Know Your Agent: Why the Audit Trail Is the Leg Nobody Built

The industry gave AI agents a way to pay before it agreed how to know who the agent is. That sequence is not accidental. Payments are measurable, immediate, and commercially obvious. This created a gap, and that gap is now the central risk question for any enterprise or government deploying autonomous agents. "Know your agent" sounds simple. It is not.

Coinbase revived the long-dormant HTTP 402 status code (originally "Payment Required", unused since the early web) as x402: a protocol that lets agents settle payments machine-to-machine without a human in the loop. Settlement is irreversible. No chargebacks. Google co-led AP2, which introduced a mandate model: an intent mandate capturing what the user wants, and a payment mandate bound to a specific cart and amount. Visa announced its Trusted Agent Protocol in October 2025, a mechanism designed to let merchants distinguish trusted agents from bots.

Each of those moves made sense in isolation. Each also assumed the harder questions underneath were already settled. They are not.

Enterprises and governments actually face this question: how do you maintain grip on transactions that keep drifting further from a human hand? The issue is whether you can prove what an agent did, who authorised it, and what the record shows when someone comes asking later.

The market is now waking up to the first part of that. "Know your agent" is no longer empty territory: identity and verification vendors are already using the phrase in public. Their answer is the familiar one. Verify the agent, bind it to a human or organisation, issue a credential or passport, authenticate it at the moment it acts. That is necessary. It is not sufficient.

"Know your agent" requires three answers, not one.

Identity: is this agent what it claims to be, and can it be faked?

Mandate: what is it authorised to do, and on whose behalf?

Audit: what did it actually do, and can every party involved see the same record afterwards?

Payments protocols largely ship as though all three are already solved. They are not. The industry has moved fastest on identity, slower on mandate, and barely at all on the third. That ordering is where the liability accumulates, until it accumulates very visibly. That makes the shape of the problem clear: it is an audit problem, not a login problem.

The identity incumbents have moved. Okta made its AI agent identity product generally available on 30 April 2026. Microsoft Entra is extending its workforce identity model to cover agents. Both approaches do what identity is supposed to do: verify the agent at the door, bind it to a human principal, issue a credential.

That matters. An agent that cannot prove what it is should not be transacting on anyone's behalf. A credential tells the counterparty: this agent is real, it belongs to this organisation, it was authorised to act. That is a meaningful improvement on the current default, which is trusting the agent's own claim about itself.

But identity proves who acted. It does not prove what happened next.

Consider the postman. You can verify his ID, his employer, his route, the time he arrived. None of that tells you what was in the envelope, whether it was opened and resealed before delivery, or what was agreed once the letter reached the room. The delivery record and the contents record are different things entirely.

Identity is the delivery record. The audit trail is everything that happened in the room.

Digital wallets and verifiable credentials are adjacent and useful. mintBlue sits alongside them as the rails and the audit layer, not as another identity wallet. The distinction matters because the problem it solves is different. Wallets hold credentials; rails carry transactions; the audit layer records what those transactions actually were.

Four things go wrong under the current setup, and they are worth naming rather than burying in category language.

Faked agent identities. An agent can present credentials that look legitimate but are not. The identity layer can be spoofed, particularly where the register behind the credential is proprietary and the counterparty has no neutral place to verify it independently. Knowing the name on the envelope does not help if the letterhead can be copied.

First-party fraud via agents. An account holder's own agent executes a transaction the account holder later disowns. "I did not authorise that specific action" is easy to assert when there is no infrastructure to show what mandate was granted, what the agent executed against it, and who signed off at each step. No shared, tamper-evident record that links an agent's identity, its mandate and what it actually did exists to answer that claim today. If the only evidence sits inside one party's system, the other has to take it on faith. If the record can be amended or selectively exported, it will not settle the argument. If each side keeps its own logs, the dispute becomes a comparison of private histories. The liability sits with whoever accepted the instruction.

Chargeback liability when an agent transacts. Card networks treat agent-initiated traffic as card-not-present. No liability shift applies. Exposure lands on the merchant. Irreversible-settlement rails such as x402 remove the chargeback mechanism but do not remove the dispute. They take away one resolution path, not the underlying disagreement.

The missing register. There is a business register for companies. There is no equivalent authoritative register for agents. Several vendors are filling that gap with proprietary agent passports. A register, however, is only as trustworthy as the record behind it, and a proprietary record is one that its owner can edit. That is not a register. That is a vendor's database with a better name.

All four failure modes share a common root: there is no shared, tamper-evident account of what the agent did. Identity tells you who was at the door. It says nothing about what the agent then did.

The durable, under-served part of know your agent is the audit trail: an immutable, shared record of what the agent did, available to all the parties involved, that neither side can edit after the fact.

Disputes live in that record. Liability questions live there. Regulatory queries live there. An identity event is a moment at the door. The audit trail is the history of the room. You cannot answer post-transaction questions with a pre-transaction credential.

mintBlue's angle is the rails between parties plus that audit layer. The sealed-envelope model makes it concrete: every party seals their own envelope. mintBlue is the postman who moves it and never looks inside. Keys stay with the parties. Nothing in the middle can read the payload. Every event carries a legally binding signature and lands in a record that all sides can read and that nobody can rewrite. No central honeypot. The data belongs to the parties, not to the infrastructure.

That distinction matters when one side of a transaction is a government agency and the other is a regulated financial institution. It matters when a regulator requests an account of what happened. A board will ask why an agent spent what it spent, and the answer needs to be one that all parties accept simultaneously, without anyone's version of events having priority over another's.

mintBlue's work specifically in agent identity and mandate is at the pilot and experiment stage. It is worth being direct about this. The underlying rails and audit layer are the mature part of what mintBlue does, proven at scale in pilots. The agent-specific credential and mandate work is newer. What exists is a clear architecture, early deployments, and a conviction that the audit trail is the durable problem, because it is the one the identity vendors are not positioned to solve.

Two legs do not stand. The complete answer to know your agent requires all three components working together.

Verified identity: a credential that proves what the agent is, bound to a human principal, issued by a trustworthy authority that a counterparty can verify independently, not just on the operator's word.

Explicit mandate: a signed record of what the agent was authorised to do, for whom, and under what constraints. Not inferred after the fact. Written and signed before the transaction executes, so that "I didn't authorise that" has a concrete answer.

Immutable audit trail: a shared, tamper-evident record of what the agent actually did. Available to all parties. Not editable by any of them.

Miss any one and the other two lose their footing. Identity without mandate tells you who the agent is but not what it was allowed to do. Mandate without audit tells you what should have happened but not whether it did. Audit without identity gives you a record with no dependable link to the actor behind it.

The buyer question: do not pay for the identity check and skip the record of what the agent did.

Payment speed is table stakes once a handful of protocols settle into place. The durable advantage belongs to whoever can answer, after the fact and to everyone's satisfaction, what the agent actually did.

That is the question regulators will ask. Legal teams will ask it when a transaction is disputed. Boards will ask it when something goes wrong and a number is attached to the failure. The organisations treating audit as an afterthought will rebuild from scratch when that moment arrives, and it always does.

Payments moved first because they are visible, measurable, and commercially motivating. Audit trails are invisible until they are the only thing standing between an organisation and a significant liability or a formal inquiry. That invisibility is exactly what makes them easy to defer and expensive to neglect.

Before signing off on an agentic deployment, consider this: if one of your agents transacted on your behalf tomorrow and the counterparty disputed it, what record would you reach for to prove what happened? Would that record be one they accept? One your legal team accepts? One a regulator accepts, on the same terms as the counterparty?

That is what know your agent actually means. The industry has shipped a wallet. It has not yet shipped an answer.