Suppose an agent emails an insurer, changes a booking, accepts a software licence, or transfers money. The receiving system can ask for a token. It can verify a signature. It may even know the agent’s registered name.
None of those facts answers the first human question: who sent it to do this?
Identity and authority are easy to confuse because ordinary software keeps them close together. A person signs in; the application assumes actions in that session are theirs. Agents stretch the session across hours, tools and sub-agents. They transform an instruction, gather new context, and decide which intermediate actions appear necessary.
The distance between “I asked for help” and “the system did this” becomes a chain.
Seven questions for one action
For any consequential agent action, ask:
- What identifies the agent instance?
- Who operates it?
- Which person or organisation authorised it?
- What exact actions were within scope?
- Could it delegate again?
- How could that authority be revoked?
- What evidence remains afterward?
An API key answers perhaps one and a half of these. It identifies a credential and often an account. It rarely proves that the account holder intended the action, that the tool call remained inside the task, or that a delegated agent was forbidden from delegating again.
Composability changes the threat
The modern agent is powerful because it can use tools. Tool descriptions enter its decision context. One tool may read a document, another may encode data, and a third may send a message. Each action can be legitimate in isolation while their composition creates an unauthorised disclosure.
This is why prompt-level permission language is not a security boundary. If a shell, browser or credential store remains technically reachable, an instruction saying “do not use it” is a behavioural preference. Real boundaries live in scoped tokens, sandboxes, policy enforcement, rate limits and human approval at the point of consequence.
The same applies to identity. Giving an agent a stable identifier does not make it accountable. Accountability requires a trace from actor to authority to action to outcome.
The receipt we do not yet have
A useful agent receipt would say something like:
Agent instance A, operated by service B, acted under delegation C from person D. The delegation allowed actions X and Y until time T, prohibited re-delegation, and was revoked at R. This action used tools M and N and produced result Z.
That is not a friendly consumer interface. It is the machinery from which a friendly interface could be built.
Until then, “AI agent” often names a capacity without naming an authority. The important question is not whether the agent is intelligent enough to act. It is whether everyone affected can establish why it was allowed to.