Three separate questions get sold under the same label. Identity asks which agent is calling and on whose behalf. Payment authorization asks whether this specific purchase, at this merchant, for this amount, is permitted right now. Audit asks what happened afterwards and who can prove it. Different vendors, different standards bodies, and three failure modes that don't overlap. A security review covering only the first one leaves the other two open.
Here's how to tell them apart in a vendor call.
| | Identity | Payment authorization | Audit |
|---|---|---|---|
| The question | which agent is this, and for whom? | may this transaction go through? | what happened, and who can prove it? |
| Evaluated | at connection or token issue | at the authorization moment | after the fact |
| Inputs | keys, tokens, scopes, delegation chain | amount, merchant, category, time, approval threshold | the decision record |
| Who's building it | the MCP Agent Identity working group, your IdP, Visa's Trusted Agent Protocol | card networks, the Agentic Payments Alliance, Shatale | AP2 mandates, your card programme |
| How it fails | a stolen or over-scoped credential | a valid credential buying the wrong thing | a record nobody can reconstruct or trust |
What does agent identity get you?
Confidence that the caller is the agent it claims to be, acting under authority someone granted it. It's the question every security review opens with, and the one the industry is furthest along on answering. It's also the only one of the three that says nothing at all about money.
MCP's maintainers are moving quickly on this. The [MCP roadmap updated 22 August 2026](https://modelcontextprotocol.io/development/roadmap) puts agent identity in its top five priorities, with DPoP to bind tokens to a key the caller has to prove it holds, Workload Identity Federation to remove pasted API keys, and RFC 8693 token exchange so a parent agent can hand a sub-agent something narrower than it holds itself. [Visa's Trusted Agent Protocol](https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21716.html), announced in October 2025 with Cloudflare, does a related job at the merchant edge: the agent signs its HTTPS requests so a merchant can recognise it as accountable rather than blocking it as a bot.
What identity doesn't carry is an amount. A token binds a caller to a set of permitted operations. "May call the procurement tool" and "may spend $4,000" are different assertions, and the first one is the only one a scope can hold.
What does payment authorization get you?
A decision on one transaction while the merchant is still waiting. This is the layer where the amount, the merchant category, the time window and the approval threshold get evaluated together, and where a purchase can be stopped rather than reported.
[Five ways AI agents authorize payments](/blog/five-ways-ai-agents-authorize-payments) covers the mechanisms in use.
Two properties separate a control from a report.
The first is timing: a policy evaluated at the authorization moment can block or escalate before the money moves, while a policy evaluated against yesterday's statement can only start a recovery conversation. The second is composition. Per-merchant controls cover the merchants you predicted; a purchasing instrument scoped to a single agent covers every merchant that accepts it, including the ones the agent finds on its own, which is the entire reason you deployed an agent.
Shatale sits here. Agent-scoped virtual cards, your policy enforced at the authorization moment, purchases outside policy blocked or escalated to a person for approval, and an immutable per-agent record of each decision.
What does audit get you?
Evidence, and only if it was built to be evidence. Logs written by the same system that made the purchase, into a store the agent's own service account can write to, answer the question "what do our logs say" rather than "what happened". Most teams discover the difference during their first incident.
A record is worth something to a security reviewer when it's immutable, scoped per agent, and includes the approvals as well as the transactions, so the question "who signed off on this" has an answer that doesn't depend on anyone's memory.
AP2 is the standard closest to this. Google's Agent Payments Protocol, [donated to the FIDO Alliance in April 2026](https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/), uses cryptographically signed Mandates. A Checkout Mandate covers what the user wants to buy and a Payment Mandate covers how they want to pay, and together they give an agent-led purchase a tamper-proof record of what the user authorised.
Why do buyers ask about identity first?
Because the security questionnaire starts at authentication. It's been that way since long before agents existed, and it's the section reviewers know how to fill in.
Meanwhile the loss event is a purchase. Nobody's board asks how the agent authenticated. They ask what it bought, who approved it, and how much. A review that closes on a clean answer about token binding and never reaches the spending question has checked the part that was already the strongest.
Run the three questions in the order the money moves: who is calling, what may it spend, what can we prove afterwards.
What to ask
- Which of the three questions does this product answer, and which does it assume somebody else handles?
- If the credential is valid and the scope is correct, what stops a purchase we didn't intend?
- At what moment in the transaction is our spending policy evaluated?
- Does a purchase outside policy get blocked outright, escalated to a person, or logged for us to find later?
- Is the record immutable, scoped per agent, and does it include approvals as well as transactions?
FAQ
What is the difference between agent identity and agent authorization?
Identity establishes which agent is calling and under whose authority, using keys, tokens and delegation. Payment authorization decides whether one specific transaction, at one merchant, for one amount, is permitted at that moment. A correctly identified agent with valid scopes can still make a purchase that breaks your budget.
Do OAuth scopes control agent spending?
Scopes gate which operations an agent may perform, so they can decide whether it reaches a purchasing tool at all. They carry no amount, no merchant and no time window, so a $12 purchase and a $12,000 purchase through the same tool look identical to a scope check.
What makes an agent audit trail usable as evidence?
It has to be immutable, scoped per agent, and cover approvals alongside transactions. A log the agent's own service account can write to answers what your systems recorded rather than what happened.
Which standards bodies cover which layer?
Agent identity work sits with the MCP Agent Identity working group, the IETF OAuth and WIMSE groups, and Visa's Trusted Agent Protocol. Payment authorization is being argued at the Agentic Payments Alliance, launched 18 August 2026. Audit is closest to AP2's signed Mandates, stewarded by the FIDO Alliance since April 2026.
---
For the protocol-side version of this split, [MCP's roadmap answers who the agent is and stops there](/blog/mcp-roadmap-agent-identity-not-payments). Early access is free for publishers.
Shatale is the control layer for AI-agent payments. Its authorization architecture is the subject of European patent application EP26194994.5 (filed; priority 28 July 2026).