An AI agent shouldn't need to assume a person's identity or take control of their identity credentials and keys.
That principle sounds obvious, but much of today's identity infrastructure wasn't designed for software acting independently on someone's behalf.
Here's how the model for AI agent identity should actually work.
The infrastructure problem no one designed for
Giving an agent its own credential means rethinking the infrastructure that holds and presents it.
Many identity wallets were designed around human-present flows: a person holding a device and approving a request. That's fine when the person is present, or at least with access to a smartphone.
But it doesn't solve the problem of an agent acting on someone's behalf while that person is offline or asleep.
An agent doesn't have a phone. It needs its own identity and credentials, held in infrastructure it can access programmatically, with authority that can be scoped, time-limited and revoked.
The agent carries its own credential
The agent can hold its own credential in infrastructure designed for programmatic access, such as a cloud-hosted wallet.
The person retains control of their identity and keys.
What the agent holds is separate, constrained authorization that can prove who authorized it, what it is allowed to do and for how long.
Delegation. Not impersonation.
This creates the basis for a traceable line of accountability: the person authorizes the agent, the agent proves that authorization, and audit records can connect its actions back to the authority it was given.
The infrastructure has to support that separation between the identity of the user, the identity of the agent and the authority being delegated between them.
Asking the right question
Agents should be able to authenticate as themselves and present evidence of the authority they've been given without taking possession of the user's identity or credentials.
The real question is whether your identity infrastructure can issue separate, limited credentials to non-human holders at all.
If an agent needed to act for one of your customers tomorrow, with clearly scoped and revocable authority, could your current stack give it a credential of its own?
We're already working on this problem within Truvera.
We've implemented AP2 mandate issuance and verification, giving organizations a practical way to test agentic commerce flows where an agent needs to prove what it was authorized to buy and how it was authorized to pay.
Before a transaction is processed, merchants and payment providers can verify the mandates and check that the specific purchase stays within the constraints the user approved.
If you'd like to talk about where AP2 may fit into your agentic commerce strategy, just reply to this email.
