Authorizing an agent payment is no longer one decision.

What does it take to authorize an agent payment?

Four layers, four questions. Identity at L1 asks who is acting and whether that key binds to a registered principal. Protocol at L2 asks how payment crosses the wire and whether the merchant accepts it. Spending governance at L3 asks what caps, merchants, and time windows constrain the agent. Behavioral attestation at L4 asks whether the agent stayed inside the scope it was given across every tool call, and whether a third party can verify that without trusting the agent's operator.

Each question has its own infrastructure and its own failure mode. Bundling them makes governance look complete when it isn't. Splitting them lets you check what's actually in place before authorizing the spend.

How do AgentCore Payments and x402 fit together?

On May 7, AWS shipped the preview of Amazon Bedrock AgentCore Payments. Coinbase x402 and Stripe are bundled. Spending limits run at the infrastructure layer. Every transaction lands in the same logs, metrics, and traces developers already use in AgentCore. The Coinbase x402 Bazaar MCP server exposes over 10,000 endpoints agents can search and pay for autonomously.

That covers L2 and a piece of L3 inside one hyperscaler product. Five weeks earlier, on April 2, the x402 Foundation launched under the Linux Foundation with 22 founding members including Visa, Mastercard, American Express, Stripe, Coinbase, Cloudflare, AWS, Google, Microsoft, Adyen, Fiserv, and Shopify. The protocol is now neutral infrastructure. The wallet on top of it is a hyperscaler default.

How are Visa TAP and Mastercard Verifiable Intent different from x402?

Visa Token Authentication for Payments and Mastercard Verifiable Intent live one layer below x402. Both bind a card or an authorization to a specific agent at a specific moment.

Visa TAP lets a cardholder authorize a specific agent to use a specific token at a specific merchant. The token verifies one-time consent. Mastercard Verifiable Intent uses an SD-JWT delegation chain from issuer to cardholder to agent, signed at every hop. The chain proves the agent had permission at the moment of payment.

Both are L1 identity binding and L2 delegation. Both are clean cryptography. Neither describes what the agent does after the moment of consent.

What do Cloudflare-Stripe Projects spending caps actually enforce?

Cloudflare and Stripe launched Projects on April 30. An agent can register a Cloudflare account, buy a domain, deploy a Worker, and bill a Stripe-issued payment token. The default cap is $100 per month.

A .com registration runs about $10 a year. An agent acting in good faith might spend $15. An agent operating from a poisoned context can register sixty look-alike domains in a single session, deploy a credential-harvesting Worker on each, and finish the month $40 under cap. The Stripe charges authorize cleanly. The transactions reconcile. None of it trips a fraud signal.

The cap answered did the spend stay in budget. It did not ask should this agent be allowed to register microsoft.io.support-portal.com. Those are different questions, and only one of them is currently being asked at provisioning time. Read the full breakdown.

What do spending caps not prove about an agent?

A cap is a financial guardrail. It limits the size of the damage. It says nothing about the shape.

Spending caps don't see which merchants the agent was authorized for. They don't see whether the action sequence matches the agent's prior behavior. They don't see whether the same key is operating from a freshly-created controller with no history. They don't see whether the agent has been prompt-injected since authorization. They don't see whether sixty similar registrations in 90 days fit a phishing pattern.

That's the L4 question. Caps are necessary. They are also the layer that gets confused with governance because they ship in the same product. Treating L3 as L4 is the failure mode this page exists to correct.

How does behavioral attestation bind to the existing payment rails?

Behavioral attestation issues a credential at session start that commits the agent to a specific scope: a price cap, a merchant whitelist, a time window. Every tool call inside the session anchors to a tamper-evident audit log. The credential is verifiable at any third party from a JWKS endpoint, with no callback to the issuer required.

In practice, the agent carries two things. A payment token to answer can it pay. A Behavioral Commitment Credential to answer should it be trusted with this action. A receiving service like Cloudflare, a card network, or an x402 endpoint can check both at provisioning time. The cap stops the financial half of the damage. The behavioral profile stops the half that doesn't show up on a card statement.

Chargebacks911's CTO described the gap to Electronic Payments International this week: "dispute management simply does not appear" in agentic-commerce reports. The cap doesn't resolve disputes. The token doesn't resolve disputes. The audit chain does. See the live dispute resolution demo.

Which layer answers which question about agent payment authorization?

• Identity at L1 answers who is acting. Visa TAP, Mastercard Verifiable Intent, agent DIDs.
• Protocol at L2 answers how the payment crosses the wire. x402, Stripe MCP Payments.
• Spending governance at L3 answers what budget the agent can spend. AgentCore Payments, Cloudflare Projects, Stripe scoped tokens.
• Behavioral attestation at L4 answers whether the agent stayed inside the scope. AgentLair Behavioral Commitment Credentials.

An L1-L3 integration authorizes a spender at the moment of payment. Can you still verify the spender three hours later? On the seventh purchase? At a different merchant? Not without L4.

The May 2026 stack closed L1 through L3. The next gate to add is L4. More on why L3 standardization makes L4 urgent.