AWS WAF added a feature called AI traffic monetization. It lets you charge AI bots that hit your site or API for access to your content. Until now, dealing with AI crawlers meant a binary choice, allow or block. This adds a third path: take payment and let them through.
I won't go deep into the feature itself here, how a content owner sets up monetization. The official announcement covers that.
What I want to look at is the other side. The story of the side defending content is, at the same time, the story of the side reading it, the side running autonomous agents. HTTP status code 402, reserved for years and rarely used, becoming practical means the cost structure of an agent reading the web is starting to change. For the payment protocol itself, I'll read it from the x402 spec.
The "let them read, recoup later" business model that AI broke
To set the stage: AI bot traffic is now too large to ignore. According to the AWS blog, for many content providers AI bots make up more than half of web traffic, and AI-specific crawlers have grown more than threefold year over year.
Traditional search crawlers built an index and sent readers back from the search results. AI bots, by contrast, use the same content to generate summaries and answers, and return almost no readers to the original site. The provider pays the infrastructure cost of serving the traffic while getting neither page views nor ad impressions. This asymmetry is where the idea of charging starts.
That is the view from the side defending content.
What Monetize returns with 402, and two constraints
First, the mechanics, just the essentials.
Monetization runs as part of AWS WAF's Bot Control. For a request judged to be a bot, you assign one of six actions (Monetize / Allow / Block / Count / CAPTCHA / Challenge); assign Monetize, and a request without payment receives an HTTP 402 Payment Required. Along with the 402 comes a manifest, written in a machine-parsable form, stating the price per request (in USDC), the accepted payment networks (Base and Solana), the destination address, and more. That format is x402, an open protocol Coinbase proposed for program-to-program payments.
Two constraints are worth noting. First, the Monetize action is only available on web ACLs associated with Amazon CloudFront. Second, payment verification and on-chain settlement happen synchronously, inside the request path. The official docs state this explicitly as "synchronously," and the content is returned only after settlement is confirmed. That latency falls only on requests that involve payment; requests without payment are unaffected.
https://docs.aws.amazon.com/waf/latest/developerguide/waf-ai-traffic-monetization-how-it-works.html
Reading x402's payment internals from the source
x402 was proposed by Coinbase and is now developed as an open standard, with the repository moved to the x402 Foundation. Both the spec and the implementation are public on GitHub, so you can read directly what the AWS docs alone don't show. The official docs take you as far as the overall flow; beyond that, only the spec has it. So let's read the source and trace, in order, what goes into the 402, how it is signed, and where it is sent.
https://github.com/x402-foundation/x402
The 402 body is a manifest of payment terms
When a 402 Payment Required comes back, in x402 v2 the payment terms ride in the PAYMENT-REQUIRED header, Base64-encoded. Decode it and you get the object the spec calls PaymentRequired. It holds an array of payment methods the provider accepts (accepts), and each element declares which scheme, on which network, which currency, how much, and to which destination you pay to get through.
Here is what one looks like. This is a single element of the accepts array, taken from the v2 spec's example.
{
"scheme": "exact",
"network": "eip155:84532",
"amount": "10000",
"asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
"payTo": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
"maxTimeoutSeconds": 60,
"extra": { "name": "USDC", "version": "2" }
}
The fields mean:
- scheme (the payment method, e.g. exact)
- network (a chain ID such as eip155:84532)
- amount (the amount, as an integer in the smallest unit; the 10000 here is 0.01 USD in USDC)
- asset (the currency's contract address)
- payTo (the receiving address)
- maxTimeoutSeconds (the payment's expiry)
The paying side picks one set of terms it can pay from this array and builds the payment. Multiple networks or currencies may be listed, and which to choose is left to the payer.
The payment is a signed authorization, not the transfer itself
What the payer creates is a PaymentPayload object, made of a signature and an authorization. The authorization holds: from whom (from), to whom (to), how much (value), the validity window (validAfter / validBefore), and a single-use value to prevent reuse (nonce).
{
"signature": "0x2d6a7588...148b571c",
"authorization": {
"from": "0x857b06519E91e3A54538791bDbb0E22373e36b66",
"to": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
"value": "10000",
"validAfter": "1740672089",
"validBefore": "1740672154",
"nonce": "0xf3746613...62f13480"
}
}
The values are all from the v2 spec's example. In response to the earlier accepts (the payment request), the payer signs and returns this. It is not the execution of a transfer; it is a signed permission to pull this amount under these terms. It uses EIP-3009's transferWithAuthorization, and the fact that the amount, the expiry, and the single-use nonce are bound by the signature is what matters for the budgeting design later.
https://eips.ethereum.org/EIPS/eip-3009
The header names changed between v1 and v2
x402 has a v1 and a v2, and how the payment-exchange headers work changed in v2. It is a difference worth knowing if you touch the implementation.
| Purpose | v1 | v2 |
|---|---|---|
| 402 payment request | response body | PAYMENT-REQUIRED |
| client's payment | X-PAYMENT | PAYMENT-SIGNATURE |
| settlement result | X-PAYMENT-RESPONSE | PAYMENT-RESPONSE |
In v1, only the payment request came back in the response body, while the payment and the result were headers. v2 organizes all three into headers, and the spec states that x402 carries all of its protocol information in headers, leaving the response body to the server implementation. The reason AWS's docs mention a payment-signature header is that it follows v2.
The facilitator handles verification and settlement but holds no funds
So that the provider does not have to implement on-chain verification and transfer itself, an intermediary service called a facilitator exists. It has two roles: verify (check that the signed payment meets the terms) and settle (send it to the blockchain and wait for confirmation). What the spec states explicitly is that the facilitator holds no funds, that is, it is not a custodian. It only receives the signed authorization and carries out verification and execution on the provider's behalf. Facilitators are already running in production on several networks including Solana, Polygon, and Base.
https://www.x402.org/ecosystem
Tracing the flow briefly from the payer's side:
- Send the request
- A 402 with PAYMENT-REQUIRED comes back
- Pick one set of terms from accepts
- Resend with the signed authorization in PAYMENT-SIGNATURE
- The provider verifies via the facilitator's verify, fetches the content, confirms with settle, and returns it with PAYMENT-RESPONSE
What AWS WAF handles is the provider side of this flow.
For that settle, AWS WAF uses the x402 facilitator provided by Coinbase Developer Platform. Note that if the origin returns 4xx or 5xx, no settlement runs and the payer is not charged.
The agent runtime becomes a payment actor
A 402 coming back presupposes an agent that receives it, pays, and goes back for the content.
The flow just traced can be run almost autonomously by the paying side's agent runtime. The runtime handles receiving the 402 and resending with the signed authorization in PAYMENT-SIGNATURE, and the provider-side verification through settlement completes synchronously, inside the request path.
This is a new design concern for whoever runs the agent. Until now, the cost of an autonomous agent fetching the web was mostly just its own token usage and bandwidth. From here on, if the fetched destination is monetized, the content itself may carry a cost. The agent's runtime becomes a payment actor at the same time as being an HTTP client. That is the structural change.
If you run your own agent, this change brings in two new design decisions: whether to treat a 402 from a fetch destination as a failure or pay and get through, and if paying, with which wallet and up to how much automatically. The same kind of decision that choosing an auth path became now arises for the payment path.
You might feel, "I am not crawling at scale, so this does not concern me." But this is a matter of premise, not scale. The moment even one destination returns a 402, the agent's design grows a branch for how to handle 402. As more providers monetize, a 402 mixing into the reasons a fetch fails becomes unavoidable. Better to hold the assumption ahead of time than to scramble later over whether to give up, pay, or route around.
Three things the payer's harness needs to decide
Once you understand the spec, the payer's design points get concrete. There are roughly three.
First, where to put the branch after receiving a 402. When the agent's HTTP client receives a 402, does it return it as a failure up the stack, or enter the payment path on the spot? If you pay automatically right inside the fetch, the agent does not have to be aware of the 402, but where and how much you paid becomes hard to see. Conversely, if you bring it up to the planning layer where the agent decides its next action, you can make the payment decision in the context of the task, but the branches scatter across the call paths. The same decision as which layer attaches the auth token now stands up for payments too.
Second, how to cap the budget. This is where x402's signature design pays off. The authorization contains value (the amount), validBefore (the expiry), and nonce (single-use), fixed by the signature. So for each payment, you can decide the cap and the expiry at the moment of signing. Give the harness rules like "up to this much per request," "up to this cumulative amount per task," and "invalid past this time," then fold them into generating the authorization, and you prevent a runaway agent from paying without limit, by design. Being able to embed the cap in the signed authorization itself, rather than hard-coding it somewhere, is the strength of this design.
Third, verification before going to production. You cannot run real currency through payment-involved code from the start. x402 has test networks (the eip155:84532 from the earlier example is a testnet called Base Sepolia), and you can run the whole flow, a 402 returning, an authorization being created, and verification happening, without moving real assets. Whether you run through this once, as a stage before putting the payment feature into your implementation, changes how calm the first production rollout feels.
At the design stage, you consider these three: which layer receives the 402, whose wallet and how much to cap, and whether to run it through a testnet. No implementation yet. Just recognizing the premise has changed, and deciding where the judgment lives, means you will not scramble as more destinations to pay appear.
The gap robots.txt couldn't close
One more thing worth seeing from the payer's side is the relationship to robots.txt. robots.txt is only a gentleman's agreement; it had no force to stop crawlers that do not comply. There was no middle ground between allow and block, and blocking shuts out even the welcome bots that bring readers in via AI search. A 402, a mechanism that does have force, is moving to fill this gap.
Put from the payer's side: part of the web where "if you went to read it, you could read it" may turn into a web where "if you go to read it, you are asked for payment." According to the AWS blog, AWS WAF classifies over 650 types of AI bots and agents, splitting them into verified, confirmable by cryptographic signature or published IP range, and unverified. The provider can serve them differently, letting verified search crawlers through for free while setting a high unit price for unverified ones. In other words, if your own agent is classified as unverified, it may end up on the side asked for a relatively high price.
Where stablecoin settlement stands today
Next, the payment method. It is a fact that payment today is centered on stablecoins like USDC. The receiving side specifies a wallet address on a network such as Base or Solana, and AWS neither intermediates the payment nor takes a fee. Converting the received stablecoins into fiat and moving them to a bank account is, officially, something you manage yourself or leave to your wallet provider. What AWS WAF handles is up to receiving the payment; the conversion and bookkeeping beyond that are on you. It is not yet at a stage where it drops straight into an existing accounting flow.
Still, what matters for practice in the near term is a different point: before going to production, you can try the payment flow in test mode without running real currency. As a stage before putting a payment-involved feature into your implementation, this is a welcome design.
The industry's move toward monetization
A similar mechanism, Cloudflare's Pay Per Crawl, came first. With AWS following, a view emerges that payment mechanisms are splitting per cloud, with each vendor using them for its own lock-in.
https://developers.cloudflare.com/ai-crawl-control/features/pay-per-crawl/what-is-pay-per-crawl/
But the fact that two companies moved in the same direction, toward program-to-program payment using 402, looks less like each vendor's individual play and more like a sign the industry is starting to lean toward web reading becoming monetizable. x402 as a protocol is not closed to any one cloud. If so, the question moves from "which cloud to use" to "which agent runtime supports this payment flow first." Seen as an AWS WAF feature it is one company's story, but stand on the side that has agents read the web and pay, and it looks like part of a wider industry shift.
Reading the source further, you find x402's scope is wider than web reading. x402's transports are defined not only for HTTP but also for MCP (Model Context Protocol) and A2A (Agent-to-Agent Protocol). In the MCP transport, when an agent calls a paid tool, the result comes back as an error first, and resending with payment executes it. In the A2A transport, one agent pays for another agent's service. In the spec's words, agents monetize their own services through on-chain cryptocurrency payments.
So AWS WAF's AI charging is just x402 implemented on one face: reading content over HTTP. Beneath it spreads the idea of a payment layer where, whether agents are calling tools or trading with each other, they pay with the same 402 and the same signature. The reason 402 was brought back is less to monetize the web and more to give agents a common payment endpoint for acting as economic actors, and reading it that way fits better.
Where to start
If you hold content, the first step is not setting up charging but looking, in the AI traffic analytics dashboard, at the proportion of AI bots coming to your site. If you have a site served via CloudFront, make the current state visible first and gather the material to judge which of block, charge, or allow fits. You do not need to enable Monetize right away.
If you run agents, you will want to check whether, among the destinations your agent currently fetches, there is content likely to start returning 402. Then leave even a single line in your harness's design notes on the policy: whether to pay automatically or not, and if paying, where to set the cap. No implementation yet. Just recognizing that the premise has changed will change your later decisions.
402, a status code that lay dormant for a long time, has risen as the payment layer of the agent economy. You can read it as a story about defending content, but the same event is, for the side that has agents read the web, also a story of one more cost premise added. Which side you stand on changes the view, but being at the entrance where reading the web may no longer be free looks the same from either side.