Infrastructure
Digital Identity for AI Agents
Identity, delegation and scope are three questions, not one.
An agent that acts for you has to answer three questions to anyone it deals with, and they are three different questions that get collapsed into one word:
- Who is this? - a stable identifier for the agent itself.
- Whose authority does it carry? - a link to the person or company behind it.
- What was it allowed to do? - the scope and limits of that authority.
An API key answers none of them. It proves the caller knows a secret. It says nothing about who the caller is, whether the secret was delegated or stolen, or what it may be used for - and it is issued by the very party whose claims a counterparty is trying to verify.
Why this is not the same as human identity
Human identity systems assume a durable subject: one person, one lifetime, identifiers that should persist. Agents invert nearly every assumption. They are created and destroyed constantly. They are cloned. They act for different principals at different moments. Their authority should expire by default rather than persist.
That means the durable object is not the agent - it is the delegation. What deserves an identifier and a lifecycle is the grant of authority, and the agent is merely its current holder. Systems designed the other way around end up unable to answer the only question that matters when something goes wrong.
The three-part model
- An identifier the operator cannot silently swap A decentralised identifier resolves to a document listing the keys that may act for a subject. Its value is not decentralisation for its own sake, but that the history of key changes is visible: an operator cannot replace the key and pretend nothing happened.
- A credential someone else vouches for A verifiable credential is a signed statement by an issuer about a subject - "this agent acts for Acme GmbH", "this agent is registered under scheme X". The verifier checks the signature against an issuer it already trusts. No call to the issuer, no trust in the agent's operator.
- A mandate that states the limits The narrowest and most load-bearing piece: a machine-readable grant saying what this agent may do, for whom, up to what value, until when. It has to be presentable to a counterparty, verifiable without the principal being online, and revocable in a way the counterparty notices.
What "revocable in a way the counterparty notices" means
This is where most designs quietly fail. Revocation is easy to declare and hard to make effective. If a mandate is revoked at 14:03 and a merchant accepts it at 14:04, the outcome depends entirely on whether the merchant had a reason to check and a cheap way to do so.
Approaches in use: short-lived credentials that expire faster than a dispute can develop; status lists a verifier can cache and check offline; and anchoring revocation state where the issuer cannot rewrite it, which is the honest, narrow argument for a ledger in this stack - covered here. Short expiry is the most widely deployed because it requires no coordination.
There is still no widely accepted way to express "this agent may spend up to €200 on travel this week, on my behalf, and nothing else" such that an arbitrary merchant can verify it, a court would recognise it, and my bank would honour a dispute if it were exceeded. Each of those three parties is solving it separately.
The delegation chain
Real deployments are rarely one hop. A person authorises a company; the company deploys an agent; the agent spawns a sub-agent for a subtask; the sub-agent calls a third-party service. Each hop should narrow authority and never widen it, and every hop should be reconstructable afterwards.
Two rules make this tractable. Attenuation: a delegate can only pass on a subset of what it holds. Provenance of authority: the chain back to the human who granted it is verifiable, so that "who authorised this" has an answer that does not depend on log files nobody kept. Capability-based systems have modelled this for decades; the work now is making it interoperable rather than inventing it.
What a service should actually check
Concretely, when an agent calls you:
- Is the identifier resolvable, and does the signature match a key currently listed for it?
- Is there a credential from an issuer you trust linking this agent to a legal person?
- Does the presented mandate cover the specific action requested, in scope, value and time?
- Has any of it been revoked - and how stale is your revocation data?
- Would you be able to reconstruct all of the above in six months if someone disputes it?
The last one is the test that matters commercially. Everything before it is access control; that one is evidence.
Where this stands
The cryptography is finished and has been for years. Identifier and credential specifications are stable and implemented. Mandate formats are in active competition, with payment networks, protocol projects and identity bodies all shipping incompatible versions - which is normal at this stage and resolves either through convergence or through one party being large enough to make its version the default.
The genuinely missing piece is demand. Almost no service currently asks an agent to prove anything beyond possession of a key, because agent traffic is not yet large enough to hurt. That changes the first time a service has to explain why it let an unverified agent commit it to something - which is a question of when, not whether.
The wider infrastructure picture is on AI and blockchain; the commercial consequences of getting this wrong show up in agent payments.