AI agents can inherit local admin rights

Same token, same rights

Windows doesn't have a separate permission tier for "AI process." An agent, whether it's a browser extension, a desktop app, or a background service, starts as a child process of whatever launched it and inherits that parent's access token. Log in as a standard user, launch the agent, and it runs as standard user. Log in as an account with local admin rights, and the agent runs with those rights too, along with anything it spawns to get its work done: a PowerShell call, a helper binary, a local runtime it installs so it can operate outside the browser sandbox.

Process tokens have worked this way for decades. What's new is what agents do with the token they inherit. Traditional privileged applications run fixed code paths approved by vendors; agents are different. They read and write local files, shell out to the command line, call OS APIs to interact with other applications, and in a growing number of cases, install a local component on first run. Every one of those actions runs at whatever privilege level the account already had.

On an account with local admin rights, that footprint reaches HKEY_LOCAL_MACHINE, the Service Control Manager, scheduled tasks running under SYSTEM, LSASS process memory where credential material sits, driver installation, and the ACLs protecting Program Files and System32. Getting there doesn't require the agent to do anything unusual. The account already has the door open. The agent just walks through it like any other process would.

This isn't the same risk profile as a normal privileged app

IT teams know how to manage risk from privileged software that runs a fixed set of vendor-written code paths. Agents break that model because the code path isn't fixed. An agent's next move is often decided at runtime, based on a prompt, a document it's summarizing, a webpage it's browsing, an email thread it's drafting a reply to. If that content contains language the underlying model reads as an instruction, and the agent has tool-use access to the OS, the model can act on it.

That's prompt injection: text embedded in ordinary-looking content, treated as a command instead of as data. Run the agent under a standard user token and an injected instruction’s  blast radius  stays limited ti what a standard user could already do. Run it under local admin and the instruction inherits admin reach; write to a protected registry keys, install scheduled tasks, reach the network with cached credentials,  disable the antivirus agent. Every step now is elevated.

There's a visibility angle too, separate from the permissions issue. Marketing picks up a writing assistant. Engineering adopts a code assistant. Sales installs a meeting summarizer. Each one shows up on a different endpoint, under a different account, with its own update cadence and its own vendor security posture, usually with no formal IT review at all. Reading the agent's source code wouldn't tell you much anyway, since what an injected instruction can do depends entirely on the account it's running under, not on the agent's own code.

Remove local admin rights, also for AI

Reviewing each new AI tool for security posture is a race IT can't win against how fast these tools get adopted. Cutting off the inheritance at the source works better: take standing local admin rights away from the account, and there's nothing elevated left for an agent, or anything else running under that account, to inherit.

The catch is workflow friction. Some of these tools genuinely need to write to a protected location once, during install. Pull admin rights with no path to scoped elevation for that one step, and the support ticket volume goes up instead of the risk going down.

PolicyPak Least Privilege Manager handles that split: the account's default privilege stays at standard user, and specific tasks get elevation rules instead. Define which installer, applet, or action is allowed to run elevated, for which users, for how long. If an agent needs admin for a one-time helper install, scope the rule to that installer. Everything else that account does afterward, agent included, runs at standard user. An injected instruction that tries to write to HKLM or install a service hits the same wall a standard user would.

Least Privilege Manager covers Windows and macOS. Worth noting given how much AI tool adoption is happening on Mac fleets that Windows-only policy would miss entirely.