Agent identity & permissions.
When your agent calls an API, whose credentials is it holding, and whose name is on the action afterwards? Most prototypes answer "the developer's key" and "nobody" — which is exactly why they do not survive their first security review. This entry separates the three questions that get collapsed into one, and explains why permissions are the only agent defense that still works when the model is wrong.
Three questions, routinely conflated.
Every action an agent takes against a real system raises three separate questions, and prototypes typically answer all three with a single API key in an environment variable:
- Authentication — who is calling? The identity presented to the system being acted upon. An agent needs one, and "the same shared service account as every other agent and background job" is a poor one.
- Authorization — what may this caller do? The permissions attached to that identity. This is the question that actually bounds damage, and the one most often left at "whatever the key can do."
- Attribution — who did that, and on whose instruction? The after-the-fact record. When a customer asks why their record was changed, "an agent did it" is not an answer; "user X's request, agent Y version 3, acting under scope Z, at time T" is.
The default anti-pattern is one long-lived, broadly-scoped credential shared by every user and every task. It fails all three at once: the system cannot tell agents apart, the agent can do far more than any single task requires, and the log shows one identity doing everything.
Delegation: acting on behalf of someone.
An agent almost never acts for itself. It acts for a user, and the design question is how that user's authority reaches the agent. Two models:
- Impersonation. The agent holds the user's own credential and is indistinguishable from them. Simple to build, and wrong in two ways: the downstream system cannot tell a human action from an automated one, and the agent inherits everything the user can do — including the ninety-nine permissions this task does not need.
- Delegated authority. The agent has its own identity and is granted a scoped, time-bounded right to act on the user's behalf — the pattern behind OAuth-style consent flows and behind MCP's authorization model. More setup, and correct: the action is traceable to both parties, and the grant can be narrower than the user's own access.
The rule that follows: an agent's effective permissions should be the intersection of what the user may do and what the task requires — never the union, and never the developer's. If a support agent needs to read orders and issue refunds under a cap, that is the grant. It should not also be able to edit the product catalogue merely because the engineer's key could.
The same logic applies between agents. When one agent delegates to a sub-agent, the sub-agent should receive a narrower grant, not a copy of the parent's. Authority that widens as it propagates is how a small compromise becomes a large one.
Least privilege, concretely.
- Scope per task, not per agent. A single agent may perform many kinds of work. Issue the credential for the run, carrying only what that run needs, rather than provisioning the agent once with the union of everything it might ever do.
- Short-lived over long-lived. A token that expires in minutes limits the value of stealing it and forces a re-grant path you can revoke. Long-lived keys in environment variables are the credentials that end up in traces, logs, and repositories.
- Split read from write. Most agent steps only read. Let the exploratory majority run on a read-only identity and require a separate, narrower credential for the few steps that change something — this is the permission-layer version of gating on consequence.
- Keep the secret out of the model's reach. If a credential is in the context window, in an environment variable the agent can print, or inside a sandbox the agent controls, treat it as disclosed. The durable pattern is brokering: the agent requests an authenticated action and a component you control attaches the credential outside the agent's reach.
- Be able to revoke. Per-agent identities exist partly so that you can switch one off without switching off everything. If the only way to stop a misbehaving agent is to rotate a key that fifteen other systems share, you do not have a kill switch.
Why this is the defense that survives.
Most agent safety measures depend on the model behaving correctly: careful instructions, a well-written system prompt, a check that the model is asked to perform. Prompt injection defeats all of them, because it attacks precisely the component being relied on.
Permissions are different in kind: they are enforced outside the model, by the system being called. An injected instruction can make an agent try to delete the production database; it cannot grant the credential the right to do it. This is why scoping is not a compliance chore layered on at the end — for a system whose reasoning is manipulable by its own inputs, it is the last line that actually holds.
The companion piece is the record. Every consequential action wants five fields: who requested it, which agent and which version acted, under what authority, what precisely changed, and when. That is what turns "the agent did something" into an investigable event — and it is the same record that lets you answer a customer, satisfy an auditor, and reconstruct an incident.
The agent identity & attestation deep-dive covers proving which agent acted, MCP auth & OAuth 2.1 covers the delegation flow for tool servers concretely, and the scoped credentials and audit trails chapters cover running both in production.