Monetizing AI Agents at the Edge with Akamai Functions

• The problem: AI agents are wrongfully consuming digital resources
• Why this is an edge problem, not an origin problem
• Why Akamai is different
• Why “serverless at the edge” is the right economic model, not just a technical choice
• Why performance still matters
• The technical deep dive Property Manager (plus Bot & Agent Control) Akamai Functions (Spin/Wasm app) The x402 facilitator The origin
• Property Manager (plus Bot & Agent Control)
• Akamai Functions (Spin/Wasm app)
• The x402 facilitator
• The origin
• The request flow, step by step
• Building the solution: Key details Detection stays entirely in Property Manager The 402 response is a real, spec-shaped x402 payload — not a placeholder Verify and settle are two separate facilitator calls Settlement gas is the facilitator's problem A lightweight KV cache Outbound egress is allowlisted, not open
• Detection stays entirely in Property Manager
• The 402 response is a real, spec-shaped x402 payload — not a placeholder
• Verify and settle are two separate facilitator calls
• Settlement gas is the facilitator's problem
• A lightweight KV cache
• Outbound egress is allowlisted, not open
• What this demo proves
• Adoption reality check: Is anyone actually paying?
• What's next

Key takeaways

Content-scraping bots and autonomous AI agents consume digital resources without generating traditional revenue (ads, subscriptions) or using human-friendly payment flows; the x402 protocol enables programmatic, per-request micropayments using stablecoins without human interaction.

Because we operate as a reverse proxy, the entire monetization handshake — detection, payment negotiation, and settlement — happens at the edge using Akamai Functions and Akamai Bot & Agent Control, leaving the customer’s back-end infrastructure completely untouched.

Built as a Spin/WebAssembly (Wasm) component at the edge, the solution ensures near-zero idle infrastructure costs (costs directly match agent revenue) while keeping round-trip handshakes fast enough to prevent agents from timing out.

While x402 has processed more than 75 million transactions (primarily agent-to-agent and agent-to-compute spend like GPU inference and APIs), publisher-facing paywalls represent the next frontier as content crawlers evolve to carry wallets.

This blog post presents a step-by-step walkthrough of building an x402 micropayment gateway for AI-agent traffic entirely on Akamai Functions — and takes an honest look at who can actually use it today.

The problem: AI agents are wrongfully consuming digital resources

For 20 years, the web’s implicit contract was simple: Content and API owners give something away (a page, a data feed, a compute cycle); ads, subscriptions, or direct billing pay the bills; and automated clients (mostly search engines) play by the unwritten rules.

Two types of AI agents are breaking that contract, each in a distinct way:

• Content-scraping bots, such as GPTBot, ClaudeBot, PerplexityBot, and CCBot , fetch and repackage publisher content without clicking ads, converting to subscribers, or sending human traffic back to the original publisher.

Content-scraping bots, such as GPTBot, ClaudeBot, PerplexityBot, and CCBot , fetch and repackage publisher content without clicking ads, converting to subscribers, or sending human traffic back to the original publisher.

• Task-executing agents now autonomously call paid APIs, data feeds, and compute services on behalf of a human or another agent, entirely without a human in the loop, to click “buy” or enter a credit card.

Task-executing agents now autonomously call paid APIs, data feeds, and compute services on behalf of a human or another agent, entirely without a human in the loop, to click “buy” or enter a credit card.

Both types of bot activity create the same underlying problem: The resource owner needs a programmatic, per-request way to charge an automated client so they either eat the cost, block the traffic, or force it through slow, human-shaped payment flows (API keys, prepaid credits, manual invoicing) that don’t fit how agents actually operate.

Blocking outright is a defensive, not a strategic, move — for content, it just pushes you out of whatever AI-mediated discovery layer comes next; for APIs and data, it forecloses an entire emerging buyer category. The better move is the one that markets have always made when a new class of consumer showed up: Charge for access, in a form that the consumer class can actually transact in. For agents, that means no signup forms, no credit cards, no human-in-the-loop approval — just a request, a price, a signature, and a retry.

That’s exactly what the x402 protocol is for. It’s an open standard that repurposes the long-dormant HTTP 402 Payment Required status code into a machine-readable handshake for stablecoin micropayments.

In this blog post, I’ll examine the x402 protocol using a publisher content paywall as an example because it’s the easiest to visualize end to end .

Why this is an edge problem, not an origin problem

Here’s the strategic insight this demo was built around: Akamai customers shouldn’t have to touch their origin infrastructure to monetize agent traffic.

Most origins are legacy content management systems (CMSs), hand-rolled back ends, or third-party platforms nobody wants to modify. It is a nonstarter for most teams to do any of the following just to charge automated clients:

• Integrate a crypto wallet SDK

Integrate a crypto wallet SDK

• Add payment-verification middleware

Add payment-verification middleware

• Maintain PCI-adjacent security posture

Maintain PCI-adjacent security posture

It’s the same reason CDNs win by living in front of origins instead of requiring origin rewrites.

Why Akamai is different

We already sit in front of the traffic as the reverse proxy of record. That position is the leverage point.

Figure 1 illustrates the pitch in one diagram: The origin never sees agent traffic that hasn’t paid, and never had to change a single line of code to make that true. All the new logic — detection, payment negotiation, settlement — lives at the edge, as a discrete, addable layer. The origin behind it could just as easily be a paid weather API, a market-data feed, or an MCP tool server as a news site.

Why “serverless at the edge” is the right economic model, not just a technical choice

There’s a second strategic decision baked into this architecture: running the paywall as a Spin/Wasm on Akamai Functions instead of a traditional always-on origin service.

This matters commercially, not just technically.

• The pay-as-you-go cost shape matches pay-as-you-go revenue. The gateway only executes — and only costs anything — when an agent actually shows up. A customer with low agent traffic today pays almost nothing; one who suddenly gets hit hard by a new agent doesn’t need to provision for it. The cost curve tracks the monetization curve.

The pay-as-you-go cost shape matches pay-as-you-go revenue. The gateway only executes — and only costs anything — when an agent actually shows up. A customer with low agent traffic today pays almost nothing; one who suddenly gets hit hard by a new agent doesn’t need to provision for it. The cost curve tracks the monetization curve.

• There is no capacity planning, no idle infrastructure. There’s no origin-side fleet to size for a traffic pattern (agent bursts) that is inherently bursty and unpredictable.

There is no capacity planning, no idle infrastructure. There’s no origin-side fleet to size for a traffic pattern (agent bursts) that is inherently bursty and unpredictable.

• Cold start latency is solved by running in Wasm at the edge, not by overprovisioning an origin container fleet in one region.

Cold start latency is solved by running in Wasm at the edge, not by overprovisioning an origin container fleet in one region.

• It’s additive, not invasive. A customer can turn this on for one property, one path pattern, or one bot category — and turn it back off — via Property Manager rule changes, with zero deploys to their own stack.

It’s additive, not invasive. A customer can turn this on for one property, one path pattern, or one bot category — and turn it back off — via Property Manager rule changes, with zero deploys to their own stack.

In short: This isn’t just “a bot paywall.” It’s a template for an Akamai customer to build edge native monetization middleware that allows Akamai to turn detection signal (Bot & Agent Control) and edge compute (Akamai Functions) into a direct new revenue line for customers, with the CDN doing the commercial enablement work the origin never had to.

Why performance still matters

Even though the audience is bots, latency isn’t free to ignore . Agents run on budgets and timeouts, too, and a slow gateway will just get skipped or blocklisted by the agent operator, killing the monetization opportunity. Running the handshake as a compiled Wasm component at Akamai’s edge, geographically close to wherever the agent’s request originated, keeps the 402 → verify → settle → 200 round trip fast enough that it doesn’t become the agent’s next reason to stop calling you.

The technical deep dive

When exposing web services to AI agents and automated crawlers, enforcing monetization without disturbing legacy user traffic requires a modular, Zero Trust boundary. This architecture achieves seamless payment verification through four decoupled components, each handling a single responsibility along the request pipeline:

• Property Manager handles precise traffic discrimination.

Property Manager handles precise traffic discrimination.

• Akamai Functions executes edge-side paywall logic via Wasm.

Akamai Functions executes edge-side paywall logic via Wasm.

• The x402 facilitator isolates the cryptographic and blockchain transaction settlement.

The x402 facilitator isolates the cryptographic and blockchain transaction settlement.

• The origin remains entirely untouched while serving verified requests.

The origin remains entirely untouched while serving verified requests.

Four moving pieces, each with a distinct, narrow job (Figure 2).

Property Manager (plus Bot & Agent Control)

Classifies traffic: Only the requests it tags as AI-agent traffic get rerouted at all. Everything else — humans, search crawlers — hits the real origin exactly as before.

Akamai Functions (Spin/Wasm app)

The paywall itself: It issues 402s, talks to the facilitator, proxies paid requests to origin. Stateless except for a short-lived KV cache.

The x402 facilitator

A third-party (or self-hosted) service that verifies signed payment payloads and submits the actual on-chain settlement transaction — the gateway app never touches private keys or gas.

The origin

Completely unmodified: Akamai Functions sends the header to origin to confirm payment has been successful.

The request flow, step by step

The elegance of x402 is that this entire negotiation — price discovery, signing, verification, settlement — happens in that single retried HTTP request. There's no OAuth-style redirect dance, no account creation, no API key provisioning. The agent's wallet is its identity and its payment method (Figure 3).

When the payment is not received, the agent sees:

When the payment is successful, the agent sees:

Building the solution: Key details

Building a functional, edge-based micro-monetization pipeline requires a strict separation of concerns and an exact alignment with x402 specifications. The following implementation notes cover the core mechanics of how the solution operates in production — and the key details that make or break it.

Detection stays entirely in Property Manager

The Functions app trusts a single signal — the `X-Detected-Agent` header — set upstream once Bot & Agent Control (or a User-Agent match list, as a fallback for accounts without it) classifies the request.

This is deliberate: Detection logic and monetization logic are separate concerns, and keeping them separate means the customer can evolve their bot-detection strategy without ever redeploying the gateway app.

The 402 response is a real, spec-shaped x402 payload — not a placeholder

Two details are worth calling out because they're easy to get wrong (and did, while building this):

• `resource` must be a fully-qualified URL, not a path — the client-side x402 library validates it as a URL and rejects a bare path.

`resource` must be a fully-qualified URL, not a path — the client-side x402 library validates it as a URL and rejects a bare path.

• `extra.name` / `extra.version` describe the EIP-712 signing domain for the token contract. Without it, the facilitator can't validate the signature and rejects with `invalid_exact_evm_missing_eip712_domain`.

`extra.name` / `extra.version` describe the EIP-712 signing domain for the token contract. Without it, the facilitator can't validate the signature and rejects with `invalid_exact_evm_missing_eip712_domain`.

Verify and settle are two separate facilitator calls

And both expect a single payment-requirement object — not the `{ accepts: [...] }` array wrapper the client received. Sending the wrapper produces a deceptively generic error: `“No facilitator registered for scheme: undefined and network: undefined”`, because the facilitator is reading `scheme`/`network` off an object that doesn't have them at the top level.

Settlement gas is the facilitator's problem

For the `exact` Ethereum Virtual Machine (EVM) scheme, the agent only signs an off-chain EIP-3009 `transferWithAuthorization` message; the facilitator is the one submitting the on-chain transaction and paying gas. That's a meaningful detail for the pay-as-you-go story: agents need a small USDC balance to pay with, but no ETH is required for the happy path.

A lightweight KV cache

A single page load can trigger dozens of subresource requests; charging per-request would be both hostile and slow. The app keys a short-lived “already paid” flag in Spin's KV store by client fingerprint plus resource path, so one payment covers a full page session.

Outbound egress is allowlisted, not open

`spin.toml`’s `allowed_outbound_hosts` restricts the component to exactly two hosts: the facilitator and the real origin. This isn't optional hardening — Spin blocks all other outbound hosts by default, which is a nice forcing function for least-privilege network design.

What this demo proves

Akamai customers can go from zero monetization of agent traffic to a working, on-chain settlement payment gateway by adding one Property Manager rule and deploying one small edge function — with zero or minimal commits to their origin codebase.

The entire payment negotiation completes within a single HTTP request/retry cycle, at edge latency, in a serverless runtime.

Check out the demo code repository. This demo intentionally keeps a few things loose that a production rollout would tighten up: replay protection on the `X-PAYMENT` header (a nonce plus KV check), a real pricing/session model instead of literal pay-per-hit. None of those are architectural changes — they're hardening on top of a pattern that already works end to end, on Akamai's edge, today.

Adoption reality check: Is anyone actually paying?

This is worth answering honestly rather than assuming, because it changes who should build this now.

x402 itself has real, if early, traction — its public dashboard reports approximately 75 million transactions, ~US$24M in volume, ~94,000 unique buyers, and ~22,000 sellers over a recent 30-day window (self-reported by x402.org, therefore directional, not independently audited). The protocol also has real institutional backing: Coinbase, Circle, AWS, Anthropic, and Vercel are named collaborators, and a Linux Foundation–backed x402 Foundation now governs the spec — which signals a genuine standardization, not a single vendor’s side project.

But look closely at what’s being purchased, and a pattern emerges: The documented adoption is overwhelmingly agent-to-infrastructure spend — agents paying for GPU inference (Hyperbolic), compute provisioning (OpenMind), real-time market/social data (Zyte, Neynar, Boosty Labs), and MCP tool calls (Anthropic’s own protocol). These are cases in which an agent is completing a task for a paying human or business and needs to acquire a resource to do it — it’s an easy, already-budgeted purchase.

What's next

General-purpose content-scraping bots (GPTBot, ClaudeBot, PerplexityBot, CCBot) that autonomously pay a publisher’s 402 challenge in the wild may be next. Today’s crawlers aren’t wallet-equipped or configured to autopay — they’re built to crawl freely or be blocked. However, a 2026 article suggests that Google has already started a pilot program with selected publishers to pay for their content.

About the Author(s)

Deepak Jha

Deepak Jha is a Lead Enterprise Architect at Akamai, helping enterprises across APJ design internet architectures that stay fast, secure, and resilient at scale. For more than 20 years, he has led programs spanning edge computing, performance engineering, DevSecOps, and AI adoption, and has run resilience and security assessments that hardened web and mobile applications against modern threats. He believes security and performance work best when built into the architecture from day one. Deepak holds a B.Tech. in Mechanical and Automation Engineering and certifications including TOGAF, CISSP, and CKA.

Tags