Securing Local AI Agents

Local AI agents are growing more common on developer and knowledge worker workstations. Like traditional software, these chat interfaces, coding assistants, local LLM runners, browser extensions, and more are installed with familiar packaging, run in familiar process containers, and inherit the privileges of whoever launched them. From the operating system’s point of view, a local AI agent is just another application or program, and Privilege Manager already controls programs: what they can launch, what privileges they get, what they can spawn, and what local accounts they can touch.

This page covers what Privilege Manager can and cannot do on endpoints running local AI agents. The short version: If the user has standing admin, the agent has standing admin. Privilege Manager’s job is to remove that inheritance and contain what remains.

How AI agents run on workstations

Pattern	Examples	What the OS Sees
Installed application	Claude desktop, cursor	A signed exe/pkg running as a user
CLI tool	Github copilot, Claude CLI	A binary on PATH, often installed via npm/pip/brew
Scripted runner	Node/Python agents	node.exe/python.exe running a script with no distinct identity in process metadata
Containerized	WSL2/Docker runners	vmmemWSL/dockerd the agent runs inside the container

The first two behave like any application. Scripted runners are the most challenging cases and need explicit identification (see the example below). Containerized agents are separate surface (see Limitations).

What Privilege Manager helps you control

Launch control: Every Windows process creation and every macOS app or installer open is evaluated against your policies. Identify an agent by path, file hash, signing certificate, publisher, command line, or parent process. Then allow, block, elevate, restrict, or require justification or approval.
Remove standing admin: Privilege Manager removes users from local administrator groups and reintroduces admin privileges selectively per policy rather than leaving broad, standing access. An agent installed or operated by a non-admin user cannot escalate, install services, or write to protected OS locations unless allowed by policy.
Run an agent without admin privileges, even when the user has them: The Remove Administrative Rights action runs the agent at Medium Integrity with no admin privilege in its token, regardless of the user's own rights.
Contain the process tree: When an agent is elevated, its child processes don't automatically inherit that elevation. You can demote them, or deny specific child shells (cmd.exe, powershell.exe, wsl.exe) from launching under the agent.
Bound and approve elevation: Where an agent genuinely needs more privileges, time-based approvals can grant privilege for a set window and on Windows even terminate the elevated processes when the window closes.
Block local-account abuse at the API layer (Windows): The Block Local User and Block Local Group Management actions hook the underlying Windows API inside the process, so New-LocalUser, net user /add, and direct SAM calls all fail, even if the agent is running with admin. Matching on command names can be bypassed; an API-layer hook cannot.
See what's installed and who's elevating: File Inventory and Monitoring policies surface installed AI tools in the console and produce events which can be forwarded to your SIEM.

Example: run a sanctioned AI agent without admin on Windows

To let developers use an AI coding agent but never let it inherit admin:

Identify it. For a native application, create a filter matching the signing certificate (and install path). For a Node-based runner, match node.exe plus a command line filter for the agent's entry script plus its install path (the process name alone isn't specific enough).
Strip admin. Build a policy targeting that filter with the Adjust Process Rights | Remove Administrative Rights action, scoped to your developer computer group.
Block backdoors (optional). Add the Block Local User Management action to the same policy, so the agent cannot create a local account even if it is granted admin later.

The agent now runs normally at Medium Integrity, cannot escalate, and cannot create a hidden account.

Limitations to understand

Not a Data Loss Prevention (DLP), Endpoint Detection and Response (EDR), or network monitoring tool. Privilege Manager does not inspect file contents, the clipboard, prompts, completions, or model API traffic. If an agent acts within a legitimate user's existing permissions, Privilege Manager will not stop it (by design). Pair Privilege Manager with DLP, EDR, a secure web gateway, and other identity-based tooling to bolster your security.
File-access blocking has a gap for Node agents. The Deny File Access action hooks standard Windows file APIs but does not intercept Node.js file I/O. Node's libuv uses lower-level NT calls that bypass the hook. To stop a Node agent from reading sensitive files, use Privilege Manager to deny it at launch or confine it with filesystem ACLs instead.
No hooks for network, registry, or crypto APIs. Model downloads, registry writes, and local file encryption aren't blocked at the API layer. Use supplementary configuration and tolling such as launch-deny, OS ACLs, firewall/secure web gateway, and BitLocker.
MacOS privacy is best suited to be managed via device management (MDM). Fine-grain access to Documents, camera, microphone, screen recording, and the like is governed by MDM PPPC payloads, which Privilege Manager does not author. Delinea provides multiple application policies for managing system settings on MacOS.
Browser and IDE extensions run inside their host application, so Privilege Manager cannot see which extension is running. Use device management (MDM) or native extension policies for this; granular browser extension control is planned for a future release.
WSL and Docker internals are opaque. You can deny or scope wsl.exe / docker.exe and withhold admin, but you cannot apply per-process policy inside the container.

What Privilege Manager is best at

Eliminating standing admin; allow/deny on install and launch; containing the process tree; blocking local-account manipulation at the API layer; and time-bounding elevation with approval. None of these require Privilege Manager to understand what the agent is "doing." It treats the agent as a program, subject to the same privilege controls as everything else on the endpoint.

Summary

Local AI agents are not a new kind of program. Privilege Manager's existing controls apply directly and remove a large class of AI-agent risk - risk that exists mostly because the user had standing admin and the agent inherited it. What Privilege Manager will not do: inspect data, traffic, or model behavior — belongs to the EDR, DLP, network, and MDM layers that sit alongside it.