AI agent payments enable software agents to make payments and purchase goods, APIs, and services on behalf of an individual or organization without requiring human interaction on each purchase transaction.
In 2026, such transactions involve four logical layers: agent identity, signed proof of authorization, a scoped payment credential, and an auditable record. The various payment initiatives (AP2, ACP, x402, Visa's Trusted Agent Protocol, Mastercard Agent Pay) address these layers incompletely.
The technical challenges are largely complete, but the security risks (tool poisoning, over-scoped credentials) and liability exposure (who pays if an agent purchases the wrong thing) remain critical issues.
This document provides the technical details, the MCP attack surface, and the liability gaps.
Key Highlights
- No single protocol has won. AP2 handles signed authorization, ACP handles agent-to-merchant checkout, and x402 handles pay-per-request stablecoin charges. Visa and Mastercard are adapting their card tokens to work alongside them.
- MCP is a connection layer, not a payment layer. Mercury's hosted MCP server, for example, is read-only by design. Moving money still goes through a separate API with its own credentials.
- MCP infrastructure is an active attack surface. An architectural flaw disclosed by OX Security in April 2026 was estimated to affect around 200,000 instances across a supply chain with over 150 million package downloads.
- Amex Agent Purchase Protection is the first major liability commitment from a card network, but it is conditional: the agent must be registered, and Amex must receive the cardholder's authenticated purchase intent.
- Legal liability is unsettled. Whether granting an agent access to an account satisfies Regulation E's authorization standard is still an open question.
- Safe agent payments depend on controls, not model quality: per-agent identity, hard spend caps, human approval for irreversible actions, and immutable audit logs.
Why AI Agent Payments Break the Checkout Model
Your procurement agent finds a cheaper cloud vendor at 2 a.m., negotiates a quote, and pays the invoice. Your payment stack was built to answer one question: is a human present and approves this? Now the answer is no, and for every control downstream (3-D Secure, CVV prompts, step-up auth) it assumes no.
Markets are already changing: Alipay launched an AI payment service in China in 2026, Mastercard announced Agent Pay for Machines on June 10, 2026, for agent-to-agent payments, and American Express released an agentic commerce developer kit in April. AI agents in fintech are past the pilot stage at the infrastructure layer, if only just beginning to see adoption at the consumer level.
How Do AI Agent Payment Systems Work? The Four-Layer Flow
Most AI agent payment systems can be understood through four key layers: identity, authorization, credentials, and evidence. Each layer plays a specific role in making payments secure, controlled, and traceable. Use this framework to evaluate an AI payment solution and identify gaps before deploying it in production.
1. Identity: Who Is the AI Agent, and Who Does It Represent?
Every AI agent needs a verifiable identity that is separate from the user's login credentials. This helps payment networks identify which agent is initiating a transaction and which human or business it represents. For example, American Express uses agent registration to help establish trust, while Visa's Trusted Agent Protocol connects agent authorization with verified, human-linked credentials.
2. Authorization: What Did the Human Actually Approve?
AI payment authorization defines what an agent can purchase, how much it can spend, and under which conditions it can act. Google's Agent Payments Protocol (AP2) uses signed mandates, including Intent, Cart, and Payment Mandates, to create a verifiable record of the payment process. This helps businesses establish what the user approved instead of relying only on a valid payment token.
3. Credentials: How Does the AI Agent Make the Payment?
An AI agent should not receive unrestricted access to a user's payment details. Instead, it can use controlled credentials, such as network tokens, virtual cards with spending limits, or stablecoin wallets with enforced restrictions. These controls help limit financial exposure if an agent makes an incorrect purchase or behaves unexpectedly.
4. Evidence: Can You Reconstruct the Transaction Later?
A reliable AI payment system must maintain records of the user's intent, the shopping cart, the agent's identity, and the final transaction. These records help businesses investigate disputed charges and determine whether a payment followed the user's instructions. Without clear and verifiable evidence, resolving disputes and assigning liability becomes much more difficult.
AI Agent Payment Protocols Compared (AP2 vs ACP vs x402)
AI agent payment protocols are converging but not interchangeable. An agent built for one cannot assume it works on another's rails.
| Protocol | Backed by | What it solves | Payment rails | Best fit |
|---|---|---|---|---|
| AP2 (Agent Payments Protocol) | Google, FIDO Alliance working groups, 60+ partners incl. Mastercard, Amex, PayPal | Signed proof of what the human authorized (Intent, Cart, Payment mandates) | Cards or stablecoin | Authorization and audit trail |
| ACP (Agentic Commerce Protocol) | OpenAI, Stripe; supported by Shopify, Salesforce, PayPal | Agent-to-merchant checkout with a payment token handoff | Cards via Stripe | Human-present checkout in chat |
| x402 | Coinbase; now under a Linux Foundation project with Visa, Mastercard, Ripple involved | Pay-per-HTTP-request, no signed approval step | Stablecoin (e.g., USDC on Base) | API calls, data feeds, machine-to-machine |
| Visa Trusted Agent Protocol | Visa, with Cloudflare | Agent identity and signed intent on Visa rails | Visa network | Visa-accepting merchants |
| Mastercard Agent Pay | Mastercard | Agentic Tokens plus Verifiable Intent on Mastercard rails | Mastercard network | Enterprise and bank-grade flows |
There are two important notes for architects: Firstly, AP2 is not a replacement for the network schemes. As of April 2026, payment providers can emit AP2 mandates, which Mastercard accepts as Verifiable Intent. Secondly, x402 deliberately does not include signed approval to make it faster, so one should provide their own spend controls on top.
When building an agent that needs to spend money, one should rejoice at the prospect of building an agent architecture where authorization, spend limits, and audit logging are baked in from the first transaction. See our AI agent development services.
Model Context Protocol Payments: What Can MCP Do, and What Can't It Do?
The term Model Context Protocol (MCP) payments can be confusing because MCP does not handle the entire payment process. It standardizes how AI agents discover and use tools, which makes AI integration easier, but it does not define payment authorization, money transfers, or liability. These responsibilities depend on the payment APIs, security controls, and approval processes connected to the agent.
Mercury MCP Payments: Why Is Access Read-Only?
Mercury's hosted MCP server allows AI tools such as Claude and ChatGPT to access financial information, including account balances, transactions, cards, and recipients through OAuth. Mercury labels this service as Beta. According to Scalekit's September 2026 analysis, its MCP tools support read-only operations, allowing agents to review payment information without directly initiating transactions.
Where Does the Money Actually Move?
Actual payment operations use Mercury's separate REST API, which follows its own authentication and permission rules. According to the same analysis, agents can submit payments for human approval under certain conditions, while direct payment transfers require an IP allowlist. Mercury also supports agent cards, where a human creates a virtual card and provides the agent with controlled access to its credentials and spending limits.
What Is the Operational Risk?
Mercury reportedly downgrades unused write permissions and deletes unused tokens after 45 days, according to Scalekit. As a result, an agent that successfully reads financial data for weeks may encounter permission errors when it attempts a payment for the first time. If administrators receive the relevant notifications instead of the engineering team, the issue may go unnoticed until the payment workflow fails.
What Does This Mean for AI Payment Security?
The main lesson is that MCP access and payment authority are separate permissions. An agent may be allowed to read financial information without having the authority to move money. Businesses should configure these permissions independently, monitor credential expiry, and regularly test payment workflows that require write access.
AI Payment Authorization: Three Patterns and Their Trade-offs
Which pattern you choose determines your control surface and your liability exposure.
| Pattern | How it works | Control strength | Main risk | Use when |
|---|---|---|---|---|
| Network token + signed intent (Visa, Mastercard, Amex) | Agent presents a registered credential and verified intent; network applies fraud and dispute rules | High: identity and intent are verified | Merchant and agent must both be integrated | Consumer and enterprise card purchases |
| Stablecoin per-request (x402) | Agent signs an on-chain payment per HTTP call | Medium: depends on your wallet limits | No built-in approval or chargeback | Micropayments, machine-to-machine |
| Bank API with approval queue | Agent proposes payments; human or policy engine approves | High for money out; slower | Approval fatigue; token lifecycle | Vendor payouts, B2B finance workflows |
A practical rule: the more irreversible the payment rail, the more human approvals you need upstream. According to the Coalition for Secure AI's guidance, published after RSAC 2026, around systems and agents that process invoices and cut checks: use of ephemeral identities, access delegation, policy-based authorization, ongoing assessment, and human-in-the-loop for irreversible actions.
AI agent payment risks fall into two groups: attacks on the agent's reasoning, and attacks on the infrastructure it depends on.
AI agent payment risks fall into two groups: attacks on the agent's reasoning, and attacks on the infrastructure it depends on.
The risks we see most often
- Tool poisoning. Microsoft's June 2026 security guidance walks through a finance agent whose third-party MCP tool carried hidden instructions to gather recent unpaid invoices and send them in an enrichment call.
- Supply chain compromise. In March 2026 the LiteLLM package, a model gateway used by several agent frameworks, was reportedly backdoored on PyPI for about three hours, and a critical LiteLLM CVE appears in Cloud Security Alliance's May 2026 MCP research note.
- Over-scoped credentials. One shared service account makes every payment look identical in the logs.
- Authorization drift. The agent executes a purchase that technically fits its permissions but deviates from what the user meant.
- Correlated behavior. Many agents reacting to the same signal can create herding in payment timing or routing, a risk the IMF note calls out.
Seven Security Controls for Safer AI Agent Payments
1. Give Every Agent Its Own Identity
Assign each AI agent a separate identity with permissions limited to its specific tasks. For example, a returns agent should be allowed to process approved refunds but not initiate bulk payouts. This makes it easier to track agent activity and reduces the risk of unauthorized transactions.
2. Set Spending Limits Outside the AI Model
Enforce payment limits through the payment system rather than relying on instructions in the AI prompt. Set maximum amounts per transaction, daily spending caps, and approved merchant or recipient lists. These controls help prevent an agent from exceeding its authority, even if it makes an unexpected decision.
3. Require Human Approval for High-Risk Payments
Require human approval before an agent performs high-risk or difficult-to-reverse actions. Examples include wire transfers, payments to new recipients, and transactions above a defined spending threshold. This adds a review step before money leaves the account and helps reduce the impact of mistakes.
4. Maintain an MCP Server and Tool Allowlist
Allow agents to connect only to approved Model Context Protocol (MCP) servers and tools. Review tool descriptions, permissions, and behavior instead of checking tool names alone. Avoid unrestricted access to all available tools, as an unsafe or compromised tool could expose sensitive financial data or payment functions.
5. Apply the Rule of Two
The Rule of Two limits the risks created when an agent combines untrusted input, access to sensitive systems, and external communication. Avoid allowing an agent to perform all three activities independently without human oversight. For payment workflows, add approval steps and separate permissions to reduce the risk of prompt injection and unauthorized transactions.
6. Log Every Agent Action
Maintain an audit log for every tool call, including the agent's identity, the authorization used, the requested action, and the result. Send these logs to your Security Information and Event Management (SIEM) system for monitoring and investigation. Detailed records help security teams identify suspicious activity and investigate payment disputes.
7. Scan and Update Dependencies
Keep agent frameworks, MCP servers, payment SDKs, and related packages updated and regularly scan them for known vulnerabilities. Pin dependency versions to maintain predictable deployments, and review new versions before introducing them into production. Configure alerts for important updates and security issues so your team can respond before they affect payment operations.
AI Agent Transaction Liability: Who Pays When the Agent Gets It Wrong?
Today the honest answer is: it depends, and the rules are still being written. AI agent transaction liability is the question that most blocks enterprise rollout.
| Scenario | Likely exposure today | Source of uncertainty |
|---|---|---|
| Agent buys something that deviates from the authenticated intent (Amex card) | Amex says it will protect eligible customers, if the agent is registered and intent was sent | Terms are conditional; agent registration specs still under development |
| Mastercard Agent Pay token disputed | Falls under existing card dispute rules, per a BlindPay comparison | Agent-specific rules not yet defined |
| Visa agent transaction disputed | Visa describes its liability terms as early and evolving, per the same comparison | Terms may change |
| Bank account agent exceeds authority (Reg E context) | Unclear whether granting an agent access meets "authorized" under Regulation E, per Fenwick | No settled case law or guidance |
| Chargeback on agent purchase | Merchants may bear fraud chargeback liability even where the consumer authorized the agent, per a Consumer Bankers Association white paper | Chargeback rules are built for human checkout |
| Agent compromised by third party | Could involve product liability, agency, and consumer protection laws | General-purpose laws not tailored to agents |
What Amex Agent Purchase Protection does and does not cover
Amex Agent Purchase Protection was announced April 14, 2026 alongside the ACE developer kit. Its published terms require that the agent be registered with Amex and integrated with the kit, that Amex receives the cardholder's authenticated purchase intent, and that the purchase deviate from that intent.
Coverage applies after the cardholder initiates a return with the merchant where possible, and it sits alongside ordinary dispute processes. Amex's own page uses forward looking language and notes that some specifications are still under development, so treat it as a commitment to design around, not a settled guarantee.
What it means for builders is that capturing signed timestamped intent now becomes your best liability defense. You cannot argue that the agent erred rather than the user if you cannot prove what the user approved.
Conclusion
AI agent payments in 2026 are a controls problem more than a model problem. The protocols exist, the card networks are shipping, and the liability rules are still catching up. Teams that win will be the ones who capture signed intent, scope every credential, and keep approval logic outside the model. Before your agent handles its first real transaction, decide who owns the loss if it is wrong.
Frequently Asked Questions
How do AI agent payments work?
AI agent payments work when an agent pays using a limited credential after you approve what it can buy. The system checks the agent’s identity, confirms your approval, completes the payment, and saves a clear record in case of disputes.
What is the Model Context Protocol in AI agent payments?
The Model Context Protocol (MCP) is a standard that lets AI agents connect to tools and data. It does not handle payment approval or liability, so you still need a separate payment API with its own permissions and spending limits.
Can Mercury MCP send payments?
No, Mercury’s MCP server is read only, so an agent can view balances, transactions, and pending approvals but cannot move money. Payments go through Mercury’s separate API, which uses its own tokens and permission rules. It is still in Beta.
What is Amex Agent Purchase Protection?
It is American Express’s commitment to protect eligible cardholders from charges caused by registered AI agent mistakes. The agent must be registered, and Amex must receive your verified purchase intent. It works alongside dispute processes. Some details are still developing.
Who is liable when an AI agent makes a wrong payment?
It depends, because the rules are not settled yet. Liability can fall on the card network, the platform, the merchant, or the user, depending on contracts, payment rails, and laws like Regulation E. Keep signed records of what you approved.
