What AWS AgentCore is, and which parts touch money
AWS AgentCore is the set of managed services Amazon put underneath agents so teams stop hand-rolling the same infrastructure. There are thirteen billable capabilities and they divide cleanly by what they govern. Runtime, Browser and Code Interpreter govern execution: they give the agent somewhere isolated to run, browse and execute code, billed on active vCPU-hours and memory GB-hours. Gateway, Identity and Policy govern access: which tools exist, which credentials the agent may borrow, which calls are authorized. Memory, Observability, Evaluations and Agent Registry govern state and oversight.
Exactly one of them governs money, and it is the newest. Amazon Bedrock AgentCore Payments reached general availability on 18 August 2026, having been in preview since 7 May. It gives the agent a stablecoin wallet through either Coinbase CDP or Stripe Privy, and when the agent hits a paid resource that answers HTTP 402, AgentCore negotiates the payment and hands back proof without breaking the reasoning loop.
That is a genuinely useful thing to have shipped, and the design is careful. It is also much narrower than the phrase "agent payments" suggests, and the narrowness is measurable rather than a matter of opinion. So we measured it.
How we measured the spend-policy surface
AWS publishes the machine-readable model for every service API in the botocore repository. That model is the contract: if a property is not in it, no console toggle, blog post or roadmap slide can make the API accept it. So the honest way to answer "what spend rules can AgentCore enforce" is to read the model and count.
On 9 September 2026 we pulled two files from the botocore develop branch: the AgentCore data plane (bedrock-agentcore, API version 2024-02-28, 480,002 bytes) and the AgentCore control plane (bedrock-agentcore-control, API version 2023-06-05, 994,087 bytes). Between them they describe 237 operations, 2,216 shapes and 4,162 member properties.
Then we ran two passes. The first looked for any money vocabulary at all: amount, currency, budget, spend, price, cost, payment, invoice, balance, wallet, fee, charge, billing, limit. The second looked for the other dimensions a real spend policy needs: merchant, category, MCC, vendor, counterparty, allow list, approval, approver, daily, monthly, cumulative, aggregate, recipient, payee, purpose.
The first pass hit 70 properties in the data plane and 48 in the control plane, across 11 payment operations. So unlike the Microsoft agent surface, AgentCore plainly does model money. The interesting result is the second pass, and how few properties carry the whole policy.
The result: one amount, one currency, one clock
The entire spend ceiling in AgentCore Payments is a structure called SessionLimits, and it has exactly one member: maxSpendAmount. That member is of type Amount, which is itself two fields, value and currency. The Currency enum contains one value, USD. The readout side mirrors it: AvailableLimits.availableSpendAmount tells you what is left.
Three details in that paragraph matter more than they look.
First, limits is optional on CreatePaymentSessionRequest. The required fields are the payment manager ARN and an expiry time. The ceiling is not required. A session created without it is a wallet handed to a model with no stated maximum, and the API will accept that call.
Second, the ceiling is per session, and a session is short-lived by construction: expiryTimeInMinutes is required and constrained to a minimum of 15 and a maximum of 480. Eight hours is the longest a payment session can live.
Third, and this is the part that changes how you should budget: our second regex pass found no cumulative, daily, monthly, weekly or aggregate property anywhere in either model. The one match in the data plane was InsightsFailureSignal.category, which is an observability field about failures, not a spend rule. So each new session starts fresh at the full maximum. An agent that runs continuously for a week does not spend one cap. It spends the cap as many times as it opens a session.
What the payment rails actually are
The enums settle a question a lot of buyers assume the other way. PaymentType has two members, CRYPTO_X402 and MPP. PaymentInstrumentType has one member, EMBEDDED_CRYPTO_WALLET. InstrumentBalanceToken has one member, USDC. The wallet networks are Ethereum and Solana, and the chain identifiers are Base, Base Sepolia, Ethereum, Solana and Solana Devnet.
Read together: AgentCore Payments is a stablecoin rail. There is no card, no ACH, no wire and no invoice in it. We checked that claim rather than inferring it, because it is the kind of statement that is easy to get wrong. The literal string "card" does appear fifteen times in the data-plane model, and every single occurrence is the A2A Agent Card, the metadata document that describes an agent to other agents. There is no creditCard, no cvv, no iban, no merchant and no mcc anywhere in the file.
Your agent can therefore pay for a metered API, an MCP server, a piece of web content or another agent. It cannot check out at a US merchant, pay a supplier invoice, or put anything on a corporate card, because none of those rails are reachable from this API. If your agent buying story involves a purchase order, a vendor or a card statement, AgentCore Payments is not the component that does it, and that is worth knowing before the architecture review rather than after.
Why the control-plane approval field is not the approval you want
Our dimension pass did find approval vocabulary, and it would be easy to misreport. ApprovalConfiguration.autoApproval exists in the control plane, and it appears on CreateRegistry, GetRegistry and UpdateRegistry. So AgentCore does have an approval concept.
It governs the Agent Registry: whether an agent published into a registry is auto-approved or has to be reviewed by a human. That is a supply-chain control over which agents your organization is willing to list and reuse. It is a good control and it is not a spend control. Nothing in the eleven payment operations consults it. ProcessPayment takes a payment manager ARN, a session ID, an instrument ID, a payment type and a payment input. There is no approver, no threshold and no pending state in that call: it either validates against the session ceiling or it does not.
The same care applies to AgentCore Identity and AgentCore Gateway, which are the two components teams most often assume already solve this. Identity vaults and brokers OAuth tokens and API keys so an agent can act against a third-party service without a human pasting a secret. Gateway turns your APIs and Lambda functions into MCP tools and applies rate limits to them. We found BatchPutGatewayRateLimits and CreateGatewayRateLimit in the control plane, so Gateway can cap how many times a tool is called. Neither component can cap what a call is worth. A rate limit on a procurement tool is not a budget, because ten calls that each spend 50,000 dollars pass a limit of a hundred calls per minute without complaint.
What this means for the AgentCore bill
There is a second, quieter consequence. AgentCore Payments is the only component on the AWS pricing page with pass-through pricing: AWS adds no charge of its own for CreateInstrument or ProcessPayment, and you pay whatever Coinbase CDP or Stripe Privy charges. Every other component has a published AWS unit rate. Runtime is 0.0895 dollars per vCPU-hour and 0.00945 dollars per GB-hour. Gateway is 0.005 dollars per 1,000 API invocations. Identity is 0.010 dollars per 1,000 token or API key requests, and free when used through Runtime or Gateway. Policy is 0.000025 dollars per authorization request.
So the money your agents spend does not appear on the AgentCore line of your AWS bill at all. It lands in a wallet provider’s ledger, denominated in USDC, on Base or Solana. Finance is going to reconcile a cloud invoice that shows compute and invocations, and separately try to explain a stablecoin ledger that shows the actual purchases. We wrote up the full component-by-component numbers in our AgentCore pricing breakdown, including the components most calculators leave out.
Where a spend policy layer fits on top
None of this is a criticism of the design. A session-scoped USD ceiling on a stablecoin wallet is a sensible primitive, and primitives are what infrastructure should ship. The gap is that a primitive is not a policy, and the distance between them is where the finance objection lives.
A policy answers questions AgentCore’s model has no field for. Which counterparties is this agent allowed to pay at all. What is its total for the month, not for the next eight hours. Which purchases need a named human to approve before they clear, and which clear silently. What happens on the tenth identical charge in a minute. Which cost center owns this, in the general ledger, in dollars.
That is what we build. Agentspay sits between the agent and the money as a spend policy engine: per-agent and per-period budgets that actually aggregate, counterparty allow lists, human approval thresholds that hold a payment pending instead of declining it, merchant-locked virtual cards for the card rail AgentCore cannot reach, and an immutable audit trail that reconciles to your books rather than to a chain explorer. If your agents pay for APIs over x402, keep AgentCore Payments doing that and put the policy above it. If they also need to buy from vendors, that part was never in scope for AWS.
How AgentCore compares with the other agent control planes
The pattern repeats across every large vendor that shipped an agent control plane in 2026, which is why it is worth naming rather than treating as an AWS quirk. Microsoft’s Agent 365 governs agent identity and access through Entra Agent ID and expresses no monetary amount at all. The accounting and ERP MCP servers govern which tools a model may call against your books, never the amount. The payment MCP servers from Stripe, PayPal, Square and Checkout.com expose write access to live payment APIs and none of them enforces a ceiling. And Salesforce Agentforce models money across 178 standard objects and agents across 41, with no object joining the two, so the largest CRM on the market has nowhere to store an agent budget either.
AWS went further than any of them: it actually shipped a limit. One optional amount, in one currency, for up to eight hours. On the current evidence that makes AgentCore the most complete of the lot, and it still leaves the buying decision ungoverned. The Machine Payment Protocol it now speaks is documented on our MPP page, and the broader question of paying per tool call is covered under MCP payments.