AI Agent Payment Trust: Identity, Permission and Tokenization

Updated 2 November 2026 to include the October payment-network developments.

AI agent payment trust depends on evidence about the agent, the customer’s authority and the transaction being requested. Payment tokenization protects card credentials within a payment flow; merchants also need to understand which identity, permission and risk checks accompany that flow.

The latest payment-network announcements bring those checks into sharper focus. Mastercard’s 29 October 2026 earnings review describes Agent Pay as combining tokenization, digital identity and Verifiable Intent, its approach to establishing evidence of customer intent. The network is explicitly treating these as connected parts of agentic commerce.

For merchants evaluating agent checkout, the useful question is what each piece of evidence establishes for a particular purchase, and which decisions remain with the business.

From common principles to specific trust signals

In the September collaboration announced by Ant International, Mastercard and Visa, the networks proposed aligning agent trust through operator traceability, shared certification requirements and ongoing monitoring. Each network would retain its own verification and decisions. That announcement began work towards common principles; it did not publish a completed cross-network specification.

Mastercard’s separate 30 September announcement described its own Agent Pay Trust Framework across identity, intent, controls, execution and intelligence. Its first new intelligence service was an agent-origin probability score, announced for testing in the United States. The score estimates whether an AI agent initiated a transaction.

That distinction matters. An estimate of agent involvement is useful context for a risk decision. It does not, on its own, establish that the customer authorised the items in the basket. The October earnings review reinforces the broader direction, while describing agentic commerce as early-stage. Businesses should evaluate the capabilities available in their proposed integration, rather than infer availability from a framework announcement.

Follow the evidence through one purchase

Consider an illustrative office-supplies purchase. A business permits an agent to reorder one box of printer cartridges from a named supplier, within a specified budget. The supplier offers business pricing after accepting evidence of the buyer’s business status. At checkout, the agent selects a recurring delivery subscription because its first shipment is cheaper.

A protected payment credential and a recognised agent do not settle whether that subscription fits the business’s approval. The total may be within budget, but a recurring commitment differs from a one-off order. The deciding evidence is the permission covering the purchase and whether the selected terms satisfy it.

Mastercard’s tokenization explainer describes agentic tokens built around customer permissions and limits, including for recurring payments. The merchant therefore needs to establish how its specific integration represents the payment account, merchant, amount, basket and recurring terms, and which conditions it checks before approval.

In this example, the business’s one-off instruction must reach the system that can block an unauthorised subscription. If the agent wants to change the commitment, it should obtain the required approval before completing the order. An agent-origin score can inform risk handling, while the permission decision still follows the customer’s instruction.

Keep the permission decision visible

This is where a merchant’s implementation choices become important. The checkout should be able to associate the request with an agent, the represented customer and the permission being relied on. It also needs a record of the order terms actually accepted. Those references help explain a later dispute without treating the entire agent conversation as the sole evidence of approval.

A useful failure test follows directly from the example: submit the permitted one-off order, then submit the recurring version using the same agent and payment method. The result should change because the commitment changed. If both pass, the team needs to identify which system is responsible for enforcing the one-off restriction.

Our agent identity and authorisation guide explains these decision boundaries. The agent permissions guide covers limits, expiry and withdrawal in more detail.

Where AIR’s customer evidence fits

Merchants invest in reaching customers who qualify for their products, prices and services. A payment-trust flow can support the transaction while the merchant still needs evidence of a customer attribute, such as membership or business status, to decide which offer applies.

With AIR Identity, trusted issuers issue reusable, user-held credentials, and businesses verify them to reach customers who meet their criteria. With AIR Agent, customers can permit agents to present relevant evidence within defined limits. Consent and minimal data custody guide that exchange.

For the office-supplies merchant, accepted proof of business status could support eligibility for a business offer. The purchase must still fit the customer’s authority, and payment approval remains a separate decision. This describes the role of customer evidence in a commerce design; it does not establish an AIR integration with the network services discussed above.

What merchants should confirm before implementation

Ask the provider to show how its available flow handles the one-off-versus-subscription test. Identify which component checks the agent, which binds the customer’s approval to the transaction, and which system enforces changes to the terms. Confirm what a risk score measures and how an uncertain result is handled.

Then confirm the deployment status: a published framework, a service being tested and a production interface provide different levels of implementation evidence. The recent announcements are useful because they make the trust model more explicit. A merchant’s next step is to connect those stated capabilities to a decision it can demonstrate at checkout.

Frequently asked questions

What is AI agent payment trust?

It is the evidence and controls used to assess an agent-initiated purchase, including the agent’s identity, the customer’s authority, the transaction terms and payment risk.

Does tokenization prove an AI agent had permission to buy?

A payment token protects a payment credential and may include restrictions. Whether the purchase matches customer permission depends on the intent evidence and controls supported by the specific integration.

Is the cross-network Know Your Agent framework complete?

The September 2026 announcement began collaboration on common principles while preserving each network’s decisions. That release did not provide a completed shared specification or implementation timetable.

What does an agent-origin probability score establish?

It estimates the likelihood that an agent initiated a transaction. It does not by itself prove customer approval. Mastercard’s September announcement described its initial service as rolling out for US testing.

How does AIR fit into an agent payment flow?

AIR Identity supports reusable customer credentials, and AIR Agent applies customer permission to agent interactions. Merchants decide which evidence satisfies their offer rules, alongside the separate authority and payment checks required for a purchase.

Sources

• Mastercard · Tokenization explained · updated 31 March 2026; technical background.
• Mastercard · Earnings review · 29 October 2026.
• Mastercard · Trust and intelligence services announcement · 30 September 2026; background to the October update.
• Ant International, Mastercard and Visa · Joint KYA collaboration announcement · September 2026; original collaboration covered by this article.

AIR is built by Moca Network, the identity network of Animoca Brands.