When AI Agents Pay and Sellers Monetize: Building x402 Apps on AWS — Anil Nadiminti, AWS

A news portal works until the reader hits a paywall. A human can enter credit card details, choose a weekly, monthly or annual subscription, and obtain access. An autonomous agent encounters the same obstacle while completing a task, but the next step becomes a request for help: someone must supply payment details or an API key. Anil Nadiminti, a Senior Solutions Architect at AWS, starts with this familiar example because it exposes where autonomy breaks. The agent can find the content; it cannot finish obtaining it.

The urgency comes from a change in who requests resources. Nadiminti puts bot traffic above human traffic and says AI agents account for 95 percent of that bot traffic. The recording does not establish the population or measurement method behind those figures, so they serve as his framing rather than a universal traffic estimate. His forecast—about a billion agents performing tasks by 2027, with 60 percent of enterprises using agentic workflows—extends the same premise: more requests will arrive from software trying to complete work independently.

The news publisher has an uncomfortable choice:

• Block bots: Blocking can forfeit AI discovery, citations and potential licensing partnerships. Content that an agent cannot reach is harder for it to incorporate into an answer.
• Allow unpaid access: Large numbers of requests create infrastructure costs, while unrestricted reuse can weaken attribution and control over the content.

Paid machine access offers another option: let the agent obtain the resource and let the publisher earn from the request.

Agent ecommerce joins two different requirements. On the buy side, an agent needs access to premium or licensed resources, a wallet and the ability to make small payments. An enterprise also needs to prevent that agent from going on a spending spree. On the sell side, a publisher needs to understand the requesting bot and charge for its activity without rebuilding the origin—the infrastructure that stores and serves the content. A shared machine-to-machine payment protocol lets these sides meet at the request.

The proposed change is from approving each purchase to setting conditions under which purchases may happen. Humans move from being in the transaction loop to supervising it, or staying outside it once limits are configured. Pay-per-use and pay-per-execution can then follow the agent's work at request speed, rather than requiring a new human subscription workflow whenever it encounters a paid resource.

Small payments make the fee structure decisive. Nadiminti uses a card-payment example with a 25-cent minimum fee plus 2.5 percent. For a purchase worth a tenth of a cent, the fixed fee alone is 250 times the purchase: $0.25 ÷ $0.001 = 250. The percentage fee barely matters beside that floor. Charging separately for each tiny resource request therefore requires a payment path whose overhead fits the size of the purchase.

x402 builds on HTTP status code 402, reserved for “Payment Required.” Nadiminti presents the protocol introduced by Coinbase as a way for machines to negotiate access through HTTP. Return to the news portal: instead of sending the agent into a human checkout, the server responds that payment is required. The client chooses a payment method and sends payment authorization back to the server.

Authorization is followed by verification and settlement. The server uses a facilitator to verify the payment authorization and complete the transaction. In the flow described here, the server releases the content after settlement completes on chain. The observable change is simple: the resource request that previously stalled now reaches the content response through a payment exchange.

What must happen between the first request and delivery of the content? The diagram separates the HTTP exchange from the facilitator's work. Payment authorization starts the transaction process; completed settlement is what precedes content delivery.

This is the force of the phrase “payment is the … credential”: the purchase itself enables access, without setting up a subscription or a separate API key for that resource. Nadiminti describes no protocol fee and nominal merchant gas fees. His description of “zero wait time” means an automated request-speed experience, rather than literal zero latency; the later figures include a 200-millisecond average settlement time on Base.

The protocol is also presented as extensible and open to implementation. Nadiminti dates its introduction to May 2025 and describes Linux Foundation open governance, with support from Coinbase, AWS, Google, Stripe, Anthropic, Cloudflare and Circle. That shared protocol supplies the connection between the AWS buyer and seller services introduced next.

AgentCore Payments, part of Bedrock AgentCore, supplies the buyer's payment machinery. The service described in the recording supports Coinbase wallets and a Stripe preview wallet option, with payment connectors orchestrating transactions. It supports x402 at the time of the presentation; support for additional protocols is planned. Protocol independence is a design goal, while x402 is the concrete path shown.

A payment session constrains spending programmatically. It can specify a maximum amount and an expiry expressed in minutes. Nadiminti's example is permission to spend $5 over 30 or 60 days. The amount limits how much the session can spend; the expiry limits how long that permission lasts. Built-in observability is intended to let developers trace the activity across the stack.

The agent continues using tools, MCP servers and other resources to complete the user's task. When one of those requests returns 402, AgentCore Payments handles the transaction and tells the agent that settlement has happened. The agent can then continue toward its response. Applied to the opening example, the news paywall becomes a payment event handled by the configured service, rather than a reason to ask the user to enter card details mid-task.

Discovery is another part of the buyer's path. AgentCore Gateway exposes internal APIs through MCP, making them available as agent tools. Its integration also gives AgentCore Payments access to a Coinbase discovery service that Nadiminti describes as offering more than 10,000 endpoints available for transactions. Finding a purchasable resource and paying for it are thus separate capabilities connected through the gateway and payment service.

The wallet integration does not give the agent its private keys. Imported secret keys are stored in a secure token wallet protected by KMS, and the agent cannot access them. That distinction matters: an agent may request a paid resource without receiving the secrets that enable the payment infrastructure to transact.

Payment execution is also decoupled from the agent's reasoning loop. Skills and inputs can be poisoned by malicious actors, so the payment path runs in a deterministic layer responsible for connectors, orchestration, limits and third-party wallet integration. The model can continue choosing tools and pursuing the task, while spending controls operate outside its nondeterministic decisions. This design contains payment authority; it does not make poisoned agent inputs harmless.

Where does a resource request cross into payment execution? The diagram shows the 402 response triggering the separate payment layer, with session controls and protected wallet keys attached to that layer. The return path communicates settlement to the agent rather than passing private keys into its loop.

The separation also supports reuse of existing agent models and frameworks. Nadiminti describes payment handling as a layer that can operate without changing the agent's code. In the narrated demo, an agent discovers a secured resource, AgentCore Payments uses an already integrated wallet, and the transaction completes. The change from the opening paywall is the removal of the manual payment interruption, with the wallet and controls configured beforehand.

The seller needs enough information about a request to choose a price. Nadiminti describes AWS Web Application Firewall bot detection as recognizing more than 650 bot types, verifying bots by signature and identifying intent, such as model training or retrieval-augmented search. Identity and intent answer different questions: which organization is requesting the content, and what kind of use is the request associated with? The talk does not explain the intent-classification method or its accuracy, so intent-based pricing depends on that classification working.

WAF AI traffic monetization applies that context at the edge. With CloudFront, the content distribution network, a publisher can attach WAF and configure monetization through the console or infrastructure as code. Nadiminti also describes applying WAF to internal APIs exposed through AgentCore Gateway as MCP tools. In both cases, the seller adds payment handling in front of an existing resource rather than moving the resource into a new application.

The seller-side flow detects and categorizes the bot, identifies its intent, verifies it and uses x402 to monetize the request. The service is presented as requiring no SDK or origin changes, with publishers retaining 100 percent of revenue and no transaction or subscription fees. Those claims concern the monetization service; they do not remove the infrastructure costs that motivated the seller's dilemma or the gas fees described in the protocol discussion.

Pricing can use several independent dimensions:

• Path: /blog, /research and an API endpoint can have different rates because they expose different resources.
• Identity: A verified bot from an organization with an existing commercial relationship can receive a different price from an unverified bot. Anthropic is the example partner in the talk.
• Intent: Training access can have a different rate from search access.

WAF rules combine these conditions with AND/OR logic. A seller can therefore price a request using several attributes together, rather than charging every bot the same amount.

The news portal can now distinguish human readers, verified bots and unverified bots. Human access might remain free or carry its own price, while bots follow different payment rules. Revenue dashboards aggregate results by bot and show the paths being accessed, giving the publisher a way to inspect which resources and requesters contribute to its revenue model.

Paid news access is only one use. The closing examples include LLM inference, compute, web scraping, research agents, agent-to-agent transactions and monetized MCP services. Each gives an agent a resource or capability it can purchase while performing work. The same request-and-payment pattern can therefore apply to executing a tool as well as reading a page.

For the preceding 12 months of Coinbase marketplace activity, Nadiminti reports $50 million in transaction volume across 170 million transactions. He also gives an average settlement time of 200 milliseconds on Base and a cost of about a tenth of a cent per transaction. These figures describe the cited activity and settlement setting, rather than a benchmark of the AWS services. They make the economic target concrete: many small purchases need both low payment overhead and short settlement delays.

Payments sit within the larger Bedrock AgentCore ecosystem. Builders can bring their own model and framework, add memory, use managed knowledge bases and web search, expose internal APIs through MCP, and evaluate agent performance. AgentCore Runtime hosts the agentic application at scale; Nadiminti describes each request as running in its own isolated micro virtual machine. The final architecture keeps these jobs distinct: the runtime serves the agent, the gateway connects resources, and the payment layer handles purchases when access requires them.