AWS Builder Center

Builder Center

Your Agent Has a Wallet Now, and the Spend Does Not Show Up on Your AWS Bill

Golden Jacket Field Notes. Week 19

Series: Golden Jacket Field Notes (22 articles)

  1. 1
    The Cheapest Price Per Token Can Be the Most Expensive Way to Run an LLM
  2. …
  3. 16
    Your Agent Has a Wallet Now, and the Spend Does Not Show Up on Your AWS Bill This article
  4. 17
    The AWS Generative AI Professional Exam: What the Blueprint Doesn’t Reveal

Erick Mancz

AWS Golden Jacket | Co-founder Golden Jackets Brazil Community | 40 AWS Credentials
I have not put an agent wallet into production. I want that on the table in the first paragraph, because this week I am writing about money moving without a human in the loop, and the distance between reading the documentation and carrying the pager for it is wider here than in anything else I have covered in this series.
What I did do was read the entire AgentCore payments documentation set twice. The first read was the tourist version. The second read is where this article came from, and it started with one line in the troubleshooting table of the quick start guide. If ProcessPayment comes back FAILED, the guide tells you to verify that the wallet has sufficient USDC and gas fees. Gas fees. In an AWS quick start, next to a boto3 snippet, in the same voice AWS uses to tell you that your Lambda function needs more memory.
That line is the whole article in miniature. AWS has made agent payments feel like every other managed primitive: create a resource, set a limit, call an API. Underneath it, the thing being spent is real money on a public settlement network, and almost every hard question it raises belongs to someone who has never opened the AWS console.

The problem

The pattern shows up in architecture reviews before anyone says the word payments.
A team is building a research agent, or a market intelligence agent, or something that reads the web on behalf of a human researcher. It works well in the demo, because in the demo the good data was free. Then it goes to a real workload and hits the actual shape of the internet, where the useful sources are paywalled, the useful APIs are metered, and the useful market data costs more per month than the team's entire compute budget.
So the room solves it the way rooms have solved it for fifteen years. Someone procures a vendor. Someone puts an API key in Secrets Manager. Someone writes a wrapper. Six weeks later they need a second source, and the whole cycle runs again: legal review, vendor onboarding, a minimum commitment for a service the agent might call four hundred times or four times, nobody knows yet.
Watch what happens to the architecture while that procurement cycle runs. The team hard codes the one source they managed to buy. The agent's reasoning quietly reshapes itself around what it can reach rather than what the question needs. Nobody writes that decision down anywhere, because it never felt like an architecture decision. It felt like waiting for a contract.
Then a different failure arrives, and this one is the reason I keep seeing the pattern. Somebody in finance asks what the agent spent last month and on what. The honest answer is a monthly invoice from three vendors, with no breakdown by agent, by user, or by session. There is no way to say that the agent burned forty percent of the data budget answering one question badly on a Tuesday night. The information was never captured, because a shared API key does not know which agent invocation used it.
The cost lands in units a manager understands immediately. A quarter of engineering time spent on vendor integrations that a protocol should have handled. A security review that stalls because nobody can produce a per transaction audit trail. And a finance conversation that ends with a spending freeze on the one capability that made the agent worth building.

Why this matters beyond the specific case

Strip the payments detail away and the shape is familiar. A slow, human, contract mediated process becomes an API call, and the governance that was implicit in the slowness has to be rebuilt explicitly somewhere else.
We have run this play many times. Provisioning a server used to require a purchase order, which meant a human reviewed the spend before the capacity existed. EC2 turned that into an API call, and the industry spent the next decade inventing tagging strategies, budget alerts, Service Control Policies and an entire FinOps discipline to replace the governance that the purchase order used to provide for free. Cross account access used to mean somebody mailed you credentials. IAM (Identity and Access Management) roles turned that into an API call, and we spent years learning to write trust policies that did not accidentally grant the internet.
Every one of those transitions followed the same arc. The primitive arrives first. The controls arrive with it, usually adequate. The organizational muscle to use the controls arrives about eighteen months later, generally after somebody's incident becomes a conference talk.
Agentic payments is that same arc with two properties that make the stakes higher than usual.
The first is that the resource being consumed is money, so the blast radius is not measured in compute hours. A misconfigured Auto Scaling group produces an uncomfortable meeting. A misconfigured payment loop produces a transfer that has already settled.
The second property is the one I keep coming back to. Every previous transition kept the spend inside AWS. When your Lambda functions ran hot, the damage showed up in Cost Explorer, in the same bill, in front of the same people who already knew how to read it. Agent payments settle in stablecoins from a wallet held at Coinbase or at Stripe's Privy infrastructure. Your agent's most variable cost now lives outside the system your company built to watch costs. The tooling you spent a decade maturing does not see it.

Technical deep dive

Four resources and one verb

AgentCore payments has a small surface, and the shape of it tells you how AWS is thinking about the problem.
PaymentManager is the top level resource in your account. It carries an authorizer configuration, either AWS_IAM or CUSTOM_JWT, and an IAM role that AgentCore adopts at runtime. It provisions a corresponding workload identity in AgentCore Identity. The documentation suggests separating managers by application, by environment, or by team, which is the same advice you would give for any resource that carries a blast radius.
PaymentConnector attaches the manager to a provider. Two exist in preview: CoinbaseCDP for Coinbase Developer Platform wallets, and StripePrivy for Stripe with Privy wallet infrastructure. The connector references a PaymentCredentialProvider in AgentCore Identity, which stores the provider API keys and wallet secrets in AWS Secrets Manager. The mapping is one to one with the credential provider, and each connector belongs to exactly one manager.
PaymentInstrument is the wallet. The only supported type in preview is EMBEDDED_CRYPTO_WALLET, it is bound to a specific blockchain network, and it moves through the statuses INITIATED, ACTIVE, FAILED and DELETED. It is created per user, it starts with a balance of zero, and it cannot transact until a human funds it and grants signing authorization. One instrument per network, with no reuse of the same address across chains.
PaymentSession is the guardrail. It carries an optional maxSpendAmount with a currency, and an expiry time. Once the session hits its cap or its expiry, further payment requests are denied. This is the object that makes the whole design defensible, and I will come back to it.
Then one verb. ProcessPayment takes the manager ARN (Amazon Resource Name), the session ID, the instrument ID, a paymentType of CRYPTO_X402, the x402 payload, a user ID, and a clientToken UUID for idempotency. It returns a processPaymentId and, on success, a status of PROOF_GENERATED with the signed proof in the response.
Four resources and one verb. Everything else in this article is a consequence of that design.

What x402 actually does

x402 is an open protocol that repurposes the HTTP 402 Payment Required status code, which sat unused in the specification for roughly thirty years waiting for exactly this. Coinbase built it, and it is now governed by the x402 Foundation with both AWS and Coinbase as members. AgentCore implements it, and CRYPTO_X402 is the only payment type the API accepts in preview.
The flow reads like this. Your agent calls a paid endpoint, either directly or through AgentCore Gateway. The merchant answers 402 with a payload describing what it wants: the amount, the recipient address, the token contract, the network, and a timeout. AgentCore checks that amount against the session limit and denies it if it would breach the cap. If it clears, AgentCore retrieves the wallet credentials through AgentCore Identity, constructs the payment proof, and signs the transaction through the connector. The agent retries the original request with the signed proof in an X-PAYMENT header. The merchant verifies the proof on chain and returns the content. AgentCore commits the amount to the session ledger.
The payload fields are worth internalizing because they are what your logs will contain: scheme, usually exact; network, expressed as a chain identifier such as eip155:84532; amount in base units; asset, which is the token contract address; payTo, the recipient wallet; maxTimeoutSeconds; and an extra block carrying metadata such as the token name and version. The current examples in the documentation use version 2 of the protocol.
Settlement is fast and cheap by design. Coinbase describes settlement on Base with USDC, a dollar denominated stablecoin, in roughly two hundred milliseconds at less than a fraction of a cent per transaction. That combination is the entire reason this exists. A card network cannot economically move a tenth of a cent, so the sub cent economy that agent workloads want has never been reachable through traditional rails.

The three phase protocol nobody mentions in the launch post

Buried in the technical deep dive from the AWS team is a detail that separates a real system from a demo. Budget enforcement runs as reserve, process, then commit or rollback.
The requested amount is atomically deducted from the available session budget before the transaction is signed. The payment then executes through the provider. On success the transaction commits to the session ledger. On failure at any step the reservation is released and the transaction is recorded as FAILED.
Read that again from the perspective of an agent loop running with concurrency. Without the reserve phase, two parallel tool calls both read a remaining budget of one dollar, both decide they are within limits, and both spend it. The reservation is what makes the cap hold under concurrency instead of holding only in the happy path. It is the difference between a spending limit and a spending suggestion.
This is also the part of the design I would want to see stress tested before trusting it with a meaningful cap, and I have not done that. Treat my confidence in it as inference from documented behavior rather than scar tissue.

Where the money actually lives

This is the part that surprises architects who expect a corporate billing model.
The wallet is self custodial and it belongs to the end user. create_payment_instrument takes a user_id and a linked account such as an email address, and returns a redirectUrl. The human follows that URL into the provider's own interface, Coinbase WalletHub or the Stripe Privy frontend, funds the wallet through crypto transfer or card or Apple Pay or Google Pay or ACH, and then separately grants the agent authorization to sign. Coinbase calls that primitive Spend Permissions. Privy calls it Delegated Actions.
Two consequences follow. Card details and bank details never touch your systems or AWS infrastructure, which is a genuinely good security property and removes an entire compliance surface from your architecture. And the private keys stay with the wallet provider, so agent code never holds them.
The developer credentials take a different path. Provider API keys live encrypted in the AgentCore Identity token vault backed by AWS Secrets Manager and AWS KMS (Key Management Service), and agent code receives just in time, session scoped tokens through the GetResourcePaymentToken data plane operation rather than the raw credentials.

The IAM model is the actual product

The documented authorization pattern uses four roles, and the reasoning behind it is more interesting than the role names.
ControlPlaneRole administers managers, connectors and credential providers. ManagementRole creates instruments and sessions. ProcessPaymentRole executes payments and reads balances. ResourceRetrievalRole is the service role that AgentCore adopts to fetch credentials, with a trust policy scoped by aws:SourceAccount and an ArnLike condition on the payment manager ARN.
The critical instruction is that ManagementRole must carry an explicit Deny on bedrock-agentcore:ProcessPayment. The documentation is unusually direct about why. An identity that can both create sessions and execute payments can create a session with any budget it likes and then spend it. The limit becomes decorative. Separation of duties is the only thing standing between a compromised identity and an unbounded wallet.
If you take one operational instruction from this article, take that one. It is a two line policy statement and it is the difference between a control and a story about a control.

Discovery, and the two doors into paid resources

Two integration paths matter for architecture.
AgentCore Gateway hosts the Coinbase x402 Bazaar as an MCP (Model Context Protocol) server, exposing what AWS describes as more than ten thousand pay per use x402 endpoints. Your agent discovers and calls paid capabilities without a hardcoded integration per vendor, which is the procurement cycle from section one collapsing into tool discovery.
AgentCore Browser handles the other door. When the paid resource is a website rather than an API, and the site supports x402, the browser tool can transact for access to paywalled content. Warner Bros. Discovery is quoted in the launch material calling this a promising direction for premium content, which tells you which industry is watching.
Governance of which tools an agent may call sits in AgentCore Policy, a Cedar based engine that evaluates requests by agent identity, tool name and parameters. The two controls are orthogonal and you want both. Policy decides which doors open. The session decides how much can go through them.

The build order I would use

Roles first, with the explicit Deny in place before any wallet holds a balance. Manager and connector second. Then a single instrument funded with testnet USDC, from the Circle faucet the quick start points to, against a sandbox endpoint. Sessions with a small cap and a short expiry, tightened rather than loosened later. Observability verified before real value moves, which means confirming that the CloudWatch metrics and the AWS X-Ray spans actually appear, since AgentCore Observability emits both for every ProcessPayment call with no instrumentation code from you.
Only then a real wallet, and only then a real cap.

What the official documentation does not tell you

The spend leaves your AWS bill entirely. The pricing page is explicit that there are no additional charges for the payments API operations beyond the wallet operation fees your provider charges. CreatePaymentInstrument costs one wallet operation with Coinbase CDP and nothing with Stripe Privy. ProcessPayment costs one wallet operation with both. What that page does not say out loud is the consequence: the payments themselves, the actual money your agent spends, never appear in Cost Explorer at all. They come out of a stablecoin balance at Coinbase or Stripe. Your Budgets, your anomaly detection, your cost allocation tags and your monthly FinOps review all watch a bill that no longer contains your agent's most variable cost. Tell your FinOps team this before they discover it, and expect the follow up question about who reconciles the wallet.
Gas is real and I do not believe it counts against your cap. The troubleshooting table says a FAILED ProcessPayment can mean the wallet lacks sufficient USDC and gas fees. The session limit is expressed as a maxSpendAmount in a currency, applied to the payment amount. I have not found documentation stating that network fees are counted inside that cap, and I have not measured it. My reading is that they are not, which would mean a session capped at five dollars can drain slightly more than five dollars from the wallet. Verify this yourself before you size a cap that matters, and treat my reading as inference rather than fact.
The permission trap gives someone an unlimited budget while everything looks correct. Grant CreatePaymentSession and ProcessPayment to the same role and you have not broken anything visible. The console renders normally, sessions carry their caps, the audit trail exists. The control is simply not binding on anyone holding that role, because they can mint a fresh session with a larger cap whenever the current one runs out. This belongs to the same family as the Gateway service role missing bedrock:Retrieve that I wrote about in Week 18 and the Lambda Function URL double permission trap in the Week 02 companion repository. Same signature every time: correct looking configuration, no error message, and a property you believed in that was never actually enforced.
The default wallet model is per user, and most enterprise architectures want per company. Every documented instrument creation takes a user_id and a linked email, the human funds it, and the human grants signing. That model fits a consumer product where the user pays for their own agent's consumption. It does not obviously fit the enterprise case where the company funds the agent and employees consume the capability, and the documentation I read does not lay out that pattern. There are ways to reason toward it, one instrument per service account being the obvious one, and I have not seen AWS bless a specific approach. If your architecture takes a corporate wallet for granted, design that explicitly and validate it early rather than discovering the gap during implementation.
Four regions, and South America is not among them. Preview availability is US East (N. Virginia), US West (Oregon), Europe (Frankfurt) and Asia Pacific (Sydney). For those of us architecting for Brazilian regulated workloads, that alone ends the conversation for anything with a data residency requirement in sa-east-1. It also opens a stranger conversation, because the settlement rail is a public blockchain, which means the residency question here is a different category of question than the one your compliance officer is used to answering. Have that conversation before the proof of concept, with the compliance team in the room, and understand that whether stablecoin settlement is workable for your institution is a legal and regulatory determination rather than an architectural one.
There is no chargeback. A settled stablecoin transfer is final. If a merchant returns garbage for your money, your recourse is whatever that merchant offers, plus the terms of a contract you probably never signed because the whole point was discovering the endpoint through a bazaar. Card rails carry dispute resolution that most engineers have never had to think about because it was always there. This rail does not. Build merchant allowlists for anything above a trivial amount, and keep the discovery driven long tail on a genuinely small budget.
Session expiry is your real blast radius, and the cap gets all the attention. The quick start example uses a five dollar cap with sixty minutes of expiry. Both numbers matter, and teams tune the first while copying the second. A cap of five dollars with a twenty four hour session sitting inside an agent that retries aggressively is a very different risk from the same cap in a sixty minute session tied to one user interaction. Session lifetime should map to interaction lifetime. When in doubt, shorter, because creating a session is cheap and explaining a spending pattern to your CFO is not.
Idempotency is your problem, and agent loops are where double spends live. ProcessPayment takes a clientToken UUID for idempotency, and generating a fresh UUID on every call, as the samples do, means a retried tool invocation is a new payment. Agent frameworks retry. Networks time out after the merchant already got paid. Somewhere in that gap sits a category of bug that costs money instead of latency. Decide deliberately what your idempotency key derives from before you go live.
Preview means the shape will move. The documentation states plainly that features and APIs might change before general availability. EMBEDDED_CRYPTO_WALLET is the only instrument type, CRYPTO_X402 is the only payment type, and both of those are strong hints about roadmap direction rather than permanent constraints. Build the wrapper you would want to have when a second payment type appears.

The bigger picture

There is a protocol race happening right now, and it is worth naming carefully because there is more press release than production in it.
x402 is the one I have verified to primary sources: an open HTTP native standard, an x402 Foundation with AWS and Coinbase as members, and the numbers Coinbase publishes for its first year, more than one hundred and sixty nine million payments across roughly five hundred and ninety thousand buyers and one hundred thousand sellers. Google has published its own Agent Payments Protocol, AP2, and OpenAI and Stripe have published an Agentic Commerce Protocol, and the card networks have been announcing their own agent schemes. I have read AWS and Coinbase material closely and the rest only in outline, so treat my sense of the competitive landscape as informed rather than authoritative.
What I am more confident about is the shape of the outcome. This will settle the way MCP settled, with one or two protocols becoming the seam and the rest becoming adapters. AWS choosing x402 and joining its foundation is a meaningful signal about which seam they expect to hold, in the same way that AgentCore exposing everything as MCP tools was a signal a year ago.
The deeper shift is not about protocols at all. Money is becoming a runtime resource with a quota, and quotas are owned by platform teams. Money is owned by finance. Those two functions have almost no shared vocabulary, no shared tooling, and in most companies no standing meeting. The session cap is a technical control that enforces a financial policy nobody in the room is authorized to set, and I think that gap is where the first serious incidents in this space will come from. Not a broken API. A five dollar cap that a well meaning engineer chose because the sample used five dollars.
I will state the opinion plainly. Within two years, per agent spending policy will be a normal part of enterprise architecture reviews, in the same slot where we currently discuss data sensitivity and residency. The teams that get there gracefully will be the ones who started the treasury conversation while the caps were still measured in cents.
For careers, the implication follows the pattern this series keeps finding. The mechanics are small: four resources, one verb, an afternoon of reading. What is scarce is the person who can walk into a room containing a security architect, a compliance officer and someone from finance, explain what a self custodial wallet with delegated signing means to each of them in their own language, and leave with an agreed spending policy. That is not an AWS skill. It is the skill that makes the AWS skill usable, and it is the one I would be building deliberately right now.
There is also an uncomfortable corollary worth sitting with. When agents can pay for capability directly, the boundary of your architecture stops being the set of systems you integrated. It becomes the set of things your agent can find and afford. That is either the most useful property of this technology or the most alarming one, and which of the two it turns out to be in your company depends entirely on decisions made in the first week, before anyone thinks it is important.

Takeaway

Four resources and one verb. PaymentManager, PaymentConnector, PaymentInstrument, PaymentSession, then ProcessPayment. The API is the easy afternoon.
The session cap is deterministic and enforced outside the model, which is what makes the design trustworthy under prompt injection. That property survives exactly as long as no single role holds both CreatePaymentSession and ProcessPayment. Write the explicit Deny first.
And the money your agent spends will not appear on your AWS bill. Whoever owns cost governance in your company needs to hear that from you rather than from a reconciliation surprise.
One question I keep turning over. Who should own the wallet, platform engineering or treasury? Platform owns the quota, understands the failure modes, and can enforce a cap in an IAM policy. Treasury owns money, understands reconciliation and audit, and has never in their working life had to think about gas fees on a Tuesday. Every answer I construct feels like it puts the control in the right place and the accountability in the wrong one. If you have already run this decision through a real finance organization, I want to know where it landed and what broke first.

References

About the author

I am an AWS Solutions Architect with almost 15 years in cloud, focused on production ML and GenAI workloads for regulated organizations. I hold every active AWS certification, including the Generative AI Developer Professional as an Early Adopter, the status AWS calls Golden Jacket. I am the sixth Brazilian Golden Jacket holder according to the Awstronauts list, and co-founder of Golden Jackets Brazil.
Golden Jacket Field Notes is a weekly practitioner series. No re:Invent recaps. No tutorials. Field notes from workloads where outages, audit gaps, and cost surprises are not tolerated. The full index lives at golden-jacket-field-notes .
<sub>Opinions expressed in articles and code are my own and do not represent the views of my employer or any affiliated organization.</sub>
#AWS #AmazonBedrock #AgentCore #AgenticPayments #x402 #AIAgents #GenerativeAI #CloudArchitecture #FinOps #GoldenJacket
# amazon-bedrock-agentcore# aws-payment-cryptography# amazon-bedrock# amazon-bedrock-agents# knowledge-bases-for-bedrock

Series: Golden Jacket Field Notes (22 articles)

  1. 1
    The Cheapest Price Per Token Can Be the Most Expensive Way to Run an LLM
  2. …
  3. 16
    Your Agent Has a Wallet Now, and the Spend Does Not Show Up on Your AWS Bill This article
  4. 17
    The AWS Generative AI Professional Exam: What the Blueprint Doesn’t Reveal
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article