least privilege for ai agents: What the Frameworks Actually Require

Every team that ships an AI agent eventually searches for least privilege for ai agents, usually right after a scare: an agent that deleted more than it should have, a pilot that got a broad role "just for now" and kept it, or an audit that could not say which principal took an action. The good news is that the guidance has converged. OWASP's LLM Top 10 names the failure mode, Microsoft's Entra documentation turns it into an identity pattern, and AWS's security team has laid out the architectural principles in its response to NIST. This post reads the three primary sources together and turns them into a working checklist, without inventing requirements that are not in the documents. Source

Why agents break the usual least-privilege habits

OWASP calls the failure Excessive Agency, entry LLM06 in its 2025 LLM Top 10, and its root cause is disarmingly simple: excessive functionality, excessive permissions, or excessive autonomy. The examples are ones practitioners will recognize. A read-only agent connects to the database with an identity that also has UPDATE, INSERT and DELETE. An extension built for one user's documents runs under a generic high-privileged account that can reach everyone's files. A plugin trialled during development stays wired to the agent after the team picked a different one. An agent that can post social content does so without any human approval step. None of these require an exotic attack; OWASP notes the trigger can be a hallucination or a prompt injection, and the damage comes from what the agent was allowed to touch, not from how clever the trigger was. Source

OWASP's mitigations set the baseline that the other frameworks build on: minimize which extensions an agent can call, minimize what each extension can do, avoid open-ended tools like arbitrary shell or URL fetch in favor of granular ones, scope the extension's downstream permissions to the minimum table, scope or repository, execute in the end user's context rather than a service account's, require human approval for high-impact actions, and enforce complete mediation, meaning downstream systems re-check authorization instead of trusting the LLM's decision. Source

Microsoft's pattern: identity first, privilege just in time

Microsoft's least-privilege guidance for agents, published as part of its Entra Agent ID documentation, starts one step earlier than permissions: with identity. Its argument is that least privilege is unenforceable if you cannot say which principal acted, so every production agent needs a unique, dedicated identity with a named owner, a documented purpose, and an approved list of data and tools. The document names five failure modes that show up when identity is ambiguous: shared secrets and mixed on-behalf-of modes that blur accountability, permission creep where broad pilot roles never get narrowed, over-broad tool access that turns one prompt injection into a cross-system incident, audit trails that log the chat but not the underlying tool calls, and slow revocation when disabling an agent leaves live tokens behind. Source

The practical core of the Microsoft pattern is pairing a stable agent identity with time-limited privilege. Instead of standing roles, higher privilege exists only for the duration of a specific workflow through just-in-time entitlements: temporary role activation, short-lived tokens, or approval gates. The guidance maps this onto concrete scenarios. A document-summarizing agent gets a read-only role scoped to one workspace with retrieval-only tool allowlists. A ticket-writing agent gets separate read and write roles, an allowlist of create-and-update actions, and human approval for bulk changes. A remediation agent gets JIT elevation scoped to specific resource groups, with step-up controls for destructive actions. An agent touching regulated data gets explicit data-access approvals and verified downstream enforcement. The trade-offs are stated plainly: more upfront design, ongoing access reviews and revocation testing, and friction on privileged operations. Source

AWS: the security box and earned autonomy

AWS's contribution, from an April 2026 Security Blog post summarizing its response to NIST's Center for AI Standards and Innovation request for input, is the architectural frame. Four principles, but two carry the least-privilege weight. Principle 3 says deterministic external controls are the starting point for agentic security: enforcement must live outside the agent's reasoning loop, because an LLM is a probabilistic engine, not a security mechanism, and prompt injection can override any instruction you give the model. AWS calls the enforcement layer the security box: fully specified, deterministic controls that govern which tools the agent can access, what operations it can perform, and what data it can reach, with every interaction passing through it. Principle 4 says autonomy should be earned through ongoing evaluation: start with human decisions on high-consequence operations, record what the agent recommended and what happened, and expand autonomy per operation type only when the evidence supports it, with permanent boundaries where the consequences are simply unacceptable. Source

AWS is also careful about the failure mode of the human gate itself. If every action needs approval, reviewers go reflexive and the control becomes theater, so oversight should be scoped to genuinely high-consequence operations. And its Principle 2 closes the loop with OWASP: traditional controls, least privilege included, apply with more force to agents, because agents act at machine speed and scale, which raises the cost of every excess permission. Source

Where the three sources agree

Read together, the convergence is striking and gives you a defensible minimum. Identity: every agent is a first-class, unique principal with an owner, never a shared credential. Scope: roles map to tasks and resource boundaries, not to convenience, and aggregate effective permissions across systems get reviewed because narrow roles can stack into broad access. Tools: allowlists decide what the agent can invoke, open-ended tools are replaced with granular ones, and high-impact actions like delete, export, and privilege change sit behind approval or time-bound elevation. Enforcement: authorization is re-validated downstream at every hop, not delegated to the model or the orchestrator. Evidence: every action logs identity, role, scope, action, resource, and a correlation ID. Exit: revocation is tested, including token invalidation, and autonomy expands only as the agent demonstrates alignment. If your current setup fails one of these six, that is the gap to close first. Source

A working checklist for one agent, in our assessment

This section is our read, applying the sources to the teams we work with. Pick your highest-privilege production agent and run this sequence this week. First, inventory: list its identity, every role and token it holds, every tool it can call, and every downstream system those tools reach; Microsoft's discover-and-assess step exists because this list is almost always longer than anyone expects. Second, subtract: remove unused tools, split read from write, and narrow roles to resource boundaries, the same subtraction OWASP's minimize-everything mitigations describe. Third, externalize: move the permission decision out of prompts and into deterministic checks at the tool and downstream layer, which is AWS's security box; our AI agent tool permissions post walks the mechanics, and our MCP OAuth security guide covers token scoping for MCP-connected tools. Fourth, gate: put delete, export, bulk, and privilege-changing actions behind approval or JIT elevation. Fifth, instrument and rehearse: log the six audit fields, then actually revoke the agent in a drill and measure how long full containment takes, because an untested kill path is a hope, not a control. Teams that skip this work are exactly the ones our rogue AI agents post was written about. Source