AgentCore payments is GA: cap the wallet, not the prompt

Your agent is about to get a credit card. AWS moved Bedrock AgentCore payments to general availability on August 18, four months after the preview it built with Coinbase and Stripe. Agents can now discover, access, and pay for metered APIs, MCP servers, and content on their own. The part worth your attention is not that agents can spend. It is where AWS chose to put the limit: in the payment session at the infrastructure layer, not in the prompt.

What actually happened

AgentCore payments gives an agent a wallet — Coinbase or Stripe Privy — and a session with two hard caps: a maximum spend amount in a stated currency, and an expiry time. The infrastructure validates each request against the remaining session budget deterministically, before it signs the transaction. The model does not get a vote.

Two payment standards are supported. x402 now includes an "upto" scheme, which lets an agent commit a ceiling rather than a fixed price, so a merchant selling LLM tokens or any usage-metered API can charge for exactly what was consumed at the end of the call. AWS also added the Machine Payment Protocol, co-authored by Stripe and Tempo, and says MPP-compatible services work without an extra line of code. Coinbase credential provisioning has a Quick Create path in the AgentCore console.

Observability is wired in. Payment audit trails vend logs to CloudWatch and spans to AgentCore Observability, with prebuilt dashboards for transaction success rate and average transaction value across agents and time. Framework hooks ship for Strands (AgentCorePaymentsPlugin), LangGraph (AgentCorePaymentsMiddleware), and an agents-pay skill for OpenClaw.

Why agent payment limits matter for your business

A budget in the system prompt is a suggestion; a budget in the session is a boundary. "Never spend more than $50" sitting in a system prompt is one prompt injection away from irrelevant. A session ceiling enforced before transaction signing holds regardless of what the agent read, believed, or was told.

Expiry is the control most teams will forget. The spend cap gets the attention. The clock is what saves you from an agent that loops. A session that dies in fifteen minutes bounds a runaway loop to fifteen minutes of spend, not a weekend of it.

Pay-per-call changes how you price your own APIs. If you sell data, inventory feeds, or a metered service, x402's "upto" scheme means a machine buyer can transact without a contract, an invoice, or a sales call. That is a real channel, and it needs your endpoints to be discoverable and priced per call. Most small-business catalogs and APIs are neither.

Metered spend needs the same accounting discipline as payroll. Success rate and average transaction value dashboards are a start. What you actually want is spend attributed per agent, per task, per customer — so a $900 month is a line you can explain rather than a number you absorb. Tag it at the session, not at the invoice.

One session per task, not one per agent. The temptation is a long-lived wallet with a big ceiling because it is less plumbing. Do the plumbing. Scope each session to the job it funds and let it expire when the job ends.

Sources: AWS: AgentCore payments is now generally available, AWS Machine Learning Blog: Amazon Bedrock AgentCore payments is now generally available.