Workplace adoption of AI tools on endpoints is growing.
As of July 2026, 90% of professional developers were using AI coding agents at work at least weekly, according to JetBrains Developer Ecosystem Survey 2026. Claude Code was used by 39% of developers worldwide, up from 18% in January.
A developer opens an AI coding agent, describes what they want in a sentence, walks away to get coffee, and comes back to a machine that has been busy. The agent opens a terminal, edits files, installs packages, runs the build, kills the process that’s holding the port and tries again.
That is not a browser tab. That is a program taking instructions from a text box and executing them on a workstation.
The most important question your security program needs to ask is what is the agent running as?
So far, the AI risk conversation on employee laptops has been about data going out. For example, someone pasted a customer contract into a chat window, and your personally identifiable information (PII) is sitting in another company’s cloud. That’s still a real problem, and it can be addressed by Data Loss Prevention (DLP) tooling and security awareness training.
An agent is a different problem. Chatbots leak, while agents act. An AI agent has a working directory, a process tree and a token. Whatever privilege that token carries, the agent carries. And so does everything the agent launches. A chatbot mistake leaves you with an incident to investigate, but if an agent with administrator rights makes a mistake, you have a changed machine.
Like traditional software, coding assistants are installed with familiar packaging, run in familiar process containers, and inherit the privileges of the token they are launched with. From the operating system’s perspective, local AI agents show up in five patterns:
| Pattern | Examples | What the OS sees |
| Installed application | Claude desktop, cursor | A signed exe/pkg running as a user |
| CLI tool | GitHub Copilot, Claude Code | 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 metadata |
| Containerized | WSL2/Docker runners | vmmemWSL/dockerd, the agent runs inside the container |
| Browser extension | Perplexity AI Companion, ChatGPT Extension | Process IDs underneath a browser process |
None of this is exotic or adversarial. It's how modern developer tooling installs itself. But if your organization is asking “do we allow AI agents?”, that’s the wrong question, because the honest answer is that you already do.
The risk concentrates in one place: whether the user launching the agent is a local administrator.
If the user is a local administrator, the agent gets their reach. Not their token, exactly; Windows is more careful than that. When a local administrator signs in, they get two tokens: a filtered one with the admin group switched off, and a full one held in reserve. Their desktop runs on the filtered token, so the agent they launch does too. It starts at medium integrity with no admin rights in force. The difference from a genuine standard user is that the full token is still there, one consent click away.
What it inherits is the distance to admin. For a local administrator, that distance is one consent click the human is primed to approve, because they are the one who asked the agent to do the work. For a standard user, that same moment is a prompt for credentials they do not have. That is the whole boundary, and it is worth being precise about: not a different token, a different answer to a question the agent is going to ask.
This is also how it tends to get set up in the first place. The agent needs to install a dependency, and if something fails with a permissions error, and the fastest path to a working demo is to run the whole thing elevated and stop thinking about it. Nobody wrote that decision down anywhere.
You end up with an unattended process taking natural-language instructions and spawning children that inherit whatever it has. To make matters worse, even if agents ship as per-user installs running at medium integrity, they can still do damage at the user level.
When a gated command doesn’t hold In October 2025, a Claude Code user filed issue #10077: The agent ran a recursive delete from the filesystem root of his Ubuntu environment under WSL2. He reports he had not enabled bypass mode and had an allowlist scoped to his project directory, and the logs he captured record the tool's output but not the command that produced it.
The issue's own reproduction field reads “UNKNOWN.” The user was not root. His home directory was emptied. /bin, /boot, /lib and /etc survived, behind page after page of logged “Permission denied” lines. No Anthropic engineer ever replied; a stale-issue bot closed it 60 days later.
Whatever gated that command, it did not hold. The model's own judgment did not hold. The operating system's permission model was the last thing standing, and it is the only reason that machine still booted. It also did not save the user's files. Least privilege capped what the agent could reach; it did not stop it doing real damage inside that boundary.
Microsoft has landed in the same place. One of their stated principles for agents on Windows is that they “must not be granted permissions or capabilities exceeding that of the initiating user, including administrative rights.” Read that carefully: It is a ceiling, not a reduction. Microsoft's model only delivers a meaningful ceiling if the human is not a standing administrator. If they are, the ceiling is admin. (Microsoft Support, “Experimental Agentic Features,” updated 5 December 2025.)
Identify agents by what they are, not what they’re called
You can’t control what you can’t see. Start by building an inventory of AI tools and agents running across your endpoints, including unsanctioned or “shadow AI’ that may have been installed outside normal IT processes. Read the first blog in this series to learn more: Shadow AI is already on your endpoints. Here’s what to do about it.
For installed apps, match on the signing certificate and install path so it will survive version upgrades in a way a file hash won't. For scripted runners, you have to be more specific: Match the interpreter plus the command line that launches the agent's entry script, from its install path. It's more work than adding an app to a list, and it's the only way to write policy about a thing that presents itself as node.exe.
Decide what is allowed to run, not just what it can do once it is running
The strongest version of this is not a list of banned agents. It is the opposite posture: Deny by default, then allow by attribute. Allow anything signed by a certificate you trust, anything owned by an account you trust, anything your deployment tooling shipped, or anything present on a known-good reference machine.
Between them those cover the overwhelming majority of a managed fleet without anyone sitting down to name applications. The catch-all then denies whatever is left, and the exceptions you write are few enough to actually review.
Remove standing admin
Remove local administrator group membership and let the agent run as a standard user at medium integrity, with no admin privilege in its token, regardless of what rights the human has. Then hand back exactly the privileges that genuinely need elevation: a specific installer or a specific operation all granted through policy instead of through group membership. The agent keeps working. It just stops being able to change the machine underneath it.
This is the highest-value single change available, and it is not sufficient on its own. That is why it is one of six moves rather than the only one. The limit is worth stating plainly: A great deal of modern software, agents very much included, does everything it needs to do inside the user's existing permissions and never asks for elevation at all. Removing standing admin sets a ceiling on the worst case. Deciding what is allowed to run in the first place, move 2, is what covers the rest.
Contain the process tree
If you do elevate something, elevation should stop there. That is something you configure deliberately rather than something you get by default, so it is worth confirming rather than assuming.
Prefer demoting the shells an agent reaches for over denying them outright. Naming cmd.exe and powershell.exe covers the obvious cases, but a renamed copy, or a process created with no shell at all, routes straight around a deny list. Otherwise, an agent you elevated for one narrow reason becomes a general-purpose elevated shell, which is a much larger thing than you agreed to.
Close the local-account backdoor
Account creation is how a temporary problem becomes a permanent one. Blocking local user and group management at the Windows API layer means calls fail, so having admin rights is not by itself enough to get past it. It's a small change that closes off a whole category of persistence.
Time-box the elevation you do grant
When someone legitimately needs elevated access for a task, grant it for the task, not for the quarter. Approval-based, time-bound elevation (where a one-time JIT session automatically terminates the applications it elevated when the window closes) means the exception doesn't quietly become the configuration.
Endpoint privilege management has two core layers: application control and endpoint least privilege. However, these are not a perimeter. Being precise about where the boundary is lets you plan the rest of your stack around it. Other layers sit alongside endpoint privilege management:
Delinea AI Runtime Authorization controls which infrastructure an agent can reach, and issues the credential at the point of access so the agent never holds it.
Data loss prevention (DLP) and Network monitoring inspects traffic and file contents in motion and catches things like PII pasted into a web chat.
Endpoint detection and response (EDR) watches behavior and flags or kills malicious activity.
Endpoint privilege management does not read prompts or completions. It does not inspect clipboard contents or model API traffic. And the most important limitation of all: If an agent acts entirely within the permissions the user already has, endpoint privilege management on its own will not stop it by design.
A few other honest edges of endpoint privilege management worth knowing before you plan around them:
Container internals are opaque. You can deny or scope wsl.exe and docker.exe and withhold admin from them, but you're not applying per-process policy to what's inside.
Node's file I/O goes through lower-level NT calls that bypass the usual Windows file-API hooks, so file-access denial isn't the right tool there. Deny at launch or use filesystem ACLs.
None of that makes endpoint privilege management less valuable. It makes it a layer. Endpoint privilege management decides what runs and what it runs as. Delinea AI Runtime Authorization controls what agents are allowed to access beyond the machine, DLP handles the data and EDR handles the behavior.
AI agents on endpoints aren't going to be contained by a policy document, and they aren't going to stop multiplying. Your developers are already more productive with them, which means the ones you block will be replaced by ones you haven't heard of.
So, the meeting on whether to allow or block them is actually about what privileges they can or cannot be granted.
An agent running as a standard user, with a contained process tree and no path to a local account, is a productivity tool that occasionally fails with a permissions error. The same agent running with standing administrator rights is an unattended administrator that takes instructions from a text box. Same software, same user, very different outcome.
Delinea Privilege Manager treats local AI agents the way it treats any other program on the endpoint: It identifies them by certificate, path, hash or command line, allows what you trust and denies what is left, removes standing administrative rights, contains what their child processes can inherit, and blocks local-account manipulation at the API layer without any understanding of the agent's behavior required.
It also inventories browser extensions, scores them on the permissions they actually request, and flags the ones that are AI tools. Our best-practice guidance for securing local AI agents walks through the specific filters and actions, including a worked example of running a sanctioned coding agent without admin rights on Windows.
Read the prompts if you can. You still have to decide what their agents are allowed to become.