When AI Agents Pay and Sellers Monetize: Building x402 Apps on AWS — Anil Nadiminti, AWS
Description
Card rails put a floor under every transaction: a 25 cent minimum with a percentage on top. Anil Nadiminti's point is that when an agent pays a tenth of a cent for a single API call, that floor costs roughly 250 times the thing being bought, which is why the subscription model cannot simply be pointed at agents. Meanwhile the traffic has already turned over. He puts bot traffic past human traffic on the open web, with the large majority of it coming from AI agents, leaving sellers to choose between blocking it, which forfeits discovery, citations and licensing revenue, or absorbing it, which means carrying the infrastructure cost and losing attribution. His framing for the way out is that the human moves from in the loop to out of it, and the payment becomes the credential. The AWS pieces land on both sides of that. On the buy side, AgentCore Payments gives an agent a wallet, a connector layer built to be protocol agnostic, and per session spending limits with an expiry. Two design choices carry the security argument. Imported wallet keys sit in a KMS backed store the agent cannot read, and the payment path is decoupled from the agent loop entirely, on the reasoning that skills and inputs can be poisoned and payment has no business running on a nondeterministic path. On the sell side, bot detection at the edge classifies over 650 bot types, verifies them by signature and infers whether a request is for training or for search, which lets a publisher price by path, by whether the bot belongs to a known partner, and by intent, without touching the origin. Speaker info: - https://x.com/super_intel_bot - https://www.linkedin.com/in/nadiminti Timestamps: 0:00 - A paywall built for humans, and traffic that is not 1:08 - Bot traffic passes human traffic 2:58 - The seller's dilemma: block bots or absorb them 6:36 - Why a 25 cent floor kills a microcent payment 7:31 - The x402 flow, end to end 9:23 - AgentCore Payments, and setting spend limits 12:12 - Why the agent never
Summary
Generated by gpt-5.6-terraAt-a-Glance
- Verdict: Watch fully
- Core thesis: AWS positions x402 as the payment primitive that lets autonomous agents buy paywalled content and API access at internet speed, while Bedrock AgentCore Payments and AWS WAF provide the buyer-side controls and seller-side monetization layer.
- Why it matters: This is a concrete architecture for agentic commerce: agents can encounter a 402 response, pay within tightly scoped policy limits without handling private keys, and access resources; publishers can price and govern AI traffic at the edge without rewriting origins.
- Best use: Use it to evaluate x402 as a near-term protocol layer for paid agent tools, APIs, MCP servers, research sources, and usage-based monetization—not as a general replacement for conventional enterprise payments.
Executive Summary
The presentation argues that autonomous agents will increasingly fail at conventional paywalls because card-based checkout, subscriptions, API-key provisioning, and human approval interrupt an agent’s execution loop. Sellers face an equally unattractive choice: block bots and lose AI discovery, licensing, attribution, and new revenue, or permit unrestricted bot access and absorb infrastructure cost while giving away valuable content. The proposed middle path is agent e-commerce: agents discover resources, make machine-to-machine payments, and receive access programmatically.
The underlying standard is x402, built around HTTP 402 Payment Required. A server returns payment requirements; the client selects a method and submits authorization; a facilitator verifies and settles the transaction on-chain; the server then returns the requested resource. The speaker’s commercial case is that card economics cannot support cent, sub-cent, or micro-cent usage: a cited $0.25 minimum fee plus 2.5% can make the fee roughly 250 times the price of a one-tenth-cent transaction.
AWS’s buyer-side offering, Bedrock AgentCore Payments, aims to isolate payment execution from the probabilistic agent loop. It supports Coinbase and Stripe Preview wallets, x402 connectors, per-session budgets and expiry, instant settlement, and observability. Crucially, imported wallet secret keys are stored in a KMS-secured token wallet and are not exposed to the agent. The architecture is intended to limit damage from poisoned skills or malicious agent inputs by keeping payment controls deterministic and outside the agent’s direct control.
On the seller side, AWS WAF AI Traffic Monetization combines CloudFront/WAF edge controls, bot detection, bot verification, intent classification, x402 charging, and revenue analytics. A publisher can apply different prices by URL path, bot identity or verification status, and asserted intent such as training versus search/RAG. The presentation is product-forward and contains limited detail on trust boundaries, dispute handling, intent-classification accuracy, regulatory treatment, wallet custody, and real-world adoption; those are the areas to validate before treating the model as production-ready.
Key Takeaways
- Claim: x402 is designed to convert HTTP 402 Payment Required into a standardized machine-to-machine payment flow suitable for autonomous agents. | Evidence: The described flow is: client requests a resource; server replies with 402; client determines payment method and sends authorization; a facilitator verifies and settles on-chain; the server returns the content. The protocol was introduced in May 2025 and is described as being under Linux Foundation open governance with support from Coinbase, AWS, Google, Stripe, Anthropic, Cloudflare, and Circle. | Implication: For paid agent-accessible services, x402 is worth treating as an emerging interface contract: return a machine-readable payment challenge rather than building bespoke agent checkout flows. | Caveat: The transcript presents ecosystem backing and governance but does not establish broad production adoption, interoperability across wallets/chains, or the maturity of non-x402 payment connectors.
- Claim: Microtransaction economics are the primary reason conventional card/subscription payment rails are poorly suited to agent-driven usage pricing. | Evidence: The speaker contrasts cent, sub-cent, and micro-cent transactions with a conventional cited fee of $0.25 minimum plus 2.5%, stating that the minimum alone is about 250 times a one-tenth-cent transaction price. Coinbase agentic-market activity is cited at $50 million across 170 million transactions in 12 months, with approximately 200 ms settlement and around $0.001 transaction cost on Base. | Implication: Usage-based agent services can potentially monetize actions that are too small for card rails, including individual API calls, data lookups, inference, compute, scraping, research, and MCP tool access. | Caveat: These are speaker-provided market and network figures; they do not include operational costs such as wallet management, compliance, fraud/dispute processes, or volatility/fiat-conversion costs.
- Claim: Payment execution should be architecturally separated from the LLM-driven agent loop rather than placing private keys or spending authority inside the agent. | Evidence: AgentCore Payments detects a 402 response and handles settlement separately. Wallet import keys are stored in a KMS-secured token wallet, while the agent has no access to private keys. The presenter explicitly frames this isolation as protection against poisoned skills and malicious inputs, with payments kept on a deterministic path. | Implication: Ken should treat payment as a privileged control-plane capability: agents may request a purchase, but a separate deterministic policy service should enforce spend limits, approved counterparties, permitted resource types, and session expiry. | Caveat: Separation reduces direct key exposure but does not solve authorization quality: an agent can still be induced to request an expensive or inappropriate resource if policy, vendor allowlists, purpose controls, and budget scopes are weak.
- Claim: Bedrock AgentCore Payments supplies a buyer-side control plane for agent spending, initially through Coinbase and Stripe Preview wallets and x402. | Evidence: AWS describes wallet support, payment connectors/orchestration, instant settlement, payment limits, and full-stack observability. Payment sessions can set a maximum spend value and an expiry in minutes; the example describes allowing an agent to spend $5 over 30 or 60 days. AWS says the service is protocol-agnostic, although x402 is the supported protocol today. | Implication: The useful design pattern is not AWS-specific: use ephemeral, budgeted payment sessions rather than durable open-ended agent wallet authority, and record each payment decision end-to-end. | Caveat: The offering’s wallet support is specifically described as Coinbase and Stripe Preview, and the transcript does not specify regional availability, identity/KYC requirements, ledger/reconciliation capabilities, or the exact policy model.
- Claim: AWS WAF AI Traffic Monetization lets sellers monetize agent traffic at the CDN/WAF edge rather than changing origin applications. | Evidence: The product combines CloudFront with WAF and is presented as requiring no SDK or origin change. AWS says WAF detects more than 650 bot types, can verify bot signatures, analyze traffic in real time, and classify access intent. x402 is used to charge and settle before access is granted. | Implication: For content/API businesses, an edge-based monetization layer can be piloted without rebuilding the core service, but pricing policy should initially rely on high-confidence signals and conservative entitlement rules. | Caveat: Bot identity and especially intent classification are security- and revenue-critical assertions; the presentation gives no accuracy rates, spoof-resistance details, appeal/dispute process, or evidence that claimed intent can be reliably enforced.
- Claim: The seller monetization model supports differentiated prices by resource, bot relationship, and use case instead of one universal bot policy. | Evidence: The speaker gives separate pricing examples for /blog, /research, and API endpoints; verified partner bots versus unverified bots; and training access versus search/RAG access. These rules can be combined with logical AND/OR conditions, while dashboards report revenue by bot and accessed path. | Implication: A practical initial offer is a narrow paid surface—such as premium research endpoints or metered MCP tools—with explicit pricing tiers for known counterparties, rather than attempting to monetize all crawler traffic at once. | Caveat: Differentiating price based on declared or inferred use may create contract, audit, and enforceability problems if a bot’s downstream use cannot be proven.
- Claim: AWS is framing payments as one component of a broader agent platform rather than a feature embedded in one model framework. | Evidence: The presentation connects AgentCore Payments with AgentCore Gateway for exposing internal APIs as MCP-compatible tools, plus memory, managed knowledge bases, web search, evaluation, and a runtime that runs each request in an isolated micro-VM. AWS states developers can bring their own model and agent framework. | Implication: The strategic opportunity is an end-to-end agent service stack where tool exposure, policy, identity, payment, observability, and runtime isolation are coordinated; payment should not be evaluated as a standalone wallet integration. | Caveat: The transcript is an AWS product presentation and does not compare architecture, cost, lock-in, or operational tradeoffs with alternatives.
Detailed Brief
The business-model transition from subscriptions to programmatic consumption
- Claims: The speaker expects subscriptions designed for humans to shift toward pay-per-use and pay-per-execution as agents become the principal consumers of digital resources.; Publishers that simply block bots sacrifice possible discovery, citations, partnerships, and licensing revenue; publishers that allow all bots risk escalating infrastructure cost and reduced control of proprietary content.; The stated agent-commerce market already includes LLM inference, compute, web scraping, research agents, agent-to-agent transactions, and monetized MCP servers.
- Evidence: The speaker claims bot traffic has surpassed human traffic and that 95% of bot traffic comes from AI agents.; The presentation projects one billion agents performing tasks and 60% of enterprises using agent workflows by 2027.; The suggested operating model moves humans from being in the payment loop to being on the loop or out of the loop.
- Caveats: The presentation does not source or qualify its adoption forecasts or bot-traffic percentages.; The economics of metered access only work where the resource has enough marginal value, payment acceptance is widespread, and pricing does not exceed the agent’s cost of finding substitutes.
- Implications: Agent-facing products need a pricing unit aligned to a completed action or retrieved resource, not solely a monthly seat or human login.; Content owners should segment agent access as a product channel with its own economics and rights policies rather than treating all automated traffic as abuse.
Unresolved operational questions before deployment
- Claims: The proposed architecture provides a credible control split—agent reasoning requests access, while a dedicated layer settles payment—but production deployment requires governance beyond a spend cap.; Seller-side differentiation depends on confidence in bot identity, verification, and purpose signals.
- Evidence: The service offers session value ceilings, time expiry, connector selection, wallet isolation, and observability.; WAF pricing can vary based on bot verification and training versus search intent.
- Caveats: The transcript does not address who approves wallet funding, how organizations reconcile on-chain settlement with accounting, fraud and theft recovery, sanctions/KYC/AML obligations, consumer or enterprise refunds, or pricing-dispute resolution.; It does not explain whether requests are cryptographically bound to stated intent, how bots cannot spoof a verified identity, or how access rights persist after settlement.
- Implications: Any pilot should include a payment-policy review, a restricted counterparty list, comprehensive audit logs, a reconciliation process, and a manual kill switch.; Measure conversion, revenue per bot class, cost-to-serve, verification failures, and unauthorized/low-value purchases before expanding pricing coverage.
Notable Concepts & Terms
- x402: An emerging protocol using HTTP 402 Payment Required to enable machine-to-machine payment authorization and settlement before a server delivers a protected resource.
- HTTP 402 Payment Required: A historically reserved HTTP status code repurposed here as the server’s machine-readable signal that access requires payment.
- Facilitator: The protocol participant described as verifying payment authorization and settling the transaction on-chain before the seller releases content.
- Bedrock AgentCore Payments: AWS’s buyer-side payment orchestration service for agents, offering wallet connectors, x402 support, scoped payment sessions, security isolation, and observability.
- Payment session: A programmatically created authorization boundary that constrains maximum agent spend and expiry duration, intended to prevent open-ended wallet access.
- AWS WAF AI Traffic Monetization: AWS’s seller-side edge product for detecting, verifying, classifying, pricing, and monetizing AI-bot requests through WAF/CloudFront policies.
- MCP-fy: AWS’s term for exposing internal APIs through an AgentCore Gateway as MCP-compatible tools that agents can discover and call, potentially with monetization.
- Deterministic payment layer: The design principle of moving credentials, authorization, limits, and settlement outside an LLM’s non-deterministic reasoning path.
Operator Notes / Why Ken Should Care
- Run a small x402 evaluation for one high-value, easily metered agent capability—such as a premium research endpoint, paid data lookup, or MCP tool—rather than exposing broad content access.
- Define a payment policy schema before integrating any wallet: per-session cap, aggregate cap, expiry, approved payees/domains, permitted tool/resource classes, unit-price ceiling, and a global emergency disable.
- Keep signing keys and wallet credentials outside the agent runtime; require a deterministic payment service to validate each proposed transaction against policy and emit an auditable decision record.
- For any seller-side pilot, begin with verified counterparties and explicit contract-based pricing; do not price on inferred training-versus-RAG intent until signal quality and enforcement are validated.
- Validate the actual x402/AgentCore availability, supported wallet and settlement networks, compliance posture, accounting/reconciliation path, and operational fees before committing to an AWS-specific design.
- Instrument the pilot around economic quality, not just payment success: successful paid retrievals, cost-to-serve, agent abandonment, repeat buyers, disputed transactions, policy denials, and bot-verification error rates.
Source/Metadata
- Title: When AI Agents Pay and Sellers Monetize: Building x402 Apps on AWS — Anil Nadiminti, AWS
- Transcript words: 4934
- Duration seconds: 1240
- Timestamp note: No timestamps or chapters were provided. The transcript includes substantial repeated material in the latter portion.
Transcript
Hello, welcome to the Agent E-Commerce track, and I'm Anil Larmity. I'm a senior solutions architect here at AWS. I'm here to talk to you today about how AWS is innovating and how you can build apps on AWS to support Agent E-Commerce. So welcome to the session. Just to get you started, let me set the stage with something that you're very familiar with. Imagine that you or your organization is building a news portal like this, right? You're all familiar with something where you're accessing the news content, and then suddenly you hit a paywall, right? So this is where you pull out your wallet, or you try to figure out how to make the payments, set up your credentials, access keys, in the sense that you make a credit card transaction, weekly, monthly, or annual subscription, and then get started to access the content, right? So this is all the content that is behind a paywall. But what we see now is that much of the traffic that is actually being sent to these portals on the internet is all coming from bots. We see that we're at an inflection point where the bot traffic is more than the human traffic, right? In fact, it's just surpassed that. And 95% of that bot traffic is coming from AI agents. So essentially, we are also looking at the rise of autonomous agents, right? We all started using LLMs, asking questions, asking for summarization, being able to get help with using them as co-pilots, getting them to do agent work, to do multi-step tasks. And now we are in the phase of autonomous agents, where agents are using the reasoning powers of large language models to complete a task. And completing a task means that it has to go do whatever you're asking it to do. That's where we are in the journey. And we see that by 2027, about a billion agents will be performing tasks, and 60% of the enterprises will already be using agent workflows. So what happens when agents hit these paywalls that we just saw? When agents hit the paywalls, they stall, they can't operate, and you see those messages that, hey, I cannot access content, right? So at that point, humans get in the loop. They try to enter and put the credit card details or API keys to those transactions for the AI agents. But all of that is manual friction, right? So essentially, bringing in a human in the loop. Autonomous agents actually break at that point, where the friction is now building up. So now sellers of the content have a couple of options, right? They can block all their bot traffic, but by blocking all the traffic, they lose this AI-powered discovery, they miss these partnership licensing options, and AI also now supports citations, right? So the responses. So they lose all of those powered citations as well if they can't sell the content. Essentially, they lose revenue-generating options. And if you allow the bots to access the content, what it means is that hundreds of thousands of bots or millions of bots could be hitting your infrastructure, which means that the infrastructure costs will also rise, and you need to be able to support all of that, right? Also, when you allow bots to access content, you lose attribution, the IP itself, right? Because content is now freely available. So both these decisions are probably not a good option. They're not ideal. So there should be another ideal option where you would want to have your AI agents be able to get and pay for the content that they are looking for and monetize on that. So now we look at the next phase of rising autonomous agents, where agents should be able to transact and discover other agents' resources and essentially make payments, right? So this is the definition of agent e-commerce, where AI agents can essentially discover. It's a form of e-commerce where autonomous agents can discover independently and make those settlements and then access content. So let's look at agent e-commerce, the two sides of agent e-commerce: the buy side and the sell side. So when we talk about the buy side, the agents are making these transactions. And on the sell side, the sellers of the content are trying to monetize the content. So on the buy side, when you look at things, AI agents want to access this premium paywall content, licensed content. They want to be able to hold wallets, which they do not have the option to do today. And they want to be able to make these microtransactions you just heard in the prior talk as well. But enterprises, when they come to this point, want more guardrails, and they do not want agents to go on a spending spree. Think about it, right? Would you allow your AI agents to get a handle on your wallets or credit cards to be able to do that, right? Transactions where they could go rogue as well, right? So that's what the buyer side is looking at. And on the seller side, there are, again, billions of transactions that will be happening with these AI bots. So sellers really want to be able to understand what kinds of bots are operating, what kinds of transactions they're making, and really do this at the edge. The sellers don't want to change their entire infrastructure and origins where the content is sitting. They want to be able to do this at the edge without changing much of this, right? So there is, again, one common thing here on the buyer side and the seller side, which is a standardized approach or a protocol to be able to solve for this machine-to-machine payments at the edge. So bottom line, buyers are saying that they want their agents to be able to pay for content and not have humans approving this. And then the sellers are saying that they want to be able to earn from the AI traffic. So bottom line, the subscription model is going to change from humans in the loop to becoming humans on the loop or out of the loop. And that's what we are building toward. The traditional one-size-fits model does not work anymore because of the fact that, again, we look at that in the next slide, where the transaction costs will not really work, right? All of this needs to be happening at real-time speed, and the pay-per-use and pay-per-execution model is what the future is going to look like. So if you're a seller, you would have come across this, right? There is a 25-cent minimum transaction fee as well as 2.5% on top of that. And all of these microtransactions are in a cent, sub-cent, or micro-cents, is what we are calling them. So if you add 25 cents on top of that, it's essentially 250 times what they are essentially paying for. So all of this model does not work. And while we are trying to solve for that, a very brief history of this is every HTTP call essentially responds back. There is a response for that. You've seen 200 status codes, 404, and 301. These are all status codes that you're familiar with. And then there is one status code, which is 402, which has not been used. It was reserved for payment required. And now finally Coinbase has introduced this as transactions over 402, which is also called X402, where the protocol talks about how you can do machine-to-machine transactions using this protocol, right? So we'll take a closer look at that. But what happens within the protocol is, if you look at this flow chart here, a client makes a request to the server, and then the server responds back with the payment required. The client then figures out what is the payment method that it wants to operate, and then it sends the payment authorization to the server. The server then utilizes a facilitator to complete the verification and also utilizes the same facilitator to complete the transaction. And once the settlement is completed on-chain, essentially the server will then respond back with the content, right? So this is what's happening under the X402 protocol. I thought I'll pick one of the protocols and just explain this to you. But why this is compelling is, essentially, there are no protocol fees, or the fees that a consumer is paying for these micro-send transactions, and the merchant is paying very nominal gas fees. Again, there is zero wait time. This is happening at the speed of the internet, and there is no friction. There are no API keys to set up, no subscriptions, and the payment is essentially the credential to be able to get the content. So there is no centralization. X402 can be extended as well, and you can implement it, and there are no restrictions as well. So some key milestones here are, it was introduced last year, May 2025. X402 is now part of the Linux Foundation under open governance, and it's backed by Coinbase, AWS, Google, Stripe, Anthropic, Cloudflare, and Circle, right? So many more organizations are supporting that. So from Amazon, we have also released AgentCorp payments under the Bedrock suite, where agents will be able to make payments, and we'll go into some of the details here. So let's talk about the buyer side here and what is involved, right? So we understood from the developers that they really want to be able to get these agents and the payment is essentially the credential to be able to get the content. So there is no centralization. It's X402 can be extended as well, and you can implement it, and there are no restrictions as well. So some key milestones here are, it was introduced last year, May 2025. X402 is now part of the Linux Foundation under open governance, and it's backed by Coinbase, AWS, Google, Stripe, Anthropic, Cloudflare, and Circle, right? So many more folks are supporting that, organizations in there. So from Amazon, we have also released AgentCorp payments under the Bedrock suite, where agents will be able to make payments, and we'll go into some of the details here. So let's talk about the buyer side here and what is involved, right? So we understood from the developers that they really want to be able to get these agents to have wallet support. They want to be able to have real-time settlement, have the budget and guardrails, which enterprises really want, and observability throughout the stack, where they would want to have the full stack trace of everything that's happening under the hood. So I'm excited to share with you that we've launched AgentCorp payments, and this is a service that allows AI agents to autonomously discover, authorize, and execute payments with a few lines of code. Now we've launched this in partnership with Coinbase and Stripe, where you can bring wallets from Coinbase and Stripe Preview to be able to do these operations, and we'll go into some of the details. But the core capabilities to start with are wallet support, where you can bring the wallets from Coinbase and Stripe. You're able to orchestrate the payments using payment connectors, and today we support X402 with many more protocols that are in the pipeline. The service is designed to be protocol agnostic, so as new protocols emerge, we are going to be adding support for those protocols as well. And the settlement is going to be instantaneous, instant essentially, and the payment limits can be set, which is the most important thing that we spoke about, where enterprises are looking to put some payment limits and guardrails on how these transactions can operate. So observability is built in, and essentially all of this operates with security as the layer that is operating the whole model. So with that, let's look at some of these details on how the payments limit can be set up. So you can create payment sessions where you can programmatically set the maximum amount of value that can be used for transactions, or you can also set expiry time in minutes. Think where you are able to set that the agent can actually spend maybe $5 in 30 days or 60 days, right? So that's the operation model that you can set with many more details that are available. I'm only going over a few features, but let's look at what happens on the buyer side. When the user is asking an agent to make a particular request for resources, right? So the agent completes the request by accessing tools, MPP servers, other resources as well. So at that point in time, if the agent is looking at, it finds that there is a response from one of the tool calls or requests with a 402, AgentCorp payments is going to handle the request to complete the transaction, and then let the AI agent know that essentially the settlement happened, and the AI agent will be able to respond back to the users. So in this process, when the wallets are, wallet support is imported, the secret keys that you use to import the wallets actually are stored in a secure token wallet that is secured by KMS, where that's there. So essentially the agent does not have access to the private keys. This is most important to note. And the next thing is that AgentCorp payments is also integrated through a gateway, which is also part of, which is another service that we have to MCP-fy your internal APIs. Through AgentCorp gateway, the AgentCorp payments can get access to discovery service in Coinbase, where there are 10,000 plus endpoints that are available to transact. And then, again, there is a per-session budget that we just discussed as well. So there is a decoupling of agent infrastructure and the payment infrastructure by design, where the agent can operate in its own loop, and whenever it sees the payment, the payment connectors, orchestration, payment limits, and integration with third-party wallets can happen, right? So it's important to decouple them because, again, skills can be poisoned. Inputs for the agents can also be poisoned by inputs as well, right? So where malicious actors could try to do that. So by decoupling and making this by design, agents can essentially have a secure path for these transactions. And payments do not touch the undeterministic path, but this is more on a deterministic layer as well. So why this is important is that, again, the code of the agents does not have to change. You can bring your own model frameworks, and then the payment itself can flow through in the payment layer itself. So, again, the controls, the policy spending controls can be outside of the payment stack itself. And, again, this is built to be protocol agnostic. So this is one of the console screens where it shows how you can import the payment connector, and it shows that you can select the Coinbase wallet and the Stripe Preview wallet from the console. And this is a demo in action where we are showing how a secure resource can be accessed. Now, in this case, the AI agent is essentially discovering that there is a secure resource. The AgentCorp payments is kicking in, and then it's completing the transaction by utilizing the wallet that is already integrated, and the transaction completes. Now, this is on the buyer side. Now, let's look at the seller side to understand what's happening, right? So, again, there is a lot of bot activity that's happening. We have released under the AWS Web Application Firewall a feature where we have bot detection in place. Today, we detect over 650 different types of bots, types of bots like Perplexity Bot, GPD Bot, Cloud Bot, again, Google Bots, right? So there are so many bots that are out there. So we're able to detect, also understand the intent of these bots. So why are these bots accessing the content? Are they accessing the content to train their models? Are they doing it because they have to respond back to an intent where they're responding for a rag search? So we're able to identify the intent. We're also able to verify the bots and identify them by a signature. So we are able to say, hey, this is a verified bot. So maybe you have built a relation with one of these organizations, and this verification will allow you to have different pricing for the organizations that are already verified. So we'll look at that in a second. So there's also a real-time traffic analysis that allows more to be customized. And I'm also happy to share with you today that we announced WAF AI traffic monetization. This is a service that allows you to monetize based on the content, based on how you can measure, verify, and monetize based on the AI traffic that is hitting your endpoints. Now, if you might be familiar with CloudFront, which is our content distribution network, you can add a web application firewall at that point, and essentially you can start monetizing right away. And based on a few clicks, you can do that, again, using infrastructure as code as well. Now, I also spoke about a gateway service that allows you to expose your AI endpoints that are internal and MCP-fy them. So the same web application firewalls can be used there. So your internal APIs can be MCP-fied, and then you can start monetizing as well. So what happens during monetization? The AI agent, AI bot essentially requests some content. The bot context understands what kinds of bots, is detecting it. It's able to detect the bot. It's able to categorize and understand the intent of the bot, as we discussed earlier, and verify and check what kind of bot is available. So then we are able to monetize using the X402, and the publishers get paid as well. So important to note is that, again, there is no SDK change, no changes at the origin. Publishers keep 100% of the revenue as well, and again, there are no transaction fees or subscription fees. So this supports X402, and we are adding support for more protocols as well. A few dimensions on how you can start monetizing. Think you have separate paths. So a slash blog, in this case, can be charging for a different rate than a slash research or maybe an API endpoint itself. And you know the identity of these bots. Again, if you make some kind of relationship with the bots, companies, organizations, maybe you make a relation with Anthropic, then you can essentially have different pricing for those bots versus different unverified bots. Right, so think of that option. And then you can also set different pricing for intent as well. If somebody is coming here, if a bot is accessing the content for, again, training, you can charge a different rate than what it's doing for a search as well. So again, these are different WAF rules. They can be in a combination of and or, or, or, and then you can access that. and we are adding support for more protocols as well. A few dimensions on how you can start monetizing. Think you have separate paths. So a slash blog, in this case, can be charging for a different rate than a slash research or maybe an API endpoint itself. And the identity of these bots. Again, if you make some kind of a relationship with the bots, companies, organizations, maybe you make a relation with Anthropic, then you can essentially have a different pricing for those bots versus different unverified bots. Right, so think of that option. And then you can also set different pricing for intent as well. If somebody is coming here, if a bot is axing the content for, again, training, you can charge a different grade than what it's doing for a search as well. So again, these are different WAF rules. They can be in a combination of and or, or, or, and then you can access that. So this is how the re-imagined flow would look like where you're allowing the AI agents or essentially verified bots and unverified bots to have different pricing and humans to have different pricing. Some cases you want to have humans to access the content freely. Some cases, again, the humans could be charged, where the bots could be charged differently as well. So this is how you can reimagine the price. So again, there are some dashboards that show the revenue numbers and how you're able to aggregate by different bots and figure out what kind of revenue model you want to operate. And it also shows what is the path that's being accessed by these bots. So again, what is currently everyone using Agent eCommerce for? They are using Agent eCommerce to run, again, LLM inference, getting compute, web scraping. They're creating research agents to be able to serve the requests, and agent to agent as well. We see MCPs also being monetized now. Again, this is the last 12 months of traffic from, again, what we are seeing on Coinbase agentic market, where you're seeing that a $50 million volume transaction happened over 170 million transactions. The average settlement time is 200 milliseconds on base with about a tenth of a cent as cost per transaction. So I spoke to you about Agent Core payments, which is one of the parts of the bigger ecosystem, Agent, Bedrock Agent Core, where you can essentially bring your own model, you can bring your own framework, and you can start building AI agents. You can add context by adding memory. You can bring, again, your own managed knowledge bases. You can add web search capabilities to the agents. You can MCPfy your internal APIs, and then you can have many more features, like being able to run evaluation on how your agents are performing. So again, you can use runtime, which is a Bedrock Agent Core runtime, where you can bring your own agent application and serve at scale, and every request will have its own isolated micro virtual machine that is running to serve the requests. So that's it from my side here today. Thank you, and I hope you have a nice day. Thank you. can be outside of the payment stack itself. And, again, this is built to be protocol agnostic. So this is one of the console screens where it shows how you can import the payment connector, and it shows that, you know, you can select the Coinbase wallet and the Stripe Preview wallet from the console. And this is a demo in action where we are showing how a secure resource can be accessed. Now, in this case, the AI agent is essentially making a, you know, discovering that there is a secure resource. The agent code payments is kicking in, and then it's completing the transaction by utilizing the wallet that is already integrated, and the transaction completes. Now, this is on the buyer side. Now, let's look at the seller side to understand what's happening, right? So, again, there is a lot of bot activity that's happening. We have released under the AWS Web Application Firewall a feature where we have bot detection in place. Today, we detect over 650 different types of bots, things of bots like Perplexity Bot, GPD Bot, Cloud Bot, you know, again, Google Bots, right? So there are so many bots that are out there. So we're able to detect, also understand the intent of these bots. So why are these bots accessing the content? Are they accessing the content to train their models? Are they doing it because they have to respond back to an intent where they're responding for a rag search? So we're able to identify the intent. We're also able to verify the bots and identify them by a signature. So we are able to say, hey, this is a verified bot. So maybe you have built a relation with one of these organizations, and these verification will allow you to have a different pricing for the organizations that are already verified. So we'll look at that in a second. So there's also a real-time traffic analysis that allows more to be customized. And I'm also happy to share with you today that we announced WAF AI traffic monetization. This is a service that allows you to monetize based on the content that, you know, based on how you can measure, verify, and monetize based on the AI traffic that is hitting your endpoints. Now, if you might be familiar with CloudFront, which is our content distribution network, you can add a web application firewall at that point, and essentially you can start monetizing right away. And based on a few clicks, you can do that, again, using infrastructure as code as well. Now, I also spoke about a gateway service that allows you to expose your AI endpoints that are internal and MCP-fy them. So the same web application firewalls can be used there. So your internal APIs can be MCP-fied, and then you can start monetizing as well. So what happens during monetization? The AI agent, AI bot essentially requests for some content. The bot context understands what kinds of bots is detecting it. It's able to detect the bot. It's able to categorize and understand the intent of the bot, as we discussed earlier, and verify and check what kind of bot is available. So then we are able to monetize using the X402, and the publishers get paid as well. So important to note is that, again, there is no SDK change, no changes at the origin. Publishers keep 100% of the revenue as well, and again, there is no transaction fees or subscription fees. So this supports X402, and we are adding support for more protocols as well. A few dimensions on how you can start monetizing. Think you have separate paths. So a slash blog, in this case, can be charging for a different rate than a slash research or maybe an API endpoint itself. And you know the identity of these bots. Again, if you make some kind of a relationship with the bots, companies, organizations, maybe you make a relation with Anthropic, then you can essentially have a different pricing for those bots versus different unverified bots. Right, so think of that option. And then you can also set different pricing for intent as well. If somebody is coming here, if a bot is axing the content for, again, training, you can charge a different grade than what it's doing for a search as well. So again, these are different WAF rules. They can be in a combination of and or, or, or, and then you can access that. So this is how the re-imagined flow would look like where you're allowing the AI agents or essentially verified bots and unverified bots to have different pricing and humans to have different pricing. Some cases you want to have humans to access the content freely. Some cases, again, the humans could be charged, where the bots could be charged differently as well. So this is how you can reimagine the price. So again, there is some dashboards that show the revenue numbers and how you're able to aggregate by different bots and figure out what kind of revenue model you want to operate. And it also shows what is the path that's being accessed by these bots. So again, what is currently everyone using Agent eCommerce for? They are using Agent eCommerce to run, again, LLM inference, getting compute, web scraping. They're creating research agents to be able to serve the requests, and agent to agent as well. We see MCPs also being monetized now. Again, this is the last 12 months of traffic from, again, what we are seeing on Coinbase agentic market, where you're seeing that a $50 million volume transaction happened over 170 million transactions. The average settlement time is 200 milliseconds on base with about a tenth of a cent as cost per transaction. So I spoke to you about Agent Core payments, which is one of the parts of the bigger ecosystem, Agent, Bedrock Agent Core, where you can essentially bring your own model, you can bring your own framework, and you can start building AI agents. You can add context by adding memory. You can bring, again, your own managed knowledge bases. You can add web search capabilities to the agents. You can MCPfy your internal APIs, and then you can have many more features, like being able to run evaluation on how your agents are performing. So again, you can use runtime, which is a Bedrock Agent Core runtime, where you can bring your own agent application and serve at scale, and every request will have its own isolated micro virtual machine that is running to serve the requests. So that's it from my side here today. Thank you, and I hope you have a nice day. Thank you.