The spend cap worked. The risk budget didn't compose.

Spending limits are becoming the foundational guardrail for agentic payments. AWS Bedrock AgentCore Payments enforces them per payment session. Google's AP2 expresses limits through mandates that bind amount, merchant, and intent. Wallet and custody platforms add their own policy layers.

I tested one narrow question against AWS AgentCore Payments' live preview: when multiple sessions belong to the same principal, does the platform aggregate their authority?

The short version: the per-session control works exactly as documented. It does not compose into a principal-level risk budget.

Three layers: admit, sign, settle

An agent payment moves through three gates. The system admits the request — checks it at the front door. It signs an authorization — produces the cryptographic artifact intended for presentation to a merchant or facilitator. It settles on-chain — money moves.

Functional testing often stops at admission: was the request accepted or rejected? But the signed authorization is the artifact that matters: it's what crosses the agent-side policy boundary and gets presented for payment. So I drove the tests to the signing layer, through real Coinbase CDP delegated signing, and watched what the stack will authorize.

Method, precisely

Holding constant the same AgentCore payment manager, userId, agentName, Coinbase-backed payment instrument, delegated-signing grant, AWS account, and region (us-east-1, preview API, 2026-07-11), I created five concurrently active payment sessions, each with an independent maxSpendAmount of $0.05. I then drove each session to a signed authorization (PROOF_GENERATED) via AgentCore ProcessPayment. Nothing was submitted on-chain; every test stopped after the payment proof was generated.

Finding 1 — each session's budget holds; the authority doesn't aggregate

Within a single session, the budget enforces correctly. Three signatures walked one session's balance from five cents to two, and a fourth, over-budget request was refused with the arithmetic to prove it. The accounting works.

Across the five concurrently valid sessions, I found no principal-level aggregate limit. Each of the five signed independently; each session's ledger decremented only itself. AWS documents a PaymentSession as a scoped payment context and enforces spending within it — so this is not a broken promise. It's the composition: session-scoped enforcement does not add up to a principal-scoped ceiling.

Whoever controls session issuance controls the aggregate exposure: five concurrent sessions create five independently enforceable budgets, and session issuance is itself part of the control surface. Local enforcement is not aggregate governance.

Finding 2 — in the tested path, the signer applied no recipient policy

Here the boundary matters, so I'll name it exactly. When the payment requirements — including the recipient (payTo) — were author-constructed and submitted to AgentCore ProcessPayment, the delegated signer performed structural address validation but applied no recipient allowlist or merchant-legitimacy decision. It produced cryptographically signed authorizations naming the zero address and syntactically valid, previously unseen addresses; only malformed addresses were rejected.

Two honest caveats. This tests a crafted requirement, not the normal flow where requirements are discovered from a merchant's 402 response — so it models a substituted or injected requirement, which is precisely the agentic threat worth caring about. And declining recipient vetting at the signer is defensible: payee legitimacy is arguably a merchant-and-facilitator concern, not a signing-primitive one. But it's a boundary operators should draw on purpose. In the tested path, no allowlist, merchant binding, or policy evaluation stood between an author-supplied recipient and a cryptographically signed payment artifact.

What holds

This is not a system that fell over. In the scenarios tested, the documented session-level controls held: cap-versus-amount is enforced at signing, deleting a session genuinely voids its signing ability, and idempotency and structural validation both work as expected.

The gap is specific: session enforcement is real; it simply doesn't compose into a control across sessions.

The cap worked. The risk budget did not compose across sessions.

The line I won't cross yet

I proved what the stack signs — not what it settles. I hold five signed authorizations that each honor a session's cap and collectively exceed an operator's intended aggregate ceiling — even though each remains within its configured session limit. I have not submitted them on-chain, so I am not claiming money moved. Settlement may still reject an authorization on recipient rules, facilitator validation, balance, nonce, or expiry.

So the precise claim: the signed authorization is already part of the blast-radius surface — an externally usable artifact that has crossed the agent-side policy boundary. Whether that authority is ultimately redeemable is a settlement question, and that test comes next.

What it asks of operators

A session budget answers one question: how much may this execution sign? It does not answer the one that actually governs risk: how much authority does this agent, user, wallet, or business process hold across all of its active executions?

Agentic-payment governance needs both. The first is a local enforcement control, and AgentCore provides it. The second — a principal-wide risk budget that composes across concurrent sessions — is a control-plane responsibility, and it has to be layered by whoever operates the agent.

The rail is being built fast. The aggregate governance layer still belongs to the operator.

These observations are being reported to AWS. Findings are architectural characteristics of a preview product, bounded to signing-layer evidence; no settlement testing was performed.