Designing permissions for AI agents

Why can the model not decide?

An agent’s context contains text it did not write. Documents it retrieved, tickets it read, pages it browsed, output from other tools. Any of that text can carry an instruction, and the model has no dependable way to distinguish an instruction from the person who employs it from an instruction inside a document that person happened to attach.

A permission decision made inside the model is therefore a decision an attacker can participate in. The decision has to be made somewhere that reads no untrusted text: in code, keyed to an identity, evaluating a policy that a person wrote.

This is not a statement about model quality, and better models do not resolve it. NIST’s taxonomy lists least privilege among the required layers precisely because the input-handling problem has no complete fix.

Identity comes before permission

Most early agent deployments run under a shared service account, because it is the fastest route to a working demonstration. The cost appears during the first incident, when the audit log records that the service account did something and nobody can say which agent, prompted by which user, in response to what.

Each agent and each tool should hold its own identity. This makes revocation possible at the granularity of the thing that misbehaved, and it makes the log answer the only question that matters during an investigation.

Beyond identity is delegation. An agent acting for a person should carry that person’s permissions, not the permissions of the team that built it. Where this is done, retrieval returns what the asker is entitled to see, which also removes a category of oversharing finding that would otherwise appear in an assessment months later.

What does the MCP specification require?

The protocol’s security work is unusually direct, and it is worth reading rather than summarising from vendor material. Remote servers are treated as OAuth resource servers, with proper authorisation flows rather than ad-hoc header schemes.

Token pass-through is forbidden. A server that receives a token from a client must not forward it to an upstream API, because the upstream cannot then tell who actually made the request. Where a server needs to call upstream, it obtains its own token. The specification names the attack this prevents: the confused deputy, in which a component with legitimate authority is induced to exercise it on behalf of someone else.

Tokens should also be bound to their intended recipient. Clients include the resource parameter defined in RFC 8707 so a token is issued for a specific server, and servers verify the audience claim rather than accepting any token that validates. Without this, a token issued for one service can be replayed against another.

Where each decision is made

The model proposesReads the request and any retrieved content. Selects a tool and arguments. Has no authority.

Policy decidesDeterministic evaluation of actor, action, resource and context. Reads no untrusted text. Allows, denies, or requires approval.

The system actsExecutes under a scoped, short-lived, audience-bound token. Records what was called, by whom, with what arguments.

Separating read from write

Read access and write access are different grants and should be issued separately. An agent that summarises tickets does not need the ability to close them, and an agent that drafts a reply does not need the ability to send it.

For actions that cannot be reversed cheaply, a person approves. The approval should record what was approved, including the arguments, so that an investigation can distinguish between an action a person authorised and an action a person waved through without reading. Approval fatigue is a real failure mode, and the answer to it is fewer consequential actions rather than faster clicking.

What permissions do and do not achieve

A permission model does not prevent prompt injection. Content will still carry instructions, and the model will still sometimes follow them. What a permission model determines is the size of the consequence when that happens.

The same injected instruction against a broadly permissioned agent produces a data breach, and against a scoped one produces a failed tool call in a log. That difference is the entire return on the design work, and it is why the permission question should be settled before the agent is built rather than after an assessment finds it.

The positions we hold in engagements

An AI agent should never be responsible for deciding whether its own action is authorised. That decision belongs in code, outside the model, keyed to an identity.

Every agent and every tool gets its own identity, because a shared service account makes an incident uninvestigable.

An agent acts with the permissions of the person who asked, and where an action cannot be reversed cheaply, a person approves it and the approval is recorded with the arguments that were approved.