AgentCore Payments: AWS ships a managed x402 buyer

On 18 August 2026 AWS made AgentCore payments generally available. The buyer half of x402 is now a managed cloud primitive, and the managed client is stricter than the protocol it implements.

Most of the agent-payments work we have audited over the past months lives on the seller side: how to return a 402, how a facilitator verifies and settles, how a scheme encodes price. The buyer side stayed library code. You installed an SDK, you handed it a private key, and you hoped your spend cap was more than a variable in a prompt.

Amazon Bedrock AgentCore payments moves that half into the control plane of a hyperscaler. AWS announced the preview on 7 May 2026 in four regions — US East (N. Virginia), US West (Oregon), Europe (Frankfurt) and Asia Pacific (Sydney). The GA announcement is dated 18 August 2026, and the region matrix now marks AgentCore payments as available in twelve: N. Virginia, Ohio, Oregon, Frankfurt, Ireland, London, Milan, Paris, Spain, Stockholm, Singapore and Sydney.

This post is a read of the documentation, not a press release summary. What the service actually accepts, what it refuses, where it deviates from the specs, and what a call costs.

Five resources before a single payment

The service does not expose "a wallet". It exposes a resource tree, split across two API surfaces: bedrock-agentcore-control for configuration and bedrock-agentcore for the data plane.

The how-it-works page defines them precisely. A PaymentCredentialProvider holds the provider secrets in AWS Secrets Manager through AgentCore Identity. A PaymentManager is the top-level resource and the authorization boundary: it takes an authorizer type of AWS_IAM or CUSTOM_JWT plus an IAM role, and the service provisions a workload identity for it. A PaymentConnector binds that manager to one provider — CoinbaseCDP or StripePrivy. A PaymentInstrument is the end user's embedded wallet. A PaymentSession is a time-bounded budget.

Only then can an agent call ProcessPayment.

# Data plane: budget context for one interaction
session = manager.create_payment_session(
    user_id="test-user-123",
    limits={"maxSpendAmount": {"value": "5.00", "currency": "USD"}},
    expiry_time_in_minutes=60
)

The lifecycle states are worth noting because they leak the architecture. Managers and connectors move through CREATING, READY, UPDATING, CREATE_FAILED, UPDATE_FAILED. Coinbase connectors created with Quick create add four more: PENDING_AUTHENTICATION, PROVISIONING, AUTHENTICATION_EXPIRED and AUTHENTICATION_FAILED. Quick create is an OAuth consent against Coinbase that provisions the CDP key and wallet secret for you; the returned authorizationUrl is documented as valid for about ten minutes, after which the connector expires and you re-create it. Stripe (Privy) supports manual provisioning only — you paste App ID, App Secret, Authorization ID and a P-256 authorization private key.

Instruments carry a network enum. The create-instrument page states that ETHEREUM "covers Ethereum mainnet and all supported EVM-compatible Layer 2 networks (Base, Arbitrum, and others)", and that Solana-compatible chains use the SOLANA enum. Instrument status is INITIATED, ACTIVE, FAILED or DELETED.

The flow, header by header

The runtime path is the x402 loop we have described before, with the signing step relocated to an AWS API. The documented sequence: the agent calls a paid endpoint; the merchant answers 402 Payment Required with a payload naming amount, recipient, asset and network; AgentCore payments checks the session limit; it retrieves wallet credentials from AgentCore Identity and signs; the agent retries with the proof in the X-PAYMENT header; the merchant verifies and settles on chain; the service commits the transaction and updates the session spending ledger.

The last line of that sequence is the one to underline: "If any step fails, the payment limit reservation is released and the transaction is recorded as FAILED." Budget is reserved, then committed or released. That is a two-phase accounting model inside the buyer, which is exactly the discipline the protocol itself does not give you.

Calling it directly looks like this — the merchant's payload copied verbatim into paymentInput.cryptoX402:

payment = dp_client.process_payment(
    userId="test-user-123",
    paymentManagerArn=PAYMENT_MANAGER_ARN,
    paymentSessionId=SESSION_ID,
    paymentInstrumentId=INSTRUMENT_ID,
    paymentType="CRYPTO_X402",
    paymentInput={
        "cryptoX402": {
            "version": "2",
            "payload": {
                "scheme": "exact",
                "network": "eip155:84532",
                "amount": "100000",
                "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
                "payTo": "0x99935f281d3ED1E804bF1413b76E0B03e1fed4F9",
                "maxTimeoutSeconds": 300,
                "extra": {"name": "USDC", "version": "2"},
            },
        }
    },
    clientToken=str(uuid.uuid4()),
)

The response carries "status": "PROOF_GENERATED" and the signed proof in paymentOutput.cryptoX402.payload. Nothing settles inside AWS. The service is a signer with a ledger; settlement stays with the merchant's facilitator. That distinction matters when you reason about failure: a PROOF_GENERATED response is not a paid invoice, it is a signed authorization that the merchant may still fail to broadcast.

MPP rides the same operation with a different envelope. Set paymentType to MPP, forward the merchant's WWW-Authenticate: Payment header verbatim in paymentInput.mpp.wwwAuthenticateHeaders, and the response returns paymentCredential in the form Payment <base64url-token> to attach as the Authorization header. The docs are emphatic about not touching it: "Do not decode or modify paymentCredential. It embeds the original challenge and the signed payload, and the merchant's HMAC binds to those exact bytes."

Two protocols, one API, distinguished by an enum. We audited MPP when Stripe and Tempo shipped it; seeing it arrive as a peer of x402 inside an AWS data plane operation is the clearest signal so far that the buyer is expected to speak both.

The budget is infrastructure, not a prompt

The single most useful design decision here is that the spend cap is not in the agent. It is a server-side object with two fields — maxSpendAmount (value plus currency) and an expiry — checked before the wallet is ever asked to sign. The main payments page states it plainly: "When the session expires or the budget is reached, further payment requests are denied. If a payment signing fails after budget deduction, the budget does not deduct the failed payment."

The troubleshooting page sharpens the ordering further. For both protocols, validation happens "before it holds budget or signs", and malformed or expired inputs return a ValidationException that "consumes no budget". An expired MPP challenge is called out explicitly: no budget consumed, fetch a fresh challenge and retry.

Compare that with what the open SDKs give you. When we measured x402 spend controls across the three official SDKs, the cap was a client-side check the agent process could be talked out of. Here the check sits behind IAM, on a resource the agent cannot mutate, with a reservation released on failure. That is the correct place for it. It is also the same guarantee onchain spend permissions give at the wallet layer, moved to the API layer — with the trade-off that you now trust an AWS service instead of a contract.

Where the managed client narrows the spec

This is the audit's core finding. AgentCore payments does not implement x402; it implements a subset, and the subset is enforced with named errors.

Canonical USDC only. The validation table includes Payment asset is not a supported USDC token address for network '{network}', with the resolution "Use a merchant endpoint that requests canonical USDC". x402 itself is asset-agnostic — the scheme carries an arbitrary token address. The managed buyer refuses anything that is not the canonical USDC for the network. Every non-USDC price list on the seller side is invisible to an AgentCore agent. The MPP side is identical: "MPP EVM/Tempo charge supports only the canonical USDC token on network".

Two schemes. Payment scheme not supported. Supported scheme: {scheme}, with exact and upto as the accepted set. The batch-settlement and auth-capture schemes we audited earlier this year are not addressable through this client today.

upto carries an on-chain cost the caller must plan for. The process-payment page documents that upto settles through Permit2 and therefore needs an ERC-20 allowance. You grant it by passing permit2AllowanceLimit in the asset's smallest denomination (1000000 being 1 USDC at six decimals, or the maximum uint256 for unlimited). When you set it, "AgentCore payments submits an on-chain approve transaction before signing. This transaction incurs blockchain network (gas) fees paid from the wallet's native token balance." And because approve sets rather than adds, the docs tell you to send the field only on the wallet's first upto payment. Supplying it for exact is a ValidationException. It is also version-gated and chain-gated: upto requires x402 version 2 and EVM networks only. Our deep dive on the upto scheme called the Permit2 approval the scheme's hidden prerequisite; here it is, surfaced as a request field with a gas footnote.

MPP is fenced in four ways. Only the charge intent. Only pull mode. Exactly one challenge per ProcessPayment call. And methods limited to evm, tempo and solana, with a provider matrix: Solana works on Stripe (Privy) and is explicitly rejected for Coinbase-managed instruments. There is also an account-level gate — Access to MPP (Machine Payments Protocol) payment processing is not enabled for this account. Contact AWS Support for access. MPP shipped at GA, but not to everyone by default.

Gas consent is an explicit flag. For MPP, a challenge advertises who pays network fees through methodDetails.feePayer. If the seller does not sponsor them, the service refuses to sign unless you pass buyerPaysGasFees=true, because "that cost is not visible in the challenge amount". The evm method needs no consent since the facilitator broadcasts and pays; solana supports server-sponsored fees only. This is a small, genuinely good piece of design: an invisible cost is turned into a required affirmative parameter.

Delegation is a grant the user can revoke

An instrument starts empty and inert. The docs state that a payment instrument "starts with 0 USDC" and that "the agent does not have permissions to transact through the instrument unless the customer explicitly grants them". The end user opens paymentInstrumentDetails.redirectUrl, lands in the provider's wallet hub, tops up by crypto transfer or card, Apple Pay, Google Pay or ACH, and grants the agent signing permission. Only then does the instrument become ACTIVE.

Two failure modes get their own error strings, which tells you how often they happen: Delegated signing grant is not active for the end user wallet (the user never granted, or revoked) and Delegated signing is not enabled for your Coinbase project (the CDP project policy toggle is off). Revocation is a first-class action in the same wallet hub. The agent's authority to spend is a delegation, held by the user, revocable without touching AWS — which is the same shape as the delegation rails we have been tracking on chain.

The economics: you pay per wallet operation

The AgentCore pricing page says there are no additional AWS charges for payments API invocations beyond the wallet operation fees charged by your provider. The mapping is one to one: for Coinbase CDP, one CreatePaymentInstrument is one wallet operation and one ProcessPayment is one wallet operation; for Stripe Privy, instrument creation is free and each ProcessPayment is one wallet operation. The page's worked example prices a Coinbase CDP wallet operation at $0.005.

Hold that number against the service's own framing. The payments page describes the target transactions as "often under $1 or fractions of a cent". A half-cent fee per signature is invisible on a $1 call, is half the value of a one-cent call, and dominates anything below that. Metered pricing does not fix it either: upto reduces the number of signatures only if the seller lets you settle a session's worth of usage in one authorization.

The practical consequence is that per-request payment at true nanopayment sizes still wants batching or an escrowed session, not a signature per call. That is the same conclusion we reached auditing batched settlement, and it survives the move to a managed buyer. There is one more cost that is not a fee: using Coinbase requires an active AWS Marketplace subscription to the "Coinbase Wallets for AgentCore Payments" listing, and its absence returns SubscriptionRequiredException with HTTP 403 both at connector creation and at payment time.

Discovery comes bundled

The piece that makes this more than an SDK is distribution. AgentCore Gateway ships a Coinbase x402 Bazaar target — server URL https://api.cdp.coinbase.com/platform/v2/x402/discovery/mcp, outbound auth "No Authorization" — described as exposing "10,000+ existing paid MCP tools that support x402 microtransactions". Add the target, attach the payments plugin, and an agent can search for paid endpoints and pay for them without a line of payment code.

The client integrations follow the same logic: a plugin for Strands Agents, middleware for LangGraph, and an agentcore invoke --auto-session path where the deployed agent's x402 interceptor catches the 402, calls ProcessPayment and retries. AWS also publishes a seller-side sample where CloudFront plus Lambda@Edge enforces the 402 over S3 content on Base Sepolia — the same edge-enforcement pattern we analysed when x402 moved into CDNs.

What it means for LLM4Agents

LLM4Agents is a seller. We return 402, we price inference per call, we settle in stablecoins over an OpenAI-compatible gateway. AgentCore payments is the counterparty: a large, well-distributed population of buyers that speaks our protocol without us writing their client. That is a net gain, with three concrete implications.

First, the asset question is settled for this segment. If an AgentCore agent cannot pay in anything but canonical USDC on its instrument's network, then any price we quote in a non-canonical token is unpayable by that buyer. Our quotes must name the canonical USDC address for each supported chain, and our EVM offers must be reachable from an ETHEREUM-class instrument.

Second, scheme support is now a market-access decision, not a preference. Sellers who only advertise exact are fully addressable. Sellers who want metered inference must advertise upto with a correct extra.facilitatorAddress and a maxAmountRequired ceiling — the managed client validates the presence of that field and rejects the payload without it. For pay-per-inference, which is precisely our billing shape, upto is the scheme that gets us paid by these agents.

Third, the buyer now has a real budget and a real audit trail. Sessions deny over-cap requests before signature, and every data plane call emits logs and spans. Sellers that behave badly on the two-phase gap — charging for work that fails after authorization — are now visible in someone else's CloudWatch dashboard. That raises the value of the guarantees we have written about in our own two-phase gap audit: settle on delivery, refund cleanly, and make the failure path cheap for the payer.

The threat is not competitive, it is gravitational. A managed buyer bundled with discovery, identity, observability and a marketplace subscription pulls the default integration path inside one cloud. If the only frictionless way to reach agentic demand is to be listed where that cloud's discovery target points, the discovery layer becomes the chokepoint — not the protocol.

Staying on the frontier

Four moves, in order.

1. Be payable by the strictest client. Audit every 402 we emit against the AgentCore validation table: canonical USDC address per network, a positive amount, a valid payTo, a maxTimeoutSeconds within range, and extra.name plus extra.version on EVM. Any payload that fails those checks is a payment we silently do not receive. The strictest known client is the cheapest conformance test we will ever get.

2. Ship upto on our metered endpoints. Advertise the ceiling in maxAmountRequired, publish the facilitator address in extra.facilitatorAddress, and document for buyers that the first payment from a wallet needs a Permit2 allowance with its gas cost. Pay-per-inference is our core billing story; upto is how a managed buyer expresses it. The details are in our upto scheme deep dive.

3. Get listed where the buyers look. The Bazaar discovery endpoint is wired into AgentCore Gateway by default and requires no outbound auth. Being present in x402 discovery is now a distribution channel with a hyperscaler on the other end. Bazaar indexes at settle time rather than through a registration step, so the operational task is to confirm our endpoints appear and that their advertised metadata matches what we actually charge.

4. Speak MPP as well as x402. The managed buyer selects protocol with an enum, and the challenge format is the only difference at the seller edge: a WWW-Authenticate: Payment header instead of an x402 payload, and an Authorization header instead of X-PAYMENT. Adding an MPP challenge path alongside our 402 is a bounded piece of work that doubles the set of managed buyers we can accept, and it hedges against a future where the cloud client, not the protocol foundation, decides which rail wins.

The buyer side stopped being a library this quarter. The sellers who get paid next year are the ones whose 402 survives contact with someone else's validation table.