Least Privilege for AI Agents: Why Most Agent Identities Are Over-Privileged (and How to Fix It)

In July 2025, an attacker submitted a pull request to the open-source repository behind the Amazon Q Developer extension for VS Code, gained commit access, and slipped in a prompt instructing the AI agent to delete the user's local files and wipe AWS cloud resources, including S3 buckets, EC2 instances, and IAM users. The injected payload shipped in an official release of the extension. A formatting error in the injected command kept it from executing and AWS reported no customers were affected, but the lesson is unmissable: the danger was never just the prompt injection. The danger was that an AI coding agent had standing permission to destroy cloud infrastructure in the first place.

That is the over-privilege problem in one sentence. A manipulated instruction is only as dangerous as the permissions sitting behind the agent that receives it. And right now, most agent identities are wildly over-permissioned. This guide explains why that happens, what least privilege means when the principal is an autonomous, code-writing AI agent rather than a human, and the concrete controls a security team can put in place to fix it.

What least privilege means for an AI agent

The principle of least privilege is old: grant any identity only the access it needs to do its job, and nothing more. Applied to AI agents, it means granting each agent identity only the minimum scopes required for a specific task, for the minimum time, with no leftover standing access.

But agents force a stronger framing than the one we use for humans or static service accounts. The right mental model is to treat each agent session as an untrusted principal. A session can be steered by untrusted input it reads mid-task. Its memory can be poisoned across sessions. So the credentials it carries should be scoped to the task in front of it, time-limited, and never persistent. An agent is not a trusted employee you onboard once. It is a process that may be acting against your interests at any given moment, and your permission model should assume exactly that.

Why agents are not just another service account

It is tempting to treat an agent like the service accounts your platform team has managed for years. That breaks down quickly. A static service account does one predictable thing. An AI agent dynamically selects which actions to take based on natural-language input, and research consistently shows agents will execute dangerous operations when the opportunity exists and the input steers them there. The combination of broad permissions and unpredictable action selection is precisely the combination least privilege exists to defang. For the broader identity picture, see our guide on non-human identity governance.

How agents become over-privileged

Over-privilege is almost never a deliberate decision. It is the path of least resistance. A developer needs an agent to read a database, so they attach it to a service account that already has read access, which also happens to carry write and delete. An MCP server needs to call an internal API, so it gets a long-lived API key minted with broad scopes because that was faster than defining narrow ones. Nobody revisits it. Permissions accrete and never shrink.

• Bolting onto existing accounts. Agents inherit whatever an existing service account or admin role already holds, far more than the task needs.
• Static long-lived credentials. Vendor surveys in 2026 report that many organizations still issue agents static, long-lived API keys, giving any attacker who steals one an indefinite exploitation window.
• Permission accretion. Scopes are added when something breaks and never removed when the need passes, so the identity only ever gets broader.
• No visibility. A 2026 vendor survey of CISOs and security architects found roughly a fifth of organizations can actually see what their agents are able to access, so over-privilege goes unnoticed until it is exploited.

The same body of 2026 research reports that organizations granting agents broad permissions saw multiples of the incident rate of those enforcing task-scoped access (Teleport's 2026 report put the gap at roughly 4.5x), alongside a striking 'confidence paradox' in which the teams most confident in their security posture reported materially higher incident rates. Treat those figures as vendor survey signal rather than peer-reviewed fact, but the direction is consistent across multiple 2026 reports: broad standing access correlates strongly with incidents.

Over-privilege is the excessive-agency amplifier

The authoritative framing here is OWASP LLM06:2025 Excessive Agency, which describes the harm that follows when an LLM-based system can take damaging actions in response to unexpected, ambiguous, or manipulated output. OWASP names three root causes:

• Excessive functionality - the agent has access to tools or extensions it does not need (an open-ended shell, for example).
• Excessive permissions - the agent's identity carries more access than its tasks require.
• Excessive autonomy - high-impact actions execute without verification or a human in the loop.

Over-privilege is the second of those, and it is the amplifier for the other two. Excessive functionality is harmless if the underlying identity cannot do anything destructive; excessive autonomy is contained if the worst an unattended action can do is bounded by a tight scope. OWASP's own prevention guidance leads with least privilege: minimize extensions and functionality, avoid open-ended capabilities like shell access, execute in the user's context with minimal OAuth scope, and apply 'complete mediation' so downstream requests are validated against policy.

The December 2025 OWASP Top 10 for Agentic Applications (which uses the ASI, or Agentic Security Issue, prefix) makes this its own category: ASI-03 Identity and Privilege Abuse is exactly the topic of this guide. Its mitigations are short-lived credentials, task-scoped permissions, policy-enforced authorization on every action, and isolated identities per agent. If you are mapping controls to frameworks, see our OWASP Top 10 for Agentic Applications guide and the companion OWASP Top 10 for LLM Applications guide.

The mechanics: how the fix stack works

Fixing over-privilege is not a single setting. It is a stack of design choices, each of which shrinks the blast radius a little further. Here is how the pieces fit together.

Dedicated identities over shared roles

Each agent should be its own non-human identity (NHI) with its own credentials and its own audit trail, not a tenant on a shared service account. This is the consistent recommendation from identity-security practitioners and standards bodies. The scale of the problem is its own argument: industry research puts the ratio of non-human to human identities in the enterprise at roughly 45 to 1, climbing well past 100 to 1 in cloud-native and DevOps environments, and zero-trust guidance such as NIST SP 800-207 calls for governing non-human identities with the same rigor as human ones. Without a dedicated identity per agent, you cannot answer the most basic question after an incident: which agent did this?

Just-in-Time access and Zero Standing Privileges

A static long-lived key is a permanent liability; anyone who steals it has an open-ended window to use it. Just-in-Time (JIT) provisioning flips that. The agent holds no credentials at rest (this is Zero Standing Privileges), and for each operation it requests a short-lived, narrowly scoped credential through a policy evaluation. The credential is auto-revoked when the operation completes. JIT can even create the agent identity on demand, scoped to the task, then retire it when the task is done. The exploitation window collapses from indefinite to minutes or seconds. For the credential plumbing, see secrets management for AI agents.

OAuth 2.1 and PKCE for MCP access

MCP servers are the high-privilege tool surface most agents touch, which makes their authorization model load-bearing. The MCP authorization specification (revision 2025-11-25) requires OAuth 2.1 for remote MCP server access. OAuth 2.1 mandates PKCE (the S256 method) and HTTPS across all flows and drops insecure legacy flows like the implicit grant and resource-owner password credentials. The spec uses OAuth 2.0 Protected Resource Metadata (RFC 9728) so a client can discover which authorization server a resource requires, and it secures token acquisition through the Authorization Code Flow with PKCE.

The least-privilege pattern is token exchange: trade a broad credential for a narrowly scoped, audience-restricted token that expires in minutes immediately before a high-privilege MCP call, instead of handing the MCP server a static long-lived API key. PKCE matters here specifically because many MCP clients cannot securely store a client secret, so the proof-key mechanism replaces the secret. For the full walkthrough, see OAuth for MCP servers explained and the broader MCP server security guide.

Enforcement must be infrastructure-level

This is the point teams miss most often. Guardrails implemented inside the agent run under the agent's own authority. An agent that can write and execute code can write code that bypasses its own guardrails. The OWASP prevention note about validating downstream requests is meaningful only if the validation lives somewhere the agent cannot reach. Enforcement therefore belongs at the infrastructure level:

• Sandboxing and isolation so an agent runs in a bounded environment regardless of what it tries.
• Immutable audit logs of every action and every attempted self-modification.
• Versioning and rollback to a last-known-good state when something goes wrong.
• Static analysis of any tool an agent generates before that tool is integrated.
• A hard rule, enforced outside the agent: an agent must never have permission to modify its own identity, role, or permission scope.

Why scoped permissions are an architectural control, not hygiene

The clearest argument for least privilege as design (not housekeeping) is Simon Willison's lethal trifecta, described in June 2025. Data exfiltration becomes near-guaranteed when an agent simultaneously has three things: access to private data, exposure to untrusted content, and the ability to communicate externally. The crucial insight is that you only have to remove one leg to break the chain. If the agent's identity simply lacks the scope to make external network calls, no amount of prompt injection in the untrusted content can exfiltrate anything. Least privilege becomes the structural reason an attack cannot complete. We go deep on this in the lethal trifecta and AI agent data exfiltration.

The session-as-untrusted-principal stance gets independent support from MINJA (memory injection), presented at NeurIPS 2025. Researchers showed that an attacker can poison an agent's memory bank using only normal queries and output observation, with no direct access to the memory, reporting very high injection success rates. The implication for permissions is direct: state from a past session can be adversarial, so credentials must not persist across sessions. More on that attack class in AI agent memory poisoning explained.

Concrete steps a security team takes

Pulling the stack into an order of operations, here is what a program looks like in practice.

1. Inventory every agent and MCP server. You cannot scope what you have not found. Build the agent inventory and an MCP server registry first.
2. Map each identity's permissions and owner. For every agent, record what it can access, which identity it uses, and who is accountable for it. Flag any agent riding a shared service account.
3. Give each agent its own dedicated NHI. Replace shared and inherited credentials with per-agent identities that have their own audit trails.
4. Strip standing access. Move to Just-in-Time, short-lived, narrowly scoped credentials and Zero Standing Privileges. Kill static long-lived API keys.
5. Standardize MCP auth on OAuth 2.1 + PKCE. Use audience-restricted, minute-lifetime tokens for high-privilege MCP calls.
6. Apply complete mediation and human-in-the-loop. Validate downstream requests against policy outside the agent, and require approval for high-impact actions.
7. Enforce at the infrastructure level. Sandbox, log immutably, version and roll back, and forbid agents from altering their own scope.
8. Continuously monitor for over-privilege and anomalies. Detect drift, dormant scopes, and behavior that does not match the agent's stated job.

For teams running coding agents specifically, the permission models differ in important ways. See how Claude Code permissions work, the Claude Code permissions and hooks hardening guide, and the comparison of Claude Code, Codex, and Cursor permission models.

Where continuous visibility fits

Every control above shares a precondition: you can only enforce least privilege on agents and MCP servers you can actually see. The recurring finding across 2026 surveys, that only about a fifth of organizations can see what their agents access, is the gap that makes the rest impossible. You cannot strip standing access from an agent you never inventoried, and you cannot revoke a scope you did not know existed.

This is the Discover, Understand, and Monitor work of a non-human identity program, and it is where Anomity sits. The platform inventories every AI agent and MCP server across the fleet, maps what each one can access and who owns it, surfaces over-privileged identities before they are exploited, and produces the audit trail that enforcement and compliance both require. It is the visibility layer that makes least-privilege enforcement enforceable rather than aspirational. As the principle goes: you can't govern what you can't see. For the wider context, start with AI agents are the new shadow IT and inside Anomity discovery.

The bottom line

Least privilege for AI agents is not a checkbox; it is the single highest-leverage control in agentic security, because it bounds the damage of every other failure. Prompt injection, tool poisoning, memory poisoning, and stolen tokens all become survivable when the identity behind the agent simply cannot reach anything catastrophic. Start by seeing every agent and what it can touch, give each one its own dedicated identity, replace standing access with short-lived scoped credentials, standardize MCP auth on OAuth 2.1 with PKCE, and enforce the rules somewhere the agent cannot rewrite them. Over-privilege is the amplifier. Remove it, and the blast radius shrinks to something you can govern.