Security · 2026-09-28

Before You Give an Agent Your Card: An Identity Checklist for Agentic Commerce Pilots

By J. W. Bouckaert

The rules moved before the traffic did

In April 2025 Visa announced Intelligent Commerce and Mastercard announced Agent Pay. By December 2025 Visa reported that "hundreds" of agent-initiated transactions had completed with partners, and by April 2026 it described live US transactions across "a broad set of agents and partners". In March 2026 Santander and Mastercard completed what they called Europe's first live end-to-end payment executed by an AI agent, and were careful to add that the pilot "does not constitute a commercial rollout at this stage". Google published the Agent Payments Protocol in September 2025 and donated it to the FIDO Alliance in April 2026. Stripe and OpenAI published the Agentic Commerce Protocol in September 2025. American Express added an Agent Purchase Protection in April 2026.

Volume, then, is small and the rails are new. What has already changed is the rulebook. The Visa Core Rules edition of 18 April 2026 carries a section titled Agentic Platform Requirements, most of it introduced in October 2025, and its glossary now defines an Agentic Transaction: an electronic commerce transaction undertaken by an Agentic Payment Provider on behalf of a cardholder, based on the cardholder-defined payment instructions, without direct interaction between the cardholder and the merchant. Two lines in that section decide who carries the risk. The provider "is considered to be the Cardholder" for an agentic transaction, and rule 4.1.24.10 states that a cardholder is responsible for any actions taken by an agentic payment provider as part of an agentic transaction "as if the Cardholder initiated the Transaction".

Read those together. When your customer's agent buys the wrong thing under a valid instruction, the network's position is that your customer bought it. The rules require the provider to obtain the cardholder's acknowledgement of exactly that, to state when the instruction expires, and to verify the cardholder's identity before a credential is stored and before the instruction is acted on. Amex's protection covers the narrower case of an agent that deviated from an authenticated intent, and only for agents registered with Amex, and not where the intent was subjective. Nothing covers an instruction the customer did sign and did not mean.

That is the frame for a pilot. The payment rail will move the money. The identity layer is what decides whether the instruction behind the payment was really the customer's, whether the thing presenting it is really the agent, and whether either of them can still be stopped. This checklist is nine questions, ordered by how expensive they are to discover late. It is written for the team running the pilot on the merchant or issuer side, and it links to the protocol documents rather than summarising them, because each protocol answers the questions differently and the differences are the point.

1. Who signed the instruction, and with what

Every protocol on the table has a signed object at its centre. Google's Agent Payments Protocol calls them mandates: "tamper-proof, cryptographically-signed digital contracts that serve as verifiable proof of a user's instructions". In its v0.2 specification the Checkout Mandate gives the merchant cryptographic proof that the shopping agent is authorised to buy the checkout it assembled, and the Payment Mandate gives the credential provider, the network and the processor proof that it is authorised to pay for it; both are SD-JWTs. Mastercard's Verifiable Intent draft describes a layered chain of SD-JWTs from credential provider to user, user to agent, and agent execution, "a tamper-evident chain providing cryptographic evidence that an AI agent's actions were within the scope delegated by a human user". Visa's rules require the provider to verify the cardholder under the Visa Intelligent Commerce specifications before the instruction is stored, and since April 2026 a wallet must verify the cardholder through a consumer device cardholder verification method at the moment it presents the instructions.

The pilot question is what "signed" means at the moment the customer signs. A mandate signed by a key that the agent platform holds on the customer's behalf is a record of what the platform says the customer wanted. A mandate signed by a key bound to the customer's device, unlocked by the customer, is evidence of what the customer wanted. The difference matters in a dispute, and the rules have already decided which side of that dispute your customer is on.

Check: the instruction is signed by a customer-held authenticator, the signing ceremony shows the constraints being signed (merchant, ceiling, expiry), and the platform keeps the signed object itself rather than a summary of it.

2. Human present, human not present

Both AP2 and the Visa rules distinguish a purchase the customer approves item by item from a purchase the customer pre-authorised by constraint. AP2's v0.2 release exists to add the second: in Human Not Present flows "the User sees and approves a set of constraints over what closed Checkout and Payment would meet their intent", and the agent then generates the cart mandate itself once the conditions are met. The Visa glossary definition of an agentic transaction is the second case by construction, since it is completed "without direct interaction between the Cardholder and Merchant".

Visa's own survey of 2 April 2026 found that 60 percent of Americans "would not allow AI spending without approval". A pilot that starts in the human-not-present mode is therefore starting with the minority of customers who will accept it and the majority of the liability. The sensible sequence is to run human-present first, measure how often the customer declines the assembled cart, and treat that decline rate as the estimate of how often a constraint-only mandate would have bought something the customer did not want.

Check: the pilot's mode is explicit in the mandate, the constraints in a human-not-present mandate are enumerable (merchant, category, ceiling per transaction, ceiling per period, expiry), and the customer can see the list of purchases made under a standing mandate as easily as the mandate itself.

3. The agent has to prove it is the agent

Merchants have spent a decade blocking bots. An agent that shops on a customer's behalf is a bot with a reason to exist, and the merchant needs a way to tell the two apart that does not depend on a user-agent string. Visa's Trusted Agent Protocol answers this with HTTP Message Signatures (RFC 9421): the agent signs its requests with a key the merchant fetches from a well-known JWKS endpoint, the Signature-Input header carries the metadata, the signature's created and expires values may be no more than eight minutes apart, and merchants keep nonce records for eight minutes. Visa's December 2025 release framed the protocol as "helping merchants distinguish between malicious bots and legitimate AI agents acting on behalf of consumers".

Registration is the other half. Visa's rules require agentic enablers to enrol in the Intelligent Commerce programme and register with Visa; Mastercard's September 2025 rollout added an Agent Sign-Up; Amex's protection applies only to agents "registered with American Express". A pilot that accepts an unregistered agent is accepting a party nobody can be asked about afterwards.

Check: every request the agent makes to your systems carries a signature you can verify against a published key, the key is tied to a registration you can look up, and a request with a missing, expired or replayed signature is refused rather than downgraded to an anonymous session.

4. What the credential is scoped to

The old model was a card number stored in a vault and charged when needed. Every new protocol replaces it with a token that carries its own limits. Stripe's Shared Payment Token, in the Agentic Commerce Protocol, lets an application initiate a payment without exposing the buyer's credentials, and is "scoped to a specific merchant and cart total"; Stripe's October 2025 description adds that tokens "can be scoped to a specific business, limited by time or amount, revoked at any time, and monitored via webhook events". OpenAI's delegated payment specification expresses the same shape as an allowance with a maximum amount, an expiry and a merchant identifier. Mastercard's Agentic Tokens build on the tokenisation behind contactless and card-on-file; Visa's AI-Ready Cards replace card details with tokenised credentials and let the consumer set spending limits and conditions.

The question for the pilot is whether your integration honours those limits or merely receives a token that has them. A token scoped to one merchant and one cart total is only as narrow as the checkout it was minted for: if your cart can change between minting and capture, the scope is a formality.

Check: the amount and merchant in the token match the amount and merchant at capture, the pilot never stores a credential that outlives the mandate that produced it, and a token's revocation is tested end to end (revoke, then attempt capture, then confirm the decline) before the first real customer.

5. Expiry is a security property

Visa's rule 4.1.24.3 requires the provider to "clearly state the expiration date of the Cardholder-defined payment instruction". AP2 mandates and the ACP delegated token both carry expiry. The Trusted Agent Protocol's eight-minute signature window is expiry at the request level. Each of these exists because a standing authorisation is the agentic version of the standing privilege we described for OAuth scopes granted to agents: a grant that outlives its purpose becomes an asset for whoever compromises the agent next.

Three clocks need to agree. The mandate's expiry, the token's expiry and the agent's own session expiry are set by three different parties, and the pilot should establish which one is shortest and confirm that the others cannot extend it.

Check: no mandate in the pilot is open-ended, a standing mandate's expiry is shorter than the customer's expectation of forgetting about it, and re-authorisation requires the customer and cannot be performed by the agent.

6. The instruction can be forged from inside the conversation

The distinctive failure of an AI agent is that its instructions arrive as text, and text from the wrong source looks like text from the right one. In July 2025 Brave reported to Perplexity that hidden instructions in a Reddit comment could make the Comet browser's assistant, asked to "summarize this page", read the user's email, trigger a one-time code, read it from Gmail and post both back to Reddit; the patch was confirmed in August. In October 2025 Brave showed the same class of attack through near-invisible text in screenshots, affecting Comet, Fellou and Opera Neon, and put the consequence plainly: "if you're signed into sensitive accounts like your bank or your email provider in your browser, simply summarizing a Reddit post could result in an attacker being able to steal money or your private data". OWASP's Top 10 for Agentic Applications, published in December 2025, opens with Agent Goal Hijack and includes Identity and Privilege Abuse and Human-Agent Trust Exploitation. And in February 2025, without any attacker at all, OpenAI's Operator placed a USD 31.43 grocery order the user had not authorised after being asked to compare prices.

Signed mandates are the structural answer: a mandate signed by the customer's key cannot be conjured by a paragraph of hostile text, however persuasive. Brave's recommended mitigation is the same principle at the model level, separating trusted user requests from untrusted page content and requiring "explicit user interaction for security and privacy-sensitive tasks". A pilot that lets the agent both read arbitrary web content and generate a cart mandate under a standing authorisation has connected the two things the attack needs.

Check: the agent cannot create or widen a mandate; it can only act within one the customer signed. Content the agent reads while shopping never reaches the mandate-signing surface. The pilot has a written injection test, run against the shopping flow, before launch.

7. Delegation has a chain, and the chain has to be revocable

An agent that books travel spawns sub-tasks; a platform that runs many agents delegates from an orchestrator. Each hop is a place where scope can widen quietly, which is the subject of our posts on scope poisoning in delegation chains and sub-agent trust propagation. The Model Context Protocol's authorization specification, revision 2025-06-18, addressed the most common version of the widening: MCP clients must implement PKCE and RFC 8707 resource indicators so a token is issued for one server, servers must validate that a token was issued for them, and "the MCP server MUST NOT pass through the token it received from the MCP client". Those are the minimum for a chain that does not turn one grant into many.

On our own platform the delegation model is deliberately small. A delegate is created, listed, revoked or verified through four actions, verification needs no user session so a counterparty can check standing without holding your credentials, and each delegate carries a revocation floor: a trust score below it, per the trust engine, recommends full revocation rather than narrowing. When a hard signal lands on the delegating human, a SIM swap or a port-out, the revocation cascade invalidates the affected delegations and every negotiation they anchor.

Check: every hop in the pilot's delegation chain narrows scope or keeps it; none widens it. Revoking the root revokes the leaves. Revocation is tested against a live sub-agent rather than read off the design document.

8. Agent-to-agent trust is measured at transaction time

Where the counterparty to your customer's agent is another agent, the merchant's or a marketplace's, the question becomes how much either side should trust the other for this transaction. Our A2A handshake answers it with a number. Seven actions (initiate, attest, negotiate, status, invalidate, lookup, renew) produce a combined trust coefficient from both agents' standing, and the coefficient maps to a state: full trust at 0.70 and above, read-only from 0.40, verify-only from 0.20, automatic revocation below. Environmental evidence moves it. Network jitter above 150 milliseconds subtracts up to 0.20 at a full second; a fresh SIM signal on the delegating human, no older than 300 seconds, adds up to 0.03; recovery from a degraded state runs at 0.05 per hour, so an agent that misbehaved this morning is not back to full trust this afternoon. The invalidate action is reserved for the platform's own signal path, so neither agent can burn down the other's sessions.

None of that replaces a network's rules or a signed mandate. It sits underneath them: a mandate says what the customer allowed, the coefficient says how far the other party's agent has earned the benefit of the doubt right now.

Check: the pilot has a defined trust state per counterparty agent, the state is read at transaction time rather than at onboarding, and a state below the threshold for the purchase amount blocks the purchase rather than logging it.

9. The evidence pack exists before the first dispute

The Visa rules require the order confirmation for an agentic transaction to be available to the cardholder for at least 120 days from the processing date, and the compelling-evidence rules now include login identifiers for an agentic payment provider, in clear text, as a value the cardholder recognises. AP2's design intent is that in a dispute "the Checkout Mandate and Receipt, and Payment Mandate and Receipt can be brought together to provide a non-repudiable picture of the transaction". Amex's protection is conditioned on the customer first attempting a return with the merchant.

So the evidence you will need is known in advance: the signed mandate, the receipt bound to it, the agent's signature on the request, the registration the key belongs to, the token's scope at capture, and the revocation log. A pilot that can produce those six for any transaction in under a day has done the work. A pilot that has to reconstruct them from application logs has not, and the liability question will be settled by whoever has the better records.

One more evidence item is not about the card at all. Regulation (EU) 2024/1689, the AI Act, requires from 2 August 2026 that people be told they are interacting with an AI system at the latest at the first interaction. A merchant whose customer service is now talking to a customer's agent, and a platform whose agent is talking to a merchant's, should each be able to show that the disclosure happened.

Check: for a sampled transaction the pilot can produce the six artefacts above from its own stores, without asking the agent platform, and can show the AI disclosure for both sides of the conversation.

The checklist, on one page

Left open

The rails will change under the pilot. AP2 is at v0.2 and has just changed hands to the FIDO Alliance; Verifiable Intent is a draft; ACP has revised five times since September 2025; the Visa rules added a wallet requirement in April 2026 that was not there in October 2025. A checklist written against today's documents is a starting point, and the pilot's own change log, which document version each control was tested against, is part of the evidence pack.

It also does not settle who should carry the loss when an agent buys the wrong thing under a valid mandate. The card rules have placed it on the cardholder, Amex has carved out agent error for registered agents, and everyone else's terms are being written now. That is a contract question, and the identity layer's job is to make sure that when the contract is tested, the record of what was authorised, by whom, for how long, and revoked when, is not in dispute.

The agentic identity overview maps the delegation, trust and revocation model above onto the platform; the handshake post has the coefficient math for anyone who wants to argue with it.

Start free · Test the API