Design agent spending limits the model can’t sweet-talk past

When an agent asks to buy a paid API, the budget should be checked before the transaction is signed. Agents built on Amazon Bedrock can locate paid APIs, MCP servers, and web content by themselves and pay for those services in USDC. AWS announced AgentCore Payments reached general availability on August 18. The design problem is where the limit lives when the model goes too far.

Agent payments are a product responsibility. An agent that can buy data, call a paid API, or reserve a service is only as trustworthy as its spending control. A sentence in the prompt is a weak guardrail: the model can be persuaded, distracted, or simply wrong. Users are not security engineers, and they should not have to audit every transaction to keep the product safe.

The prompt is a policy, not a vault

System prompts are good for intent, tone, and task boundaries. They are unreliable for irreversible financial actions. A prompt can be long, and the budget line can be forgotten. A model can be asked to stay under a budget, but the request can be buried under a long conversation or a later user request. The failure mode is often a plausible mistake: the agent believes the extra call is necessary, or the user asks for an exception, and the model complies. Users will not read the prompt.

The strongest objection is that caps kill autonomy

Product teams often worry that hard limits will make agents feel dumb. A user asks for a research task, and the agent needs to buy several small inputs. A cap that is too low makes the task fail. A cap that is too high exposes the product. A cap is a product decision: legible, scoped, and recoverable.

A scoped budget is safer than a standing permission that survives after the task ends. The expiry idea matters because agent tasks can drift. AgentCore Payments checks payment requests against the session budget and rejects over-budget requests before signing, using a deterministic infrastructure-layer check. The model can propose a payment, but the infrastructure decides whether the proposal is allowed.

The redesign is a placement rule

For every high-stakes agent action, define the limit, owner, and enforcement point; put irreversible limits in the payment, session, or infrastructure layer, not in the system prompt. A deterministic check is easier to explain than a model's promise.

• Limit: AgentCore Payments payment sessions include a maximum spend amount in a chosen currency and an expiry time. Show it before the agent acts.
• Owner: the end user or a product policy, with a clear path to raise or revoke the cap.
• Enforcement point: the payment layer, wallet, or infrastructure control that checks the request before signing.

End users can fund an agent's wallet with credit cards or USDC stablecoin and must delegate spending authority to the agent. That delegation is the trust event. The product should make it visible: what the agent can buy, how much it can spend, and how long the authority lasts. A visible cap is a trust feature. A wallet alone does not create permission. A delegated, capped, expiring session does.

More payment routes need more limits

AgentCore Payments connects to Coinbase and Stripe Privy wallets so developers can configure agent payment capabilities. AgentCore Payments added support for the Machine Payment Protocol at general availability, a machine-payment standard co-authored by Stripe and Tempo. Each new route adds a place where a limit can be missed.

Before launch, ask what happens when the model asks for more than the user intended. When the answer is that the model will notice, the product is not ready. When the session rejects it and the user sees why, the product has a control that can be shown to users.