Least Privilege for AI Agents
An agent should hold only the permissions its task needs, for as short a time as possible. Many agent incidents trace back to permissions that were too broad.
On this page
When an agent causes harm, the first question is usually what it was allowed to do. The answer is often broader than its task required. Least privilege is the discipline of closing that gap, and for agents it has to be applied to tools as carefully as to accounts.
Permissions belong to the tools
A model cannot enforce a permission. It can be asked to respect one, and it may do so most of the time, but enforcement has to happen in the systems that perform the action. Each tool needs its own check. The backend that sends a message, reads a file or changes a record decides whether the request is allowed, using the identity and scope the request carries.
An agent usually acts in one of two ways. It may have its own service identity, with permissions granted for its purpose. Or it may act on behalf of a user, using that user's delegated access. In the second case the agent should never exceed what the user could do directly. A sound design treats the effective permission as the overlap of the two: what the agent is granted, and what the person is allowed.
The failure to watch for is the confused deputy. An agent holds broad authority, and a caller who lacks that authority persuades it to use the authority on their behalf. The agent was not compromised in any obvious way, and its own credentials were valid throughout. The defense is to bind each action to the identity of the requester at the tool, so that the agent's standing cannot be borrowed for a request it was never meant to serve.
Scope credentials tightly
Give each tool a credential scoped to the smallest set of resources it needs. A summarizer for support tickets needs to read comments on one queue. It does not need administrator rights on the helpdesk, access to other queues or the ability to delete anything. Scope by resource, such as a specific mailbox folder or project, and by action, so that a read credential cannot write.
Read-only should be the default. Avoid wildcard permissions, which grant more than their names suggest as systems grow. Use separate credentials for each agent and for each environment, so that a problem in testing cannot reach production. Keep long-lived keys out of prompts, out of configuration the model can read, and out of any place the model's output can reach.
Separate reading from writing
Expose read tools and write tools as separate sets, and keep the write set small. A write tool should validate its arguments on the server against policy. An amount limit, an allow-list of recipients and a check that a record is in an editable state all belong in the service, so that they hold however the model phrased its request.
Consequential actions should require approval for each instance, presented in plain terms. The approval should show what will change, for whom and with what effect. The approval cannot come from the same model output that requested the action, because that would ask the same source to check itself. Rate limits and batch limits help as well. An agent that begins sending dozens of messages where it normally sends one should be stopped by the system, not by a person noticing later.
Short-lived access
Credentials that expire at the end of a task limit the damage from a leak or a misdirected action. Issue access when a task begins and revoke it when the task ends. Avoid refresh tokens with broad scope held in agent memory, since they keep working long after the task that needed them. Where the platform allows it, bind a token to the task or the resource it was issued for, so that it cannot be reused for something else even before it expires.
Test revocation rather than assuming it works. Revoke a credential in a test environment and confirm that the agent's next call fails and that the failure is logged. Revocation paths are often exercised less than issuing paths, so find out how long revocation really takes before relying on it.
Audit what the agent did
Log every tool call with its arguments, a summary of the result, the identity used, the user on whose behalf it acted and any approval recorded. The log is the basis for review, for reconstructing an incident and for finding permissions that are never used. Unused permissions can then be removed.
Review the log against the intended task. A support agent that reads one ticket queue all day is behaving as designed. An agent that reads records across many unrelated queues, or that calls a write tool when its task needed only reads, has either a flawed design or a flawed prompt, and the log will show which. Set alerts on patterns that fall outside the normal range for each agent.
A permission review
Take an agent you run, or one you are designing. List each tool, the credential it uses and the scope of that credential. For each write tool, write the server-side rule that validates its arguments and the approval condition, if there is one. Then remove one permission and run the task again in a test environment. If the task still works, the permission was not needed, and the removal should stay. If it fails, note exactly which step needed it, and decide whether that step should be redesigned or the permission narrowed.
