Spending controls for AI agents: why agentic payments need a policy layer
Last updated: 2026-09-27. Written for: developers and technical decision-makers building or buying AI agents that spend money; finance/procurement/IT leaders evaluating agent risk.
An AI agent that can make a payment is only as safe as the rules that constrain it before that payment executes — and in 2026, most of the industry's attention has gone into how an agent proves it's authorized to pay, not into what a company can restrict that payment to. This article defines the problem, surveys how the major agent-payment protocols and networks currently handle authorization, and lays out the specific controls a policy layer needs to provide.
The problem: authorization is not the same as control
Giving an agent the ability to pay is a technical integration problem — connect a wallet, an API key, or a checkout flow, and the agent can transact. Giving an agent permission to pay is a different, harder problem: an organization needs to define, before any transaction happens, exactly what that agent is and isn't allowed to do with money, and needs a way to enforce that definition even if the agent misbehaves, is compromised, or is told to do something outside its intended scope by a prompt-injected input.
Most of the protocols built for agentic commerce in the last two years focus on the first problem: proving identity, signing intent, and moving funds. That's necessary — an unauthenticated agent making payments is a fraud vector — but it doesn't answer the question a CFO or IT security lead actually asks: "How much can this specific agent lose control of, at most, before someone notices?" That's a policy question, and it needs a policy layer, separate from the payment rail itself.
Types of spending controls
A useful mental model borrows directly from how enterprises already control human spending (corporate cards, procurement systems, expense policies) and adapts it for the fact that the "employee" here is a piece of software that can act at machine speed and doesn't get tired, embarrassed, or suspicious of a bad instruction.
| Control type | What it limits | Human analogy |
|---|---|---|
| Per-agent spend caps | Maximum amount an agent can spend per transaction, per day, or per period | Daily card limit |
| Merchant allowlists / denylists | Which vendors or counterparties an agent may pay at all | Approved vendor list |
| Category rules | What kind of purchase is allowed (e.g., SaaS yes, advertising no) | Expense policy categories |
| Human-in-the-loop thresholds | Amount or risk level above which a person must approve before execution | Manager approval on large expenses |
| Audit trails | A complete, tamper-evident record of what was requested, approved, denied, and why | Expense report + receipts |
| Revocation | The ability to immediately cut off an agent's ability to spend, without shutting down the whole system | Cancelling a card |
None of these are exotic — they're standard controls. What's new is that they need to be enforced at machine speed, against a requester (the agent) that can be manipulated by its own inputs in ways a human employee typically isn't.
How existing protocols approach authorization
It's worth being precise about what each of the following actually solves, because "agent payments" has become a crowded label for several different layers of the stack.
AP2 (created by Google; donated to the FIDO Alliance on April 28, 2026). Announced by Google in partnership with more than 60 payments and technology companies, AP2 is described as "an open protocol developed with leading payments and technology companies to securely initiate and transact agent-led payments across platforms," designed to work as an extension of the Agent2Agent (A2A) protocol and MCP [Google Cloud Blog, "Announcing Agents to Payments (AP2) protocol," accessed 2026-09-27]. AP2's core mechanism is the Mandate — a cryptographically signed, tamper-proof digital contract. The protocol defines an Intent Mandate (the user's initial request or, for delegated tasks, the pre-authorized rules of engagement — price limits, timing, conditions), a Cart Mandate (a locked-in record of the exact items and price once the user or agent finalizes a selection), and a Payment Mandate (which authorizes payment against a specific instrument and links it to the verified cart) [same source]. This is an authorization and audit-trail mechanism — it proves what was agreed to, which is complementary to, but distinct from, a company deciding in advance what its agent is allowed to agree to.
x402 (created by Coinbase; since July 14, 2026 governed by the x402 Foundation under the Linux Foundation). x402 is "an open standard for internet native payments" that aims "to support all networks (both crypto & fiat) and forms of value (stablecoins, tokens, fiat)" [x402 GitHub repository, github.com/coinbase/x402, accessed 2026-09-27]. It repurposes the long-dormant HTTP 402 "Payment Required" status code: a resource server responds to an unpaid request with a 402 and payment requirements, the client returns a signed payment payload, a facilitator verifies and settles it, and the server fulfills the request [same source]. The core flow described in the repository is about transport and settlement for machine-to-machine payment; how much a paying agent is allowed to spend is left to whoever operates that agent.
ACP — Agentic Commerce Protocol (OpenAI + Stripe). ACP is an open standard, currently in beta, co-developed by Stripe and OpenAI (with Stripe continuing to maintain the specification) that "enables programmatic commerce flows between buyers, AI agents, and businesses" and specifies "the checkout session and the secure sharing of payment credentials among the shopper, agent, merchant, and payment provider" [docs.stripe.com/agentic-commerce/acp; stripe.com/newsroom, accessed 2026-09-27]. It shipped first as the mechanism behind ChatGPT's Instant Checkout with merchants including Etsy and (announced) Shopify sellers [stripe.com/newsroom, accessed 2026-09-27]. Like AP2, ACP standardizes the checkout handoff — it doesn't prescribe how a business decides what its own agent is allowed to buy.
Visa Trusted Agent Protocol (TAP). Co-developed by Visa and Cloudflare and launched October 14, 2025, TAP is "an ecosystem-led framework for AI commerce" [Visa, "Visa Introduces Trusted Agent Protocol," investor.visa.com, accessed 2026-09-27] that adds cryptographic agent identity to standard HTTPS requests: an agent attaches signed headers to a request, and the merchant verifies the signature against a Visa-operated directory, so the request is treated as coming from a known, accountable agent rather than an anonymous bot [visa.com / corporate.visa.com coverage, accessed 2026-09-27]. This solves identity and accountability at the network level — establishing that a request really did come from a registered agent — rather than whether that agent should be allowed to spend this amount right now.
Mastercard Agent Pay. Announced April 29, 2025 with Microsoft, IBM, and Braintree as launch partners, Agent Pay lets verified AI agents transact on a consumer's behalf using "Agentic Tokens" — an extension of Mastercard's Digital Enablement Service that binds a tokenized card credential to a specific agent, merchant scope, and consent policy, so an agent can complete a checkout without holding the raw card number [Mastercard, "Mastercard unveils Agent Pay," mastercard.com, accessed 2026-09-27]. Mastercard has since introduced Agent Pay for Machines (AP4M) for machine-speed, agent-to-agent settlement [mastercard.com, June 2026 announcement, accessed 2026-09-27]. This is a credential-scoping and tokenization mechanism — powerful for limiting where a credential can be used, but it is the card network's mechanism, not a company's own configurable policy console.
Stripe's agent tooling. Separately from ACP, Stripe provides a Model Context Protocol server ("The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API") and requires human confirmation before certain write actions like refunds and outbound payments, via a click-to-approve link that expires after 24 hours if not confirmed [docs.stripe.com/mcp, accessed 2026-09-27]. This is the closest of the group to a built-in control (a human-approval gate on specific actions), but it's scoped to Stripe's own API surface, not a general policy engine for arbitrary agent purchases across vendors.
The pattern across all of the above: they are protocols and network features that define how an authorized payment happens and how identity/authorization is proven. Almost none of them let a company's own finance or IT team declaratively say "this agent, this budget, these categories, this approval threshold" and have it enforced independent of the payment rail underneath.
Where a policy layer fits
A policy layer sits logically upstream of any of the mechanisms above: before a Mandate is signed, before an x402 request is paid, before an ACP checkout session completes, the policy layer answers "is this specific agent allowed to make this specific payment, right now, under this organization's current rules?" It needs its own audit trail (who requested what, what the policy said, what happened), and it needs to be revocable independent of whether the agent's own credentials or code have been fixed.
Pink Agentic AI Payment is one early-access approach to this problem. Pink Agentic AI Payment lets AI agents connect and pay through MCP while a policy engine enforces each customer's spending rules before any payment executes. It is not yet generally available; the underlying payment rails and settlement approach are still being finalized, and the description above should be read as a design direction, not a claim about a shipped system.
