An AI agent that pays for its own API calls on AWS A developer built an AWS Bedrock AgentCore agent that autonomously pays for paywalled API calls using real USDC on Arbitrum One, bypassing the need for API keys or human approval. When the agent receives an HTTP 402 Payment Required response, it settles the charge on its own and retries the request, with the transaction recorded on the Arbitrum One mainnet. The project, which is open-source on GitHub, uses AgentCore's embedded wallet and Coinbase CDP connector to handle micropayments, while the merchant infrastructure runs on CloudFront, Lambda@Edge, and API Gateway. I built a small AWS Bedrock AgentCore agent that pays for a paywalled API with real USDC on Arbitrum One. It asks for a report, gets back HTTP 402 Payment Required, settles the charge on its own, and retries. No API key, no card on file, no human clicking approve. The settlement lands on Arbitrum One mainnet, and the run prints an Arbiscan link to the transaction so you can read it yourself. There's a great walkthrough of the same idea on Base Sepolia by William Mendoza Gopar https://william.mendozagopar.com/blog/bedrock-agentcore-x402.html . This post expands upon his work: mainnet instead of testnet, real USDC instead of a burn-address demo, and a merchant built on CloudFront, Lambda@Edge, and API Gateway. The full source is at github.com/hummusonrails/arbitrum-x402-aws https://github.com/hummusonrails/arbitrum-x402-aws . AgentCore is AWS's hosted runtime for AI agents, still in preview. The piece this project leans on is AgentCore Payments: a managed signer that holds an embedded wallet for you and produces payment authorizations on request. Your code asks the PaymentManager to handle a charge, and the private key stays inside AgentCore. You stand up four resources once: a PaymentManager with a connector to Coinbase CDP, an embedded crypto wallet as a PaymentInstrument, and a PaymentSession that carries a spend budget and an expiry. After that, paying is a single call. x402 puts the 402 Payment Required status code to work. A paid endpoint answers an unpaid request with 402 and a JSON body describing what it wants: the network, the token, the recipient, and the amount. The client signs an EIP-3009 transferWithAuthorization for USDC, which lets someone else submit the transfer on-chain, and resends the request with the signature attached. The server verifies and settles through a facilitator, then returns the content. No accounts to create, no keys to rotate, and charges as small as a fraction of a cent. That last property is what lets an agent use it with no human in the loop. One aside on the AWS side: this x402 support is a brand-new preview release. This week I worked with the AWS team to make sure it settles across EVM chains, Arbitrum One included, so the wallet, the facilitator, and the settlement path behave the same way on Arbitrum as on any other EVM network. An agent that pays per API call cannot spend a dollar in transaction fees to move a fraction of a cent. The math only works if the settlement layer makes sub-cent payments cheap enough to vanish into the cost of the call itself. Arbitrum One clears that bar on price. Price is half of it. The other half is predictability. An agent commits to a workflow and runs it; it cannot pause to renegotiate when gas spikes partway through. When fees jump for a few minutes, a person shrugs and waits, but an agent paying per call either overpays or stalls. Arbitrum's gas pricing is built to absorb those spikes. The recent Arbitrum One upgrade replaced the old single-target pricing model, and during peak activity it cut gas by around 98% compared to what that model would have charged. Fees stay low, and they stay close to where they were a minute ago. For x402 micropayments, that stability is worth as much as the headline number. Three pieces talk to each other. The agent runs on AgentCore with its embedded CDP wallet. The merchant is an AWS stack: CloudFront in front, a Lambda@Edge function on viewer-request that speaks x402, and an API Gateway HTTP API with a Lambda behind it that holds the report. Settlement runs through the Coinbase CDP facilitator, which broadcasts the USDC transfer on Arbitrum One. The round trip looks like this. The agent does a GET /report . Lambda@Edge sees no payment and returns 402 with the terms. The agent asks AgentCore to produce a payment for those terms and retries. This time Lambda@Edge has a payment header, calls the facilitator to verify and settle, and on success passes the request through to API Gateway, which returns the gated JSON. The agent code is short because the wallet logic lives in AgentCore. It makes a normal GET. If the response is anything other than 402, it returns it. If it is a 402, it hands the whole challenge, status, headers, and body, to generate payment header , which reads the terms, signs the authorization inside the embedded wallet, and returns the header to attach. Then it retries the GET. python def fetch with payment , client, payment manager, url, user id, payment instrument id, payment session id : first = client.get url if first.status code = 402: return first payment required request = { "statusCode": 402, "headers": dict first.headers , "body": first.text, } proof headers = payment manager.generate payment header user id=user id, payment instrument id=payment instrument id, payment session id=payment session id, payment required request=payment required request, network preferences= "eip155:42161" , Arbitrum One client token=str uuid.uuid4 , return client.get url, headers=proof headers I pass network preferences= "eip155:42161" so the payment targets Arbitrum One rather than relying on a default. The agent never builds EIP-712 typed data and never touches the private key. From the caller's point of view it made one GET and got back a 200 with the report and an Arbiscan link. The payment logic sits in the Lambda@Edge function on viewer-request . With no payment header it returns the 402 and the accepts terms. With a header it decodes the payment, calls the CDP facilitator's /verify , then /settle , and returns the original request so CloudFront continues on to API Gateway. A verify or settle failure comes back as a fresh 402 or a 502. One detail to note: CDP's facilitator uses short-lived JWTs that are bound to the exact request URL and method and expire in two minutes. You cannot mint one ahead of time and paste it into config. The edge function signs a fresh JWT with node:crypto for each verify and settle call, which is also why the CDP key material gets inlined into the edge bundle at build time Lambda@Edge cannot read environment variables at runtime . A design choice worth flagging: this version verifies and settles in viewer-request , before the origin responds. That keeps the demo to one function and one round trip. For production you want to verify in viewer-request and settle in viewer-response , so you only take the money after the content is delivered. Setup is one command that creates the AgentCore resources and prints a wallet address. You fund that wallet with USDC on Arbitrum One, grant the agent signing permission, and paste the printed IDs into .env . Then: bash $ make run-agent GET https://