Verification is one of those words that sounds clear until a dispute lands on your desk. When an agent books a subscription nobody requested, the postmortem always asks the same three questions: who authorized this, what did the agent say it was doing, and can we prove that what happened matched what was intended? A verification system is whatever lets you answer all three in minutes. It takes five layers, and a gap in any one leaves you exposed.
Identity: which agent acted?
The first question any payment audit asks is who did this. For agents, that means stable identifiers for the agent itself, the system that deployed it, and the policy it ran under. Cryptographic identity is the strongest form, and 2026 made it infrastructure rather than theory: Visa's Trusted Agent Protocol has agents register public keys and sign their requests, Mastercard's Agent Pay issues each agent a unique cryptographic credential, Skyfire's Know Your Agent protocol now has an IETF draft and ships verified agent identity through F5 and Fastly at the network edge, and the A2A protocol added signed agent cards for cross-organization identity.
You do not need all of that on day one; even a simple, stable agent ID beats an anonymous runtime session. The bar is that any transaction traces to a specific agent configuration, because you cannot enforce a policy against an agent you cannot identify.
Attestation: is spending appropriate right now?
Identity proves who the agent is. Attestation proves it is in a condition where spending is appropriate. Attestation-before-access means the payment system checks prerequisites before releasing any credential: required checks completed, funding present, a policy attached, no active incident flags. A newly deployed agent cannot silently start spending in a new environment, because access is an explicit decision rather than a default.
This layer is what makes compromise survivable. An agent that fails attestation receives no credentials, which means it has nothing to leak and nothing to misuse.
Intent: what was it trying to do?
Intent is the core verification primitive for agent spend, and the layer most often skipped. Without a declared intent, your policy engine reacts to raw transaction requests instead of evaluating whether the agent's goal is appropriate; you cannot explain the spend later, because all you have is a descriptor and an amount; and you cannot distinguish fraud from a well-intentioned agent that misread its objective.
The intent object is structured and logged before any credential is released: merchant, expected amount, purpose. That record becomes ground truth for everything downstream, from reconciliation to disputes.
If you can reconstruct the sequence in minutes, you have verification.
Otherwise you have trust.
Hard controls: what is impossible?
Verification cannot be purely after the fact, because after the fact means the money already moved. Hard controls define what cannot happen regardless of what the agent requests: funding isolation so the blast radius is a scoped balance rather than a credit line, merchant locks that bound where money can go, velocity caps that stop a retry loop from becoming dozens of charges.
The controls have to bind at authorization time on cards, and before the transfer on rails that do not reverse. A monitoring dashboard tells you something went wrong; a decline at the network is what prevents it.
Evidence: can you explain the charge?
The final layer is the record that survives disputes and audits. A complete evidence chain links the agent ID, the intent and its declared purpose, the policy decision, the credential used, the transaction, the merchant, the amount, and timestamps for each step. Chargeback processes were designed for humans who made conscious decisions; an agent transaction stands up in a dispute only as a chain: a human set the policy, the agent declared intent within it, the system approved it, and the settled transaction matched the declaration.
This is also where liability is heading. American Express now offers protection for registered-agent purchases, and protections like that will always hinge on exactly this proof: what was the agent authorized to do, and did the transaction match?
What verified looks like in production
The definition of done is short. No spend without a logged intent. No credential released without attestation and a declared purpose. Credentials scoped and closed outside the active transaction. Every settlement verified against its intent. Evidence persisted and queryable in minutes. Not one feature, but a system where each layer catches the failure the previous one cannot.
Signets builds these layers into the account: policy checks before any credential is released, intent-gated scoped credentials, hard controls enforced before money moves on every rail, and an evidence record for each transaction. If verification is the thing standing between your agents and production, tell us what you are building and we will get you sandbox access.
FAQ
What does payment verification mean for AI agents?
Proving four things: which agent acted, under what authorization, what it declared it was buying, and that the settled transaction matched that declaration. In practice that takes five layers: stable identity, attestation before access, logged intent, hard controls at authorization, and a queryable evidence record.
How do merchants verify AI agent identity in 2026?
Increasingly at the network and edge: Visa's Trusted Agent Protocol verifies agents' cryptographic signatures at checkout, Mastercard's Agent Pay issues unique agent credentials, and Skyfire's Know Your Agent tokens are checked by bot-defense layers at F5 and Fastly, letting verified agents through while unverified automation is blocked.
Is agent identity enough to make payments safe?
No. Identity gives you attribution, not prevention. Safety comes from the layers on top: attestation before credentials are released, declared intent, funding isolation, merchant locks, and velocity caps enforced before money moves.
What evidence should be kept for each agent transaction?
A linked chain: agent ID, intent ID and purpose, the policy decision, the credential used, the transaction ID, merchant and descriptor, amount, and per-step timestamps. If that sequence can be reconstructed in minutes, the transaction can survive a dispute or an audit.
