The Mandate Is The Authorization

Money is the credential boundary's harder cousin

The agent that deleted Replit's production database held credentials it should not have had. The next agent-incident story will involve money: an agent holding a wallet, a charge no human signed off on, a transaction the operator cannot defend in dispute. Credentials let an agent act inside a system. Payment authority creates external obligations that settle, generate disputes, trigger consumer-protection rights, and invite regulatory scrutiny.

The operator question is not "Which agent wallet should we use?" That framing is too narrow and likely to lead to bad deployment choices. The real question is: when should an AI agent be allowed to initiate, authorize, or complete a payment, and what independent control plane should sit between the model and the money?

The answer is becoming clearer. Agents should not hold raw payment credentials, just as they should not hold broad production credentials. They should receive narrowly scoped payment authority at the moment of need, constrained by merchant, amount, category, time, frequency, user intent, and revocation policy. The stronger implementations do not ask the model to "be responsible." They bind payment authority to a transaction object: a cart, a quote, an API request, an invoice, a purchase order, or a checkout hash. The model can request payment authority, but a separate payment layer decides whether the request is in scope.

This is the same logic as the credential boundary, but with higher consequences. A database credential can leak information or modify a system. A payment credential can transfer value to a counterparty, create a chargeback, trigger consumer-protection rights, produce tax and reconciliation obligations, and invite AML or sanctions exposure. The boundary has to be drawn outside the model runtime. The model should not be the final arbiter of whether a transaction is allowed.

The rest of this dossier explains what each gate in the audit is testing for. The four-layer landscape names which payment surface the agent crosses. The vendor surface names which products implement which mandates. The classify-and-set-boundary sections formalize the policy engine the audit verifies. The failure-modes section names what each test is designed to catch.

The four-layer landscape

The agent-payment market is splitting into four layers. Each does a different job. Operators that pick a vendor before knowing which layer they need usually pick wrong.

Payment instruments

The most important primitive is the scoped payment instrument: a virtual card, a one-time-use card, a network token, or a delegated payment token. Stripe's Shared Payment Token is the cleanest example in the current primary-source record. SPT is a scoped grant to use a customer's payment method, granted to a single merchant, with usage limits including max amount, currency, and expiration, and no raw card credentials.

This is the right mental model. The agent does not hold the card; it holds a claim that a payment method may be used for a bounded purpose. Merchant binding prevents credential reuse elsewhere, amount and currency limits cap loss, and expiry prevents zombie authority. Isolation from raw credentials reduces both PCI exposure and prompt log leakage risk.

Visa's Intelligent Commerce and Mastercard's Agent Pay push the same concept at the network layer. Visa describes user-authenticated payment instructions, passkey authentication, network-level controls, and validation that agent requests match the authenticated user instruction. Mastercard frames Agentic Tokens as dynamic credentials tied to specific permissions and limits, with every transaction associated with a specific authorized Agent Pay interaction. The pattern across all three is converging: agent payments are not moving toward agents storing credentials. They are moving toward instrument abstraction plus intent binding.

For internal business agents, virtual cards are the most immediately deployable rail because they work with existing merchants. Ramp's Agent Cards (early access) issue tokenized credentials via Visa Intelligent Commerce, scoped to a single agent or transaction with vendor lock, spend limit, expiration, and self-destructing tokens. Lithic offers the same controls as API-first issuing infrastructure: card creation, authorization rules, KYB/KYC, merchant locking, single-use cards, and audit trails. Stripe's Issuing for agents (preview) extends the same pattern.

Commerce protocols

Commerce protocols define how an agent, merchant, payment provider, and user exchange intent, checkout state, authorization, and receipts. Three are real enough to plan around.

OpenAI and Stripe's Agentic Commerce Protocol is the most visible because it is attached to ChatGPT Instant Checkout. ACP launched in September 2025 with U.S. Etsy sellers, Shopify merchants planned, single-item purchases first, multi-item carts and regional expansion later. ACP is open-sourced, in beta, and explicitly designed so AI agents can transact without becoming the merchant of record.

Google's Universal Commerce Protocol is broader. UCP covers discovery, buying, and post-purchase support across consumer surfaces, merchants, and payment providers. Google says UCP works alongside A2A, AP2, and MCP, and that it powers checkout in AI Mode and Gemini with Google Pay and PayPal, while retailers remain seller of record. UCP defines roles for platforms, businesses, credential providers, and payment service providers.

The operator implication is narrow. ACP is a strong fit for ChatGPT-native commerce. UCP is a broader Google-led commerce layer that may matter for discovery, business agents, and post-purchase workflows. Neither should be treated as universal yet.

Trust and mandate protocols

Google's Agent Payments Protocol sits at the trust layer, not the storefront layer. AP2 v0.2 introduced human-not-present payments, enabling autonomous execution based on pre-authorized user instructions. The key concept is the mandate: a signed checkout commitment scoped to a checkout hash. The agent acts only against the thing the user or business authorized, not against a free-form interpretation of the goal. Google donated AP2 to the FIDO Alliance in April 2026, signaling that the trust layer should be standardized rather than owned by one vendor.

This matters most when the human is not present at execution time. A human-present checkout can ask for confirmation. A human-not-present checkout needs stronger ex ante scope. Without a signed mandate or equivalent, "the agent thought it was okay" is not a defensible authorization story.

Agent identity and audit infrastructure

Payment authority is half the problem. The merchant also needs to know whether the buyer is a legitimate authorized agent or a hostile bot. Visa's Trusted Agent Protocol describes signed content, an Agentic Consumer Recognition Object, and an Agentic Payment Container, designed so merchants can validate the agent and the payment container during checkout. Mastercard's Agent Pay Acceptance Framework includes agent registration, unique identification, agentic tokens, merchant recognition, Web Bot Auth at the CDN layer, Dynamic Token Verification Code, and FIDO involvement.

The shift is meaningful. Bot management today asks "Is this human or bot?" Agentic commerce asks a more precise question: "Is this bot authorized, for this buyer, for this purchase, under these limits?" That requires identity systems independent of any one model provider.

Stripe and Cloudflare's Machine Payments Protocol is the machine-to-machine sibling. It uses HTTP 402: the server returns payment details, the client authorizes and retries, then receives access and a receipt. Cloudflare's documentation describes the flow concretely: a server responds to an unpaid request with WWW-Authenticate: Payment, the client fulfils payment, retries with Authorization: Payment, and receives the resource with a payment receipt. Coinbase's x402 is the crypto-native equivalent.

The vendor surface

The cells map to layers, not to overall vendor strength. A vendor strong in one layer is not necessarily relevant in another.

Two adjacent surfaces deserve a flag. Skyfire and Payman position themselves as agent-payment infrastructure, but the public material is thinner than the named vendors above and warrants deeper diligence on live customer references, money-transmission analysis, bank partners, and exact custody model before being treated as core infrastructure. Crypto and Web3 rails (x402, stablecoin settlement) are real for machine payments but add separate custody, sanctions, and regulatory questions; they should stay peripheral for the default operator answer.

Classify the use case

"Agent payments" is one phrase covering four different problems. They differ on who the buyer is, who the merchant is, where authorization happens, whether the human is present, and which rails are available.

Internal agent purchasing

An employee-facing agent buys SaaS, books travel, pays vendors, replenishes inventory, or executes procurement. Start with virtual cards or delegated payment tokens, not open web checkout. Ramp, Stripe Issuing, Lithic, Visa, and Mastercard are the relevant surface area.

Customer-facing agent checkout

A buyer asks ChatGPT, Gemini, Perplexity, Copilot, or another assistant to buy from a merchant. This is ACP, UCP, PayPal, Stripe ACS, Visa, Mastercard, and platform partnerships.

Support-to-sales agents

Bots that move from answering support questions to collecting payment, upgrading subscriptions, recovering failed payments, processing refunds, or closing reorders. The risk is not that the support bot recommends; the risk is that it crosses from recommendation into financial execution.

Machine-to-machine payments

Agents paying an API, data source, model endpoint, compute provider, or another agent. MPP and x402 territory.

The wrong move is to pick a vendor first. The right move is to map the use case to who owns the customer relationship, who is merchant of record, where authorization happens, what credentials exist, how disputes work, and whether the human is present.

Set the boundary

The boundary is a sequence of decisions, not a single rule. Where does authorization originate. Who issues the scoped object. What does the merchant execute against. Where is the outcome recorded. The figure below is the architecture at a glance. The four subsections that follow walk through each decision in order.

Decide whether the agent can hold an instrument

Most agents should not hold an instrument. They should request one.

For internal purchasing, a virtual card can be acceptable if it is single-use or tightly scoped by vendor, amount, MCC, expiration, and velocity. For customer checkout, the agent should receive a scoped token or mandate, not raw credentials. Stripe SPT, Visa payment instructions, Mastercard Agentic Tokens, and AP2 mandates all support this direction.

The operator rule: raw credentials should never enter prompt context, browser automation memory, tool logs, or general agent state. If the agent can see reusable credentials, the deployment is already behind the market.

Set the human-presence policy

Human-present checkout is easier. The agent prepares the cart, shows terms, and asks for approval. Human-not-present payment is where this becomes a real governance problem.

Human-present agents can prepare carts, quotes, invoices, renewal pages, payment links, and checkout sessions; they submit payment only after explicit confirmation. Human-not-present agents transact only when there is a pre-approved policy with hard limits. Examples: "renew this SaaS if price increase is under 5%," "buy replacement inventory from approved suppliers under $2,000," "pay API charges up to $100 per day," "book refundable travel under $700 from approved carriers." Free-form goals are not authorization. "Find the best vendor and buy what we need" is not enough.

Decide what audit trail is mandatory

An agent-payment audit trail should include at minimum: the requesting user, account, or business policy; the agent identity and version; the natural-language task and structured interpretation; the approved scope (merchant, amount, currency, SKU/cart/hash, category, time, frequency, geography); the payment instrument or token ID without raw credential exposure; the authorization decision and the independent policy check; the executed transaction, receipt, refund, chargeback, and dispute state; the model and tool calls that materially influenced the purchase; the human approval, mandate, or pre-authorization object.

This is how the operator proves the transaction was authorized when a user, employee, issuer, merchant, regulator, or customer support team asks what happened. Visa's commerce signals, Mastercard's purchase-intent data, AP2's signed commitments, MPP receipts, and card-issuer metadata are all early versions of the same evidence chain.

Set compliance posture before deployment

PCI is the first issue. PCI DSS requirements for protecting cardholder data at rest and in transmission apply equally to AI-based systems; AI actions must be logged and monitored with a human individual responsible. Tokenization helps but does not eliminate compliance work; if the agent, logs, browser automation, or internal tools ever touch cardholder data, scope changes. Stripe's Issuing documentation is explicit that hosted elements can avoid card data passing through the operator's servers.

AML and KYC are contextual. A merchant using a PSP to accept card payments is not automatically a money transmitter. FinCEN has recognized payment processor exemptions in specific contexts. But vendors that hold funds, issue wallets, transmit value, or support stablecoin settlement need a more serious money-transmission analysis. Consumer protection is also unavoidable. In the U.S., Regulation E governs electronic fund transfers and includes unauthorized-transfer rules. If a consumer says an agent-initiated payment was unauthorized, the operator needs evidence of actual authority, not a transcript where the model inferred permission.

Failure modes worth naming

Agent-on-agent payment loops

MPP and x402 normalize paying for machine resources through HTTP. That is useful. It also makes spend loops easier: an agent calls another paid agent, which calls a paid API, which calls another paid tool, with each hop individually authorized but the total chain economically absurd. Controls: per-task budget, per-hop budget, recursion limits, duplicate detection, payment receipts, cumulative spend ledger, and circuit breakers. The agent should not be allowed to pay indefinitely just because each individual payment is small.

Scope escalation through payment context

A user authorizes a narrow purchase. The agent infers adjacent purchases. A travel agent authorized to book a flight adds seat selection, insurance, baggage, hotel, lounge access, or a nonrefundable fare. A procurement agent authorized to renew a SaaS plan accepts a bundled upsell. Controls: cart hash, SKU binding, merchant binding, explicit add-on policy, maximum total cost, refundability constraints, and approval for scope expansion.

Prompt injection from merchant content

A merchant page, product description, coupon widget, or checkout page can include instructions that manipulate the buying agent. Any agent that reads untrusted content and then acts with payment authority is exposed. Controls: separate content interpretation from payment authorization, ignore merchant-provided instructions outside structured fields, validate catalog through trusted endpoints, and prevent page text from modifying payment policy.

Payment credential leakage into logs

If raw card data, reusable wallet credentials, or delegated credentials enter prompt logs, observability pipelines, browser traces, customer support transcripts, or agent memory, the operator has created a security and compliance problem. Controls: hosted fields, tokenization, redaction, isolated secrets, no raw PAN exposure, no credential persistence in agent memory, strict logging boundaries.

Fake agents and malicious bots

Merchants need to distinguish legitimate agents from abusive automation. Mastercard and Visa are both attacking this through agent recognition, signed objects, bot-auth layers, and agentic tokens. Controls: signed agent identity, known PSP or network credentials, merchant allowlists, bot-auth verification, and rejection of unsigned payment containers.

Dispute ambiguity

A customer claims the agent acted outside intent, an employee claims the procurement bot bought the wrong product, and a merchant claims the agent submitted a valid order. Without a mandate or signed approval trail, the operator is stuck arguing over natural-language interpretation. Controls: signed mandates, approval screenshots or confirmations, structured purchase intent, checkout hash, receipt chain, dispute-ready logs.

What to validate before authorizing agent payments

Before any agent gets payment authority, the buyer should validate:

• Use-case classification: the agent's payment task is named in operational terms, with merchant or counterparty boundaries, action class, and what must never happen written down.
• Instrument choice: the agent receives a scoped token, virtual card, or mandate appropriate to the use case; raw credentials never reach the agent.
• Mandate binding: every transaction binds to a specific object (cart, quote, checkout hash, payment instruction); free-form interpretation is not authorization.
• Independent policy engine: a deterministic layer outside the model decides whether a payment is in scope.
• Audit trail: the requesting user or policy, agent identity, scope, instrument ID, authorization decision, executed transaction, and human approval are all logged without credential exposure.
• Compliance posture: PCI scope, money-transmission analysis, and consumer-protection exposure are confirmed before deployment, not after.
• Failure-mode tests: scope escalation, prompt injection, payment loops, credential leakage, and unsigned containers have all been tested with the response documented.
• Merchant-of-record clarity: the operator knows who is seller of record, who handles refunds, and who owns the customer relationship.

Failure on any item means no autonomous payment authority. Supervised pilot remains an option when individual gates pass but the aggregate risk warrants conservative rollout.

The mandate is the authorization

An agent that holds payment credentials is a leak. An agent that is told to "buy the right thing" without a binding is a hope, not an authorization. Defensible architecture binds money to a signed object: a cart, a quote, a checkout hash, a payment instruction. The agent only executes what the mandate already permits. Without that binding, "the agent thought it was okay" is not a defensible story.