Zero Trust for AI agents: who is the agent acting as?
AI agents now call APIs, read files, and take actions. The identity question underneath that is one we already know how to answer.
An AI agent books a meeting, queries a database, and files a ticket. Three systems received three requests. Each one logged an identity. The question worth asking is which identity they logged, and whether it tells you anything useful a week later when someone asks what happened.
In most early deployments, the answer is a service account with a long-lived API key, shared across every user of the agent. That is not an AI problem. It’s the same over-permissioned service account we’ve been trying to eliminate for fifteen years, reintroduced because the agent needed to work by Friday.
What makes agents different
Two things, really.
The agent acts on behalf of someone. A human requests, the agent executes. If the downstream system only sees the agent, you’ve lost the delegation chain, and with it any ability to enforce that the agent can’t do something the requesting user couldn’t.
The agent’s inputs are untrusted in a way a script’s inputs are not. Content the agent reads — a web page, a document, an email — can contain instructions. This means the blast radius of a prompt injection is exactly the set of permissions you granted the agent.
Put those together and the design goal is clear: the agent should hold no standing privilege of its own.
Applying the principles
Verify explicitly. Every agent action should carry an identity that names both the agent and the user it’s acting for. On-behalf-of token flows already exist in OAuth for this. Use them rather than inventing something.
Least privilege, scoped per task. Not “the agent can read the CRM,” but “this invocation can read these records, for the next five minutes.” Short-lived, narrowly scoped tokens turn a prompt injection into a bounded incident instead of an open one.
Assume breach. Log every tool call the agent makes, with the delegation chain intact. The audit question after an incident is never “did the agent run?” It’s “what did it touch, on whose authority, and why did the policy allow it?”
Where this is still unsettled
Human approval for high-impact actions is the obvious control, and it works until the volume makes people click through without reading. Deciding which actions genuinely warrant a human, and designing the prompt so the reviewer can actually evaluate it, is harder than the token plumbing.
I don’t think agent identity is a new discipline. I think it’s IAM, with a requester that can be talked into things. That’s the part our existing models don’t account for yet.