Agentic Commerce Identity: AP2, FIDO and Agent Payments

AI agents are starting to buy things on people's behalf, and the payments system was built on the assumption that a human clicks "buy". That raises questions the industry has never had to answer at scale: which agent is this, did the customer authorise this purchase with these limits, which credential pays, and who is accountable when it goes wrong. Since 2025, card networks, payment providers, AI companies and standards bodies have published protocols to answer those questions. This guide explains the identity model behind agentic commerce, the main initiatives and how they fit together, the threats, and what merchants, payment and fraud teams, and enterprises deploying purchasing agents should do now. Several protocols are early drafts, so check the linked sources for the current position.

Key takeaways

Three things must be proven: the agent's identity, the user's authorisation (intent and limits), and the binding of the payment credential to that agent and that authorisation.
Signed evidence replaces shared secrets: emerging approaches use signed agent requests, verifiable mandates and scoped, agent-specific payment credentials instead of giving agents card numbers or passwords.
Standards work has consolidated at FIDO: on 28 April 2026 the FIDO Alliance announced agentic authentication and payments workstreams, with Google contributing the Agent Payments Protocol (AP2) and Mastercard contributing Verifiable Intent.
Merchants need a middle path: recognise legitimate agents cryptographically, step up for risky purchases, and stop treating all automated traffic as either hostile or trusted.
Authority must live outside the model: limits, approvals and audit trails belong in signed mandates, credentials and policy checks, because prompt injection and memory poisoning can change what an agent believes it was asked to do.

The identity problem in agentic commerce

The AP2 project notes that payment systems assume a human is directly clicking "buy" on a trusted website, an assumption an autonomous agent breaks. The FIDO Alliance makes the same point about authentication: current models were designed for direct human interaction, so users may be asked to share credentials, and services lack interoperable ways to verify who authorised an action, under what conditions and with what limits. Five questions follow.

Question	Why it is hard	Evidence that answers it
Who is the agent?	A merchant must tell a legitimate shopping agent from a bot or fraudster. IP allowlists, User-Agent strings and shared API keys have significant limitations, according to the IETF Web Bot Auth charter.	Signed HTTP requests verifiable against the agent operator's published keys
Who authorised it, and for what?	"Buy concert tickets under £100 for Friday" is different from "buy anything", and the limits must be checkable by others.	A signed mandate or intent credential stating amount, merchant, item and time constraints
Is the human present?	Some purchases happen while the user watches; others happen later, autonomously, from earlier instructions.	A human-present confirmation at checkout, or a pre-authorised "human not present" mandate
Which credential pays?	A real card number or account password in an agent's context can be leaked, replayed or misused.	A tokenised credential scoped to the merchant, amount and expiry, revocable by the user
Who is liable?	Dispute rules were written for human purchases. AP2 asks whether the user, agent developer, merchant, issuer, PSP or orchestration layer is accountable.	A tamper-evident record linking mandate, agent, transaction and any approval

Liability is not theoretical. In the Air Canada Chatbot Ruling 2024, a tribunal rejected the airline's argument that it was not responsible for what its chatbot told a customer. An agent acting in a commercial setting acts with someone's authority, so that authority has to be defined and recorded. See the Agentic AI Identity Guide.

How the trust model fits together

Most of the protocols share a role-based model. Keeping the roles separate stops one compromised component from holding everything needed to commit fraud.

User: the person or organisation whose money is spent. They authenticate to the agent platform and sign or approve the instructions.
Agent and agent platform: the software that assembles the purchase, and the operator that runs it and holds its signing keys.
Merchant: remains the merchant of record in ACP and UCP, and decides which agents and transactions to accept.
Credential provider and payment service provider: hold the real payment method and issue a scoped credential for this purchase.

The AP2 design principle is "verifiable intent, not inferred action": trust is anchored to deterministic, non-repudiable proof of what the user asked for, not to the agent's account of it. See the OAuth Token Exchange and Delegation Guide.

Main initiatives

Initiative	Origin and status	Identity focus
Agent Payments Protocol (AP2)	Announced by Google on 16 September 2025; v0.2 released on GitHub and contributed to the FIDO Alliance on 28 April 2026	Verifiable digital credentials (Checkout and Payment Mandates) for human-present and human-not-present purchases; an extension for A2A and UCP
Verifiable Intent	Announced by Mastercard in March 2026, according to PYMNTS; co-developed with Google, designed to work with AP2, contributed to FIDO	SD-JWT delegation chain binding issuer, user and agent, with machine-verifiable constraints and selective disclosure
FIDO Alliance workstreams	Announced 28 April 2026: Agentic Authentication Technical Working Group and Payments Technical Working Group	Verifiable user instructions, agent authentication and trusted delegation for commerce
Agentic Commerce Protocol (ACP)	Developed by Stripe and OpenAI; open source under Apache 2.0	Agent-initiated checkout with secure sharing of payment credentials; merchants accept or decline per agent or per transaction
Universal Commerce Protocol (UCP)	Open protocol co-developed by industry partners	Discovery to checkout and order management; OAuth 2.0 for identity linking and AP2 for payment mandates
Visa Trusted Agent Protocol	Visa developer programme for merchants and infrastructure providers	Recognising Visa-approved agents through RFC 9421 HTTP message signatures
Card network token programmes	Mastercard Agent Pay, Visa Intelligent Commerce and the American Express ACE Developer Kit, as named in Stripe and FIDO material	Tokenised credentials provisioned for agent-initiated transactions

The FIDO workstreams bring competing schemes into one forum: at launch the Agentic Authentication group was chaired by members from CVS Health, Google and OpenAI, and the Payments group by members from Mastercard and Visa. See the Agent Identity Standards Tracker for status.

Mandates and verifiable intent

A mandate is the signed record of what the user authorised: it turns "the agent says the user wanted this" into something a merchant, network or issuer can check.

AP2 mandates

AP2 builds trust from verifiable digital credentials (VDCs): tamper-evident, cryptographically signed objects. It defines two mandate types, each with an open and a closed stage:

Checkout Mandate: references the items and purchase details negotiated between agent and merchant, and is shared with the merchant. Open, it captures the user's constraints and goals before a cart is final; closed, it captures authorisation for a specific finalised checkout.
Payment Mandate: authorises payment against a specific instrument. Open, it captures constraints such as budget and allowed instruments; closed, it binds a transaction amount to a finalised checkout.

The VDCs are chained into an audit trail for human-present and human-not-present transactions. AP2 v0.2 added "Human Not Present" payments, which Google describes as letting agents execute payments autonomously, such as buying limited-run tickets as soon as they go on sale, based on pre-authorised instructions.

Verifiable Intent

Verifiable Intent describes itself as an open specification for cryptographic agent authorisation: an SD-JWT delegation chain binding issuer, user and agent through key confirmation claims, where each layer constrains the next. It lists eight constraint types, including amount bounds, merchant allowlists, budget caps and recurrence terms, and integration mappings for AP2, ACP and UCP. Selective disclosure means each party sees only the data it needs. See the Verifiable Credentials Guide.

What a good mandate contains

Whatever the protocol, a mandate should state the principal, the agent, permitted merchants, amount and budget limits, a validity window, whether a human must confirm, and how it is revoked. The user should approve it with phishing-resistant authentication, the FIDO "verifiable user instructions" focus area. See the Passwordless and Passkeys Guide.

Recognising agents at the merchant

Most bot management was designed to block automation. Agentic commerce needs to let good agents through while still stopping abuse, and the emerging answer is a cryptographic signature on each request.

Visa Trusted Agent Protocol: a trusted agent includes a message signature in its request. The merchant reconstructs the signature base from request attributes and verifies it with the agent's public key, using RFC 9421 HTTP Message Signatures. Visa says the protocol also describes signatures for consumer recognition and payment.
IETF Web Bot Auth: the working group is standardising cryptographic authentication of automated clients to websites, including AI agents acting for end users. Its charter states that authenticating the end user is out of scope, so a verified agent signature tells you which agent and operator, not which customer or what they authorised.
Per-agent decisions: ACP lets businesses accept or decline transactions per agent, per transaction or by custom logic, which needs a reliable agent identifier to work.

The design is layered: the agent signature gets past bot controls, the customer's account or token identifies the buyer, and the mandate proves the scope. See the Bot Management Guide.

Payment credentials for agents

An agent should never hold a reusable card number. The pattern across the initiatives is a credential minted for one agent, one merchant and one purchase or budget.

Stripe's shared payment tokens (SPTs), used with ACP, show the controls in practice. An SPT is a scoped grant to use the customer's payment method, granted by the agent to a seller with usage and expiry limits; the agent sets the maximum amount to match the transaction total. An SPT can be resolved only once, the agent can revoke it, and a deactivation event fires when it is consumed, resolved, expired or revoked. Stripe says it may use tokens issued through Mastercard Agent Pay, Visa Intelligent Commerce and the American Express ACE Kit, and when a seller resolves an SPT for a third-party processor the credential type returned (fpan, network_token, agentic_token or dpan) depends on the account's configuration; the fpan type carries the card number itself. See the PCI DSS 4.0 Guide.

Merchants should confirm with their payment provider which credential types they will receive, because a full card number brings PCI scope back.

Principles for secure agentic payments

Never give agents raw credentials. Use tokenised, agent-specific credentials with merchant, amount and time limits, revocable by the user.
Make authorisation explicit and verifiable. Capture the user's intent as a signed mandate with clear limits, approved with phishing-resistant authentication, and check it at the merchant and payment provider, not only inside the agent.
Re-check authority at execution. OWASP describes a procurement agent that completed a purchase hours after approval, although the user's spending limit had since been reduced. Evaluate limits at the moment of payment.
Step up for risk. Require real-time user approval for purchases outside the mandate, above thresholds, to new merchants or for account changes. See the AI Agent Authorisation Guide.
Separate preparing from approving. The agent that builds a purchase should not also approve it, and enterprise agents should not approve their own suppliers. See the Segregation of Duties Guide.
Keep an audit trail linking mandate, agent, credential, transaction and approval, for disputes and fraud investigation. AP2 aims to provide a non-repudiable, cryptographic audit trail for every transaction.

Threats to watch

The OWASP Top 10 for Agentic Applications for 2026 includes several payment scenarios, mapped below.

Threat	OWASP Agentic entry	What limits it
Prompt injection on product pages or reviews steering agents to other sellers, higher prices or money transfers	ASI01 Agent Goal Hijack (OWASP gives the example of a financial agent manipulated into transferring money)	Mandate limits enforced outside the model; merchant allowlists in the credential
Stale or inherited authority used after limits change	ASI03 Identity and Privilege Abuse (workflow authorisation drift)	Short-lived, single-use credentials; checks at payment time
Poisoned memory leading to bookings at a false price	ASI06 Memory and Context Poisoning (OWASP's travel booking example bypasses payment checks)	Price and amount bound into the closed mandate; memory hygiene
Forged or impersonated agents and approver agents	ASI07 Insecure Inter-Agent Communication; ASI10 Rogue Agents (an injected approval agent misleads a payment agent)	Signed agent requests; verified agent identity for every hop
Users persuaded to approve fraudulent payments recommended by an agent	ASI09 Human-Agent Trust Exploitation	Approval screens showing the signed details, not the agent's summary

Account takeover of the user's agent account, giving attackers stored mandates and purchasing power. See the Account Takeover Prevention Guide.
Refund and promotion abuse at machine scale, and fraud that hides in legitimate agent traffic. See the Payment Fraud Guide.
Agents as attackers of merchants: in the AI Agent Retail Card Theft Campaign 2026, according to Gambit Security, open-source AI agents compromised online retailers, planted card skimmers and stole more than 600,000 unexpired payment cards from two companies.

See the Browser and Computer-Use Agent Guide and the Prompt Injection Guide.

Common failure patterns

Letting the model hold the limits: spending rules written only into the system prompt can be talked away. In the Chevrolet Dealer Chatbot 2023, a user told a dealer's sales bot to agree with anything and it called a $1 offer for a Tahoe "legally binding". No sale was honoured, but the bot had no authority boundary outside the model.
Card details or passwords in the agent's context: credentials pasted into a browser agent or stored in its memory can be extracted or reused.
Blocking all automation, or trusting it all: blanket rules either break legitimate agent checkouts or admit any client that claims to be an agent.
Treating a verified agent as a verified customer: an agent signature proves the operator, not the buyer or their instructions; Web Bot Auth explicitly leaves end-user authentication out of scope.
Open mandates with no expiry: "human not present" instructions left valid indefinitely become standing purchasing power for whoever compromises the account.
Approval screens that show the agent's summary: if users approve a description instead of the signed amount and merchant, a manipulated agent can get approval for something else.

Detection and monitoring

Agent transactions need their own telemetry, because fraud signals look different when software shops.

Tag every agent transaction: record the verified agent identity, operator, mandate reference, human-present flag and credential type with each order.
Compare transaction to mandate: alert when an amount, merchant or category falls outside the signed constraints, or when a merchant receives a payment without a matching closed mandate.
Watch signature failures: invalid signatures, unknown keys, or a known agent's User-Agent without a valid signature suggest impersonation.
Track token lifecycle: monitor revocations, repeated resolution attempts and tokens used after a mandate was withdrawn.
Baseline agent behaviour per user: sudden new merchants or bursts of purchases suggest account takeover or goal hijack.

See the AI Agent Observability and Incident Response Guide.

Framework mapping

Control IDs below were checked against the published text of each framework. None is specific to agent payments; the mapping shows where these controls fit in an existing programme.

Control area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1	OWASP
Distinct, owned identity per purchasing agent	PR.AA-01	IA-4, IA-9	5.16 Identity management	Control 5	ASI03, NHI9
Agent authentication at the merchant (signed requests)	PR.AA-03, PR.AA-04	IA-8, IA-9, SC-8	8.5 Secure authentication	Control 6	ASI07, NHI4
Verifiable mandates and spending limits	PR.AA-05	AC-6	5.15 Access control, 5.18 Access rights	Control 6	ASI02, ASI03
Scoped, short-lived payment credentials	PR.AA-05, PR.DS-02	IA-5, SC-13	5.17 Authentication information, 8.24 Use of cryptography	Control 3	NHI7, NHI2
Step-up approval and separation of duties	PR.AA-05	AC-5, IA-11	5.3 Segregation of duties	Control 6	ASI09
Non-repudiable audit trail	PR.PS-04	AU-2, AU-10, AU-12	8.15 Logging	Control 8	ASI03
Monitoring agent transactions	DE.CM-03, DE.CM-09, DE.AE-02	SI-4, AC-2(12), AU-6	8.16 Monitoring activities	Control 8, Control 13	ASI10
Agent platforms and payment providers as suppliers	GV.SC-07	SA-9, SR-6	5.19, 5.20, 5.22 supplier controls	Control 15	ASI04, NHI3

Metrics that show progress

Metric	What it shows	Target direction
Share of agent transactions with a verified agent signature	How much agent traffic you can attribute to a known operator	Up
Share of agent payments backed by a signed mandate	Whether authorisation is evidenced rather than inferred	Up
Agent payments made with a full card number	Raw credential exposure and PCI scope	Down, towards zero
Transactions outside mandate constraints caught before authorisation	Whether limits are enforced outside the agent	Up as a share of out-of-mandate attempts
Open (human-not-present) mandates past their review date	Standing purchasing power left behind	Down
Procurement agents with a named owner and scoped instrument	Enterprise governance coverage	Up, towards 100%

See the Identity Security Metrics Guide.

Implementation roadmap

Phase	Merchants and payment teams	Enterprises deploying purchasing agents
First 30 days	Measure agent traffic today; review how bot management treats it; ask payment providers which agent protocols and credential types they support	Inventory agents that can spend money; name an owner for each; remove any stored card numbers or shared passwords
Days 31 to 90	Pilot signature verification for known agents; tag agent orders in fraud and dispute systems; define step-up rules for high-risk purchases and account changes	Issue scoped payment instruments with merchant, amount and expiry limits; require approval above thresholds and for new suppliers
Days 91 to 180	Accept mandate-backed payments through your provider; alert on mandate mismatches; update dispute procedures for agent purchases	Move to signed mandates where your platforms support them; review open mandates quarterly; test agents against goal hijack and memory poisoning

See the Multi-Agent and A2A Security Guide for agents that delegate purchasing to other agents.

Practitioner checklist

Merchants

Review how your bot management treats AI agent traffic, and plan to verify legitimate agents by signature rather than blocking all automation.
Track which agent protocols and credential types your payment providers support, and avoid receiving full card numbers from agents.
Keep step-up authentication for high-risk transactions and account changes. See the Customer IAM (CIAM) Guide.
Check the buyer's account and the mandate separately from the agent's signature.

Payment and fraud teams

Update fraud models for agent-initiated transactions and tag every agent order with agent, mandate and human-present data.
Review dispute processes for agent purchases, using the mandate and approval records as evidence.
Alert on transactions outside mandate constraints and on token use after revocation.

Enterprises deploying purchasing agents

Give procurement agents their own identities, named owners and scoped payment instruments with limits.
Require approval above thresholds and for new suppliers, showing approvers the signed details.
Apply segregation of duties: the agent that prepares a purchase should not also approve it.
Protect agent memory and tool inputs from poisoning. See the AI Agent Memory Security Guide.
Set expiry dates on every open mandate and review them quarterly.

Agentic Commerce Identity Guide: AI Agents That Buy