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) for a $0.01 payment via AgentCore ProcessPayment — a small amount, chosen to demonstrate independent signing rather than to probe an aggregate total. 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 control in the API path I used. The accounting was session-local: each of the five signed independently, and each session's ledger decremented only itself. The test did not rule out an undocumented aggregate threshold at higher cumulative amounts. 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, and not the ceiling of what it would aggregate. I hold five independently signed authorizations, each within its own session cap; the accounting was session-local, with no principal-wide control composing them. I signed a small amount in each to demonstrate that independence — I did not drive the cumulative total high enough to probe for an undocumented aggregate threshold, and I have not submitted anything 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 were shared with AWS as preview-product feedback. Findings are bounded to signing-layer evidence; no settlement testing was performed.
Top comments (0)