An agent needs an identity of its own

An agent needs to call things. Read a repository, query a database, open a ticket, send a message, deploy a change. The quickest way to make that work is for the agent to carry the credentials of the person who started the session, and a great many agent deployments do exactly that, because it works immediately and every downstream system already accepts those credentials.

The cost arrives later, and arrives as a set of questions that have no answer. Which of these actions were taken by the person and which by the agent on their behalf? What was the agent allowed to do that the person merely could have done? If the agent is behaving incorrectly, what do we revoke that does not also lock the person out of their job?

What impersonation costs

Impersonation collapses two principals into one. Everything that depends on telling them apart stops working at that moment, and the consequences are more specific than they first appear.

• Audit becomes fiction. The log records the user, so a reconstruction of events cannot distinguish a deliberate action from one an agent took after reading a document that contained instructions.
• Least privilege becomes unreachable. The agent inherits the union of everything the user can do, which for an administrator is effectively everything, regardless of how narrow the agent's task was.
• Revocation becomes a blunt instrument. There is one credential, so containing the agent means disabling the person.
• Anomaly detection loses its baseline. Agent access patterns look nothing like human ones — different hours, different volumes, different sequences — and attributing both to one identity means neither profile is clean.

None of these is a theoretical concern about a future capability. They are properties of any deployment where the agent's calls are indistinguishable from the user's, which is the normal state today.

Delegation, not impersonation

The alternative is not new, and it is not specific to agents. The agent has its own identity. The user grants it a scoped, time-bounded authority to act on their behalf. Every downstream call carries both principals: this is the agent, acting for this person, under this grant.

Federated identity has carried delegation semantics for years, and the model transfers directly. What changes with agents is the granularity the grant needs. A human consenting to an application usually consents once, broadly, for a long period. An agent's authority is better expressed per task and per tool, with a lifetime measured against the task rather than the session — because the thing that distinguishes a well-behaved agent run from a compromised one is often a single call that fell outside what the task required.

Policy belongs at the tool call

An identity is necessary and not sufficient. The decision that matters is whether a specific call, with specific arguments, is permitted right now — and that decision has to be made at the point of action, by something outside the model.

Placing it inside the prompt does not work, because the prompt is the surface under attack. A system instruction telling the model not to perform a class of action is a request to a component whose behaviour is influenced by every piece of content it has read. Placing it at the tool boundary works, because the enforcement point is ordinary software with a deterministic answer: this identity, this tool, these arguments, this context, permitted or refused.

An agent should not be trusted to enforce its own constraints, for the same reason a process is not trusted to enforce its own memory protection.

This also localises the human-in-the-loop question. Rather than asking whether an agent is trustworthy in general, a policy point allows a narrow answer: this class of action requires an out-of-band approval, and everything else proceeds. That is a decision a security team can make and revise, and it degrades gracefully — a policy that is too tight produces friction, not a breach.

The parts that are genuinely hard

Three problems in this area do not have settled answers, and it is worth naming them rather than implying the model above resolves everything.

1. Chained delegation. When an agent calls another agent which calls a tool, the grant has to narrow at each hop and the provenance has to survive. Protocols for this exist in fragments and not as a whole.
2. Granting scope without knowing the plan. An agent's required permissions are often only knowable once it has started reasoning, which sits badly with a grant that must be issued beforehand.
3. Memory as a delegation-evading channel. Content stored in one session and recalled in another crosses the boundary without crossing any call, which is why memory has to be governed separately from identity.

The third is the subject of separate research on this site. The first two are, at present, engineering trade-offs made per deployment rather than problems with a general solution.