What least privilege means for an AI agent with tool access
Least privilege for an AI agent with tool access means the agent holds only the tools its current task needs. Each tool is scoped to the narrowest action that task requires, under a credential issued to the agent rather than borrowed from the person who launched it. The OWASP Top 10 for Large Language Model Applications names the failure mode Excessive Agency. It states the root cause is typically one or more of excessive functionality, excessive permissions and excessive autonomy.
OWASP illustrates each cause with a worked example. Excessive functionality is an agent holding tools it does not need for the task in front of it. The example is an extension trialled during development and left available after something better replaced it. Excessive permissions is a tool the task does need, connecting to a downstream system with more rights than the task requires. The OWASP example is a read job whose identity carries UPDATE, INSERT and DELETE alongside SELECT. Excessive autonomy is an application or extension that fails to independently verify and approve a high-impact action, such as deleting a user's documents with no confirmation.
OWASP defines Excessive Agency as the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated model output. It separates that from the improper output handling entry, which covers insufficient scrutiny of that output. The separation decides what a review has to cover. A system that only displays what the model produced can mislead the person reading it. An agent that can call a function, write a file, query a database or send a message can change the systems it reaches. Every call executes with whatever the tool was configured to hold.
Why can't an agent's identity be the operator's login?
An agent that runs under the session that launched it inherits the reach of that session. That session might be a developer's cloud login, a service account key or a user's own consent grant. The OWASP Top 10 for Agentic Applications, published in December 2025, names this ASI03, Identity and Privilege Abuse, and calls it the agentic evolution of Excessive Agency. Identity in that definition covers both the agent's assigned persona and the authentication material representing it, which OWASP lists as API keys, OAuth tokens and delegated user sessions.
The document states that without a distinct, governed identity of its own, an agent operates in an attribution gap that makes enforcing true least privilege impossible. Its examples describe inherited access. Un-scoped privilege inheritance is an orchestrating agent that delegates a task and passes its full access context, leaving a narrow worker agent with rights the work never needed. Memory-based privilege retention is an agent that caches credentials, keys or retrieved data for reuse, so an attacker can prompt it to reuse a cached secret from an earlier session. Cross-agent trust exploitation is the OWASP name for the confused deputy in a multi-agent system. A compromised low-privilege agent relays valid-looking instructions to a high-privilege agent, which executes them without re-checking the original user's intent.
Time-of-check to time-of-use is the fourth. Permissions are validated at the start of a workflow and have changed or expired by the time the action runs. The agent then completes a transaction the user no longer has the rights to approve. In all four the credential is one the agent legitimately holds, so no theft is involved. The missing control is a scope that stops the agent using that credential outside its task. The trigger can be an instruction reaching the agent through a document, a ticket or another tool's output.
How do you scope each tool to the task it serves?
The OWASP prevention list for Excessive Agency starts before any credential decision. It limits the extensions an agent may call to the minimum necessary. It limits the functions implemented in each extension to the minimum necessary, and it limits the permissions those extensions hold on other systems. The worked example is a mail summariser that needs the ability to read mail and should carry no ability to delete or send. The database equivalent is read access to the one table the task uses, enforced by the permissions on the identity the tool connects with.
Open-ended tools get their own item. The OWASP guidance is to avoid them where possible, naming running a shell command and fetching a URL as the cases, and to use tools with more granular functionality instead. Its reasoning is that implementing a file write as a shell tool leaves the scope for undesirable actions very large, since any other shell command can then be executed. A purpose-built file-writing tool implements only the one operation. The agentic list carries the same rule as Least Agency and Least Privilege for Tools. It calls for a per-tool profile covering scopes, maximum rate and egress allowlists, expressed as authorisation policy attached to the tool.
The authorisation decision itself belongs outside the model. The OWASP complete mediation item is to implement authorisation in downstream systems rather than relying on a model to decide whether an action is allowed. Every request reaching a downstream system gets validated against security policy. Where an agent acts for a person, the guidance is to track that user's authorisation and security scope. The action then executes on the downstream system in the context of that specific user, with the minimum privileges necessary. The named failure case is an extension designed to work in one user's context that connects with a generic high-privileged identity holding access to every user's files.
What does Microsoft Entra block for an agent identity?
Microsoft Entra Agent ID gives an agent an identity the directory governs, instead of treating it as a full user or a generic app. Microsoft states that the design recognises agents should operate with least privilege. Entra blocks agents from being granted many high privilege roles and permissions, and users and administrators are not allowed to consent to those permissions for an agent. Microsoft also states that the list of allowed roles and permissions will evolve over time, so the block list is something to read at the time of the review.
Azure resource access is granted separately and per resource. The Microsoft example is an agent that needs to read one key vault. It is given a Key Vault Reader role on that vault, which keeps the scope to a single resource. Entra also stops an agent identity from signing in at a Microsoft Entra sign-in page, so it cannot use single sign-on over OpenID Connect or SAML. Conditional Access policies can target agent identities directly. What the platform does not decide is which tools the agent holds and which of its actions wait for a person. Both stay with the team building the agent.
| Boundary | Blocked for an agent identity | What can still be granted |
|---|---|---|
| Microsoft Entra directory role | Highly privileged directory roles, among them Global Administrator, Privileged Role Administrator and User Administrator, plus any custom role | Lower privileged built-in roles, such as a reader role |
| High-risk Microsoft Graph permission | High-risk permissions, among them Application.ReadWrite.All, RoleManagement.ReadWrite.All, User.ReadWrite.All and Directory.AccessAsUser.All, which no administrator can consent to | Scoped permissions an administrator grants for a stated need, such as User.Read.All to read directory profiles |
| Microsoft Graph delegated permission | Anything beyond the access the consenting user already holds | Permissions bounded to that user's own data, such as Mail.Read or Files.Read |
| Group membership | Role-assignable groups | Security group membership, which can be assigned through an access package |
Microsoft Entra Agent ID: what an agent identity cannot be granted
Where does human approval have to sit?
The OWASP prevention item for excessive autonomy is human-in-the-loop control requiring a human to approve high-impact actions before they are taken. It states the control may be implemented in a downstream system outside the application or within the extension itself. The agentic guidance is more specific. It requires human approval for high-privilege or irreversible actions, and explicit authentication for each tool invocation. Destructive actions such as delete, transfer and publish need human confirmation, with a dry run or a diff shown before the approval is given.
Australian guidance puts the same control in the governance layer. The National AI Centre's Guidance for AI adoption, published in October 2025 to evolve the Voluntary AI Safety Standard, sets six essential practices. The sixth is to maintain human control. It asks organisations to implement mechanisms that enable human control and intervention during the operation of an AI system. It lists tool and system access controls among the mechanisms human oversight acts through.
Draw the approval line by consequence. Reading a record, drafting a message or producing a report can run without a person. Deleting data, sending an external message, moving money or changing another account's access needs one, whether the instruction came from the operator's prompt or from text the agent read somewhere. The OWASP agentic guidance treats planner output as untrusted and puts a policy enforcement point in front of execution. That point validates intent and arguments, enforces schemas and rate limits, issues short-lived credentials and revokes on drift.
What does a least-privilege review check before an agent ships?
A least-privilege review runs in a fixed order, because each step depends on the one before it. First, list every tool the agent can call. Record what each one can do at the account or service level it connects with, which is the level that bounds the damage. Second, confirm the agent authenticates under an identity of its own with a named owner. Check that identity against the blocked roles and permissions instead of assuming a lower-sounding role name is safe. Third, confirm every high-impact action is authorised by the downstream system and, where the consequence warrants it, held for a person. Fourth, confirm credentials are scoped per task and time-bound, since the first OWASP mitigation for Identity and Privilege Abuse is short-lived, narrowly scoped tokens issued per task under per-agent identities.
Fifth, test the boundary against the failure mode it exists to stop. A tool boundary can be correct in the configuration and still be reachable through the agent's own reasoning, which is what an injected instruction aims at. Black Shard tests agent tool access as part of AI cyber defence engagements. It attempts prompt injection and jailbreak techniques against it under a written scope and rules of engagement, and reports the result for each boundary.