Know Your Agent: the identity layer AI is about to need

In the last few months I have watched software do something it has never done before. It decided, on its own, to buy something.

Not "add to basket". Decided. An agent reads a brief, compares the options, picks one and completes the purchase. The plumbing already works. Payment rails accept it, merchants ship the goods, money moves. What does not exist yet, anywhere, is a dependable way for the merchant at the other end to answer a question that used to be trivial: who is this acting for, and did that person actually agree to it?

That question is going to define the next five years of identity engineering. Most of the industry is currently solving the easier half of it.

I have been circling this problem for a decade. My first filing on it, WO2017118763A1 in January 2016, covered a one-time code carrying the user identity, the location and the time of a transaction, so that what was presented could be tied back to a person and a moment rather than to a stored credential. The agent case is the same question with the human moved one step further away.

An agent is a third kind of thing

Every access control system ever built assumes two categories. There are humans, who log in, and there are machines, which hold service accounts and API keys. The distinction carries real weight. Humans get consent screens, sessions, step-up prompts and legal responsibility. Machines get a long-lived secret, a scope and a rate limit, and nobody expects a machine to have an opinion.

An agent is neither. It has the mechanics of a machine and the authority of a person. It holds a token, but it is spending somebody's money, signing on somebody's behalf, and it can make a choice its principal never anticipated. Model it as a user and you have handed a script a human's full session. Model it as a service account and you lose the only fact that matters when something goes wrong, which is which human is on the hook.

The industry has noticed. The FIDO Alliance has stood up an Agentic Authentication working group. Google has published AP2, Mastercard has Verifiable Intent, and a handful of identity vendors have started shipping "agent identity" as a product category. Read them side by side and a pattern shows up: they are mostly answering the payment question. How does the transaction leg work, and how does a merchant tell a real delegation from a replayed token?

Worth solving. Not the part I would lose sleep over.

The hard half is the human

Here is the failure I expect to read about within eighteen months. Somebody's agent runs for weeks without incident, doing exactly what it was asked. Then a prompt arrives inside a document it was told to read, or a supplier page it was told to compare, and the instruction that comes out the other side is not the one its owner gave it. Everything downstream of that moment is cryptographically perfect. Valid token. Valid delegation. Valid signature. Correctly attributed to a real, consenting, identity-checked human who has no idea it is happening.

No amount of transaction-layer rigour catches that, because nothing in the transaction is forged. The compromise happened upstream of the signature, in the part of the system that decides what the agent wants.

Which means the delegation cannot be a single event at the start. Consent given on Monday to "manage my supplier renewals" is not consent given on Thursday to move eleven thousand pounds to an account nobody has seen before. Treating those as the same authorisation is the mistake, and it is exactly the mistake the current designs make, because a token issued once and carried forever is the cheapest thing to build.

Four properties, and only one of them is hard

If I were specifying this from scratch, I would insist on four things.

Attribution. Every action an agent takes resolves to a named human who can be identified after the fact, not to an account, an org or an API key. If your incident review ends at "the integration did it", you have built a system with no defendant.

Scoped authority. Delegation is bounded by amount, counterparty, category and time, and the bounds are enforced where the action happens rather than in the agent's own reasoning. An agent that polices its own limits is a guard that reports to the prisoner.

Live confirmation at the threshold. When an action crosses a line that its principal would want to know about, the human is brought back into the loop and confirmed as present, right then. Not "was authenticated at some point this month". Present now.

Revocation. Any grant can be withdrawn instantly and the withdrawal takes effect everywhere, including at whatever is already halfway through executing.

The first three are engineering. The fourth is where most designs quietly fail, and I have spent a long time on that specific problem in another context.

What physical verification taught me about tokens

I have spent years building a verification layer for physical things: a symbol on a product, a document, a ticket or an asset that a phone can check. The naive version of that is a code that carries its answer inside it. Print the truth onto the object and let the reader read it.

That approach fails for one reason, and it is the same reason long-lived agent tokens will fail. The moment the answer leaves your control, you have lost the ability to change it or withdraw it. A printed code is fixed forever the second it leaves the press. A bearer token is fixed the second it is issued. In both cases you have made an irreversible statement about the future, and the future does not cooperate.

The design that works inverts it. The symbol carries no answer. It is a reference, unique to one item, meaningless on its own, resolved at the moment of the scan against a record and the rules attached to it. Because nothing is decided in advance, everything stays changeable: the rules can move after the code is printed, the code can be withdrawn instantly, and the decision can take account of where the scan happened, when and who is holding the phone. Refusals get recorded alongside approvals, which turns out to be the more useful half of the log.

There is a second property that matters even more here. Identifiers are not drawn from a pre-existing pool. They are brought into existence at the moment of issue. A symbol produced outside the platform is therefore not an unauthorised code, it is not a code at all, and it resolves to nothing.

Point all of that at agents and the shape of the answer is obvious. An agent should not hold a credential that means something. It should hold a reference that means nothing until it is resolved, at the moment of the action, against a live policy and a live human. Then the interesting questions all become answerable at the right time rather than guessed at issue time. Is this delegation still valid? Has the principal revoked it in the last ninety seconds? Does this amount, to this counterparty, need the human back? Is the human actually there?

Know Your Customer was never about the customer

Banks did not build KYC because they wanted to know who you were. They built it because regulation made them accountable for what moved through them, and accountability requires a name attached to an action.

Agentic commerce is walking into precisely that structure, roughly a decade earlier than anyone planned. When an autonomous system moves money and something goes wrong, someone has to be answerable, and "the model decided" is not going to survive its first contact with a regulator or a court. The industry is going to end up with a Know Your Agent obligation whether it designs one deliberately or has one imposed after an incident. Those two paths produce very different systems, and only one of them is pleasant to build.

The uncomfortable part is that the fraud, when it arrives, will not look like fraud. It will look like a legitimate delegation from a verified human doing something slightly out of character. Every signature will check out. Which is exactly why the check that matters is not "is this token valid" but "is the authorised human present and do they still mean it".

That is a solvable problem. It is the problem I work on. What worries me is how many people are shipping agents that spend money before anyone has answered it.