How Do You Prove an AI Agent Was Authorized to Act?

An AI agent just moved money, queried a dataset, or called an API on someone's behalf. Afterward you can ask three things about what it did: what data it touched, what decision it made, and whether it was allowed to do any of it. The first two are getting answers. The third, authorization, is the one nobody has cleanly solved, and the usual answer makes it worse.

A category is forming around proving what agents do

For most of computing history the user was a person with a password. Now the user is increasingly a piece of software that acts on its own, at machine speed, without a human watching each step. That shift has started a category sometimes called verifiable AI: the idea that you should be able to independently prove what an AI system actually did, rather than take its word for it or read a log it wrote about itself.

An industry group, the Advanced AI Society, has put a name on the property they want every system to have. They call it Proof-of-Control, and the gap they point at is the absence of independent evidence of an agent's actions, the data it accessed, and the authority it acted under. Strip it down and there are three questions you have to be able to answer about any autonomous agent:

• What data did it touch?
• What decision did it make?
• Was it authorized to act at all?

Authorization is the unowned pillar

Data provenance and decision auditing have momentum behind them. There are logging standards, evaluation frameworks, and a lot of smart people working on both. Authorization is quieter, and it is the one that breaks first when the actor is software.

A human authorizes once and logs in for the day. An agent runs unattended, makes thousands of calls across systems it was never introduced to, and the question is this actor allowed to do this, right now has to be answered every single time, by a machine, with evidence that anyone on the other side can check. That is a different problem, and the tooling built for human logins does not solve it.

A credential is the wrong shape for an agent

The reflex is to give the agent a credential. An API key, a long-lived token, an identity document it carries and presents at the door. That works right up until it doesn't, because a credential the agent holds is a secret, and a secret that travels can be copied, leaked, or replayed. Hand an autonomous agent a standing key to a sensitive resource and you have created the exact thing attackers harvest.

There is a second failure mode, quieter than theft. Picture the life of one key. An agent is granted a 90-day API key for a project. The project ends on day 3. The key still works on day 90, and on day 91 if nobody remembers to turn it off. The authorization happened once, at issuance, long before the actions it kept clearing. The decision and the action came unstuck from each other, and the gap between them is where the risk lives.

This is not only our view. Recent research on agent authorization argues that standing privileges are an operational risk, and that authority should be computed fresh and ephemeral rather than granted once and left lying around. The field is converging on an uncomfortable conclusion: the credential model that defined human identity for the last twenty years is the wrong default for software that acts on its own.

The right shape is a proof, read fresh

So flip it. Instead of issuing the agent a credential and trusting whoever holds it, evaluate the condition at the moment of the action and return a signed answer. Read the wallet's state, check it against the condition the resource requires, and emit a signed yes or no. No standing grant. Nothing for the agent to carry between requests. Nothing sitting in the wild to steal.

Revocation stops being its own problem too. Because the condition is read fresh on every request, you do not claw back a credential and hope it was not already copied. You change the state, and the next request simply returns no. Access ends on the next call, not whenever a token happens to expire. That is the property you actually want when a project ends, a budget is cut, or an agent is retired.

This is the whole idea behind wallet auth: conditions, not credentials. The input is a condition the resource sets. The output is verifiable evidence, not a bearer artifact the agent hauls around and hopes nobody steals.

It is cryptographically verifiable, today

Proof-of-Control describes a ladder of how strong your evidence is: self-verifiable, then independently verifiable, then cryptographically verifiable at the top. The top rung is the hard one, and it is where wallet auth already sits.

Every answer is ECDSA-signed. The public key is published at a JWKS endpoint, so anyone can verify the signature offline with no call back to us. The condition is hashed into the response, so tampering is detectable. You send conditions in, you get cryptographically verifiable evidence out, and you can check all of it yourself, across 37 chains. This is not a roadmap slide. It runs in production.

Where it fits in the agent's life

Map it onto the lifecycle the agent already runs:

• When it asks for access, the live question is not only who it is but whether the action should be allowed, and that is evaluated right then, not honored from a grant issued months earlier. There is still a signing key, but it never travels: what crosses the wire is a fresh, single-use signature bound to that one request, with nothing reusable left behind to capture or replay.
• When it crosses into a resource, the signed attestation says the condition held, and the resource verifies that on its own.
• When it settles a payment, the paying wallet is the identity and the payment is the authorization. No separate account, no human in the loop.

And it coexists with what you already run. The ordinary API key still works. Wallet auth is a second door, an additional way in for the agents and resources that would rather present a proof than store a secret.

The same shape protects people

This is not only an agent story. A person who proves a condition instead of presenting a stored credential has no password to phish and no secret to harvest. The shopper who gets a discount because their wallet holds a brand's token never hands over an identity to be filed away and leaked later. Agents are simply where the old model breaks first and most visibly, because they act constantly and they cannot be trusted to hold a secret safely.

Proof, not a key

The category is right to demand proof. Most of what is being built answers what an agent did after the fact. The harder question is whether it should have been able to act at all, and that one has an answer that is signed, checkable by anyone, and live right now. Not a credential to steal. A proof, read fresh, every time.