● Agentic Commerce on Cloudflare
Agentic Commerce / Merchants / WebMCP

For Cloudflare merchants · In progress

Let real AI agents call your tools —
without exposing your API to everyone.

AI agents call MCP tool surfaces to search your catalogue, fetch a product, complete a checkout. The moment that surface is reachable from the public internet, every script on the web can call it too. Your job as a merchant is to separate the real agents from the spoofers, decide which tools each one is allowed to call, and keep a switch you can flip if anything goes wrong. Three phases. This page walks through all three.

The protocol — Web Bot Auth — is an IETF draft authored by Cloudflare. The pieces we ship for the merchant side (webmcp-auth and friends) are open source and deployable today. The story is still maturing as more agent vendors adopt signed requests; expect the playbook to grow.

See the three phases ↓ Open the playbook →

webmcp-auth covers

  • Verifying agent signatures on every request
  • Both spec-mandated signing algorithms (Ed25519 and RSA-PSS-SHA512) plus a compatibility option
  • Identifying agents by their published key
  • Replay protection — same request can't be used twice
  • Per-agent rate limits (keyed on the verified identity)
  • Per-agent, per-tool allow / deny rules
  • Body-integrity check on every tool call
  • BLOCK_ALL off switch

You arrange separately

  • Your existing MCP server (we don't replace it)
  • Which agent directories you choose to trust
  • Bot Management rules in your Cloudflare dashboard
  • Whatever your tools actually do once verified

Experimental release. Published as @mconroy-cf/webmcp-auth-workers while we gather partner feedback. Expect breaking changes; not for production traffic. Send feedback to mconroy@cloudflare.com.

worker.ts The whole merchant integration 
import { Authenticator } from "@mconroy-cf/webmcp-auth-workers";

const auth = new Authenticator({
  defaultPolicy: { allowTools: ["search", "get_product"] },
  agents: [
    { agentId: "openai-chatgpt", allowTools: "*" },
    { agentId: "noisy-startup",  denyTools: ["checkout"] },
  ],
  verify: { nonceStore: env.NONCE_STORE },
  blockAll: env.BLOCK_AGENTS === "true",
});

export default {
  async fetch(request, env) {
    const decision = await auth.authorize(request);
    if (!decision.ok) return decision.toResponse();

    // Verified. Forward to your real MCP origin.
    return fetch(env.MCP_ORIGIN_URL, {
      method: request.method,
      headers: { ...Object.fromEntries(decision.forwardHeaders()) },
      body: decision.rawBody,
    });
  },
};
That's the whole integration. Per-tool rules, body-integrity check, rate limiting, and the kill switch are all in those few lines — full template →

Scope · What this proves, what it doesn't

One identity layer, not two.

webmcp-auth proves which agent is calling. It does not, on its own, prove which user the agent is acting for. That distinction matters more for some tools than others — worth landing before you read the rest of the page.

Read-only tools

Search, get_product, list_products, check_inventory. These don't depend on who the user is. Verifying the agent ("this is OpenAI's verified shopping agent, not a copycat scraper") is the whole story. webmcp-auth covers this end-to-end.

Tools that act on behalf of a user

Cart, account, checkout, anything mutating user state. These need a second identity layer — proof that the agent is acting for a specific authenticated person, not just calling on behalf of nobody in particular. webmcp-auth doesn't provide that today. You bring your own user-auth on top.

How merchants handle user-auth today

Whatever you already use for API auth: an OAuth bearer the agent obtained on the user's behalf, a session cookie that flowed through from the user's browser, a signed JWT, your own session-token format. The library's KYA hook lets you verify these and surface the human-behind-agent identity to your origin if you want; the verification itself is bring-your-own.

Where we're heading

Credential delegation — the agent authenticates to your MCP server as the user, without the user's credentials leaving their browser — is under consideration. We don't have a shipped design yet; the right shape depends on partner deployment patterns we haven't seen. If your tool surface needs this, tell us what you'd want; that's how we decide what to build.

Getting Started at a Glance

Three phases, in order. You can start with any one and adopt the others later — but the natural sequence is expose → govern → observe: get the surface up, lock it down, then measure.

1 · Expose

Make your tools usable by browser-side AI agents (Gemini in Chrome today, others as the WebMCP browser API spreads) without modifying your frontend. A Cloudflare Zone Rule injects a bridge script and provisions a per-session Agent Durable Object.

See Phase 1 →

2 · Govern

Verify every signed agent calling /mcp, decide which tools they're allowed to call, rate-limit per identity, and keep a kill switch you can flip from your dashboard.

See Phase 2 →

3 · Observe

Get a 24-hour answer to "which agents are hitting my site, what proof of identity do they carry, and what are they trying to do?" — without standing up your own observability stack.

See Phase 3 →

Want the full walkthrough? What this proves (scope), edge prereqs (prereqs), install (install), verify your install (verify), what arrives at your origin (process), how to run it in production (operate), a realistic one-week rollout (rollout), build it yourself comparison (build vs. install), and a merchant FAQ (FAQ).

All three pieces are real Cloudflare Workers you can deploy today. Most merchants start with Phase 2 (webmcp-auth) — they tend to arrive with /mcp already public and a question about who's hitting it. See the day-by-day plan →

Today, an agent and a script look the same.

Both arrive as HTTP requests with a User-Agent string you can't trust and an IP that tells you nothing. As Cloudflare's announcement of Web Bot Auth put it: User-Agent headers are trivially spoofable, published IP ranges are brittle, and shared API-key bearer tokens don't scale beyond a handful of partnerships. Cryptographic signatures are how this gets fixed.

Today (no Web Bot Auth)

Tool call. Who is it?

? User-Agent: ChatGPT/1.0 Trivially spoofed. Means nothing.
? Datacentre IP, no published range Could be the real OpenAI, could be a copycat scraper.
✕ No way to enforce per-tool policy Every caller sees every tool you expose.
✕ No way to turn agents off without a redeploy If something goes wrong, your only knob is taking /mcp offline.
With webmcp-auth

Tool call. Verified in milliseconds.

✓ Signature-Input: …keyid="…thumbprint…" RFC 9421 signature. Not spoofable.
✓ You decide which agent directories to trust Out of the box, the verifier trusts the directory each agent advertises in its request. Pin to a fixed list when you want tighter control.
✓ Decide per agent, per tool "OpenAI's verified agent can call any tool; this scrappy startup can't call checkout." The verifier also checks the request body wasn't tampered with in transit.
✓ BLOCK_ALL kill switch One environment variable. Returns 403 to every agent without redeploying tool logic.

Phase 1 · Expose

Make your tools visible to browser AIs.

webmcp-interceptor is a Cloudflare Worker that runs as a Zone Rule. You enable it once for your domain in the Cloudflare dashboard and it makes your existing MCP tools usable by browser-side AI agents (Gemini in Chrome today, others as the WebMCP browser API spreads) — without you changing a single line of your frontend.

  • 1. One toggle in the dashboard

    The Worker passes every request through to your origin unchanged. When the response is HTML, it inserts a small bridge script into the page's <head>. Your server doesn't see anything different.

  • 2. Tools register themselves

    On each page load the bridge script asks your /mcp endpoint what tools you currently offer, and registers each one with the browser's AI tool API (navigator.modelContext). If you add a tool tomorrow, agents see it on the next page load — no extra config.

  • 3. One-shot orchestration

    When the browser AI wants to do something that needs several tool calls (e.g. "apply this discount code and check out"), the system writes a single short program that does the whole thing in one round trip. Faster, cheaper, and the cost stays flat no matter how many tools you offer.

  • 4. What about authentication?

    Browser AIs run inside the user's already-logged-in browser session. They don't sign requests with Web Bot Auth — the user's existing session is the authentication context. The Agent Durable Object enforces per-session rate limits and validates every message it receives. For server-side agents that hit your /mcp endpoint directly (without a browser), see Phase 2 below.

Owned by Cloudflare ETI / Chambers. Source: gitlab.cfdata.org/cloudflare/eti/chambers/webmcp-interceptor.

Phase 2 · Govern

Decide who calls your tools, and what they can call.

webmcp-auth is a Cloudflare Worker that sits in front of your /mcp endpoint and asks four questions on every request: is the agent who it claims to be, is it allowed to call this tool, was the body tampered with on the way in, and has it called too many times in the last minute. Plus a BLOCK_ALL flag — the off switch when you need it.

  • 1. Cryptographic identity

    Every request must carry a Web Bot Auth signature (the IETF standard for HTTP message signing). The verifier checks the signature against the agent's published public key. No signature, or a signature we can't verify, gets a 401. By default the verifier accepts the directory each agent advertises in its request; pin to a fixed list of trusted directories when you want stricter control.

  • 2. Per-agent, per-tool rules

    Configure something like "OpenAI's ChatGPT can call any tool; this scrappy startup can't call checkout". The library also makes sure the request body wasn't tampered with in transit, so an attacker can't swap the body to call a different tool than the one the agent signed for. If you set up the rules incorrectly the library refuses to start, rather than silently leaving you exposed.

  • 3. Per-agent rate limits

    Limits are keyed on the verified agent identity — not on IP address, not on User-Agent string. An attacker bouncing across IP addresses still hits the same quota.

  • 4. The off switch

    Flip a single environment variable (BLOCK_ALL=true) and every agent request gets a 403. No redeploy of your tool logic. Set it back to false to re-open the door. This is the direct answer to "can we turn this off again if we change our mind?".

Source: gitlab.cfdata.org/mconroy/webmcp-auth. Open source, MIT licensed.

Phase 3 · Observe

See what agents are actually doing.

@cloudflare/tapkit-traffic-logger is a single Cloudflare Worker that sits in front of your origin, sorts every request by how much proof of identity it carries, and gives you a rolling 24-hour dashboard. Pennies per merchant per day; no infrastructure of your own to run.

  • 1. Three trust tiers

    Verified — the request carried a valid cryptographic signature (Web Bot Auth) or a Cloudflare-issued agent token. The agent's identity was proven at the edge.
    Claimed only — the caller said who it was (matching a published agent list, or attaching a signature header) but we couldn't fully verify the claim.
    Unverified — User-Agent string only. The long-tail of bot traffic.

  • 2. The four answers merchants ask for

    What's the breakdown of trust tiers in my last 24 hours? Which named agents (OpenAI, Perplexity, etc.) showed up? What did they try to do — read my catalogue, view a product, attempt a checkout? And how much of my traffic carries each kind of identity signal? All served from one dashboard URL.

  • 3. Pairs naturally with Phase 2

    Run webmcp-auth in front of the logger and signed agent traffic shows up in the Verified tier instead of Claimed only — because Phase 2 actually checks the signatures, not just notes that they were present.

  • 4. A note on the package name

    The package is currently published as @cloudflare/tapkit-traffic-logger because it grew up inside the TAPKit repo. The classifier isn't payments-specific — it works equally for Web Bot Auth, agent allow-lists, KYA tokens, and User-Agent traffic. The name may get tidied; the package and install path won't change.

Prereqs · Edge readiness

Get your Cloudflare edge ready.

Unlike TAP (which needs Visa Intelligent Commerce enrolment in parallel), webmcp-auth doesn't have a longest-lead-time external dependency. Four short checks, none of them WebMCP-specific. If you're already on Cloudflare, most of this is "confirm and move on".

  • 1. Site is proxied through Cloudflare

    Your /mcp endpoint needs to be behind Cloudflare's proxy with the orange cloud on, so requests hit a Worker before they hit your origin. Standard prerequisite — same as any other edge feature. DNS proxy status docs ↗.

  • 2. WAF and a bot product are enabled

    WAF gives you the rule engine. To act on webmcp-auth's verdict (allow signed agents, block unsigned scripts), you'll want a bot product — Bot Management on Enterprise gives you the richest signal (per-request bot score), Super Bot Fight Mode on Pro or Business is a lighter starting point. Cloudflare bots docs ↗.

  • 3. Decide your tool surface

    Your MCP server probably exposes a handful of tools — search, get_product, add_to_cart, checkout, etc. Decide which agents are allowed to call which before you write the rules. The typical split: read-only tools open to any verified agent, write tools restricted to a smaller list. Account or admin tools you probably don't expose at all. Write the inventory down before you install.

  • 4. Pick a rollout stance

    Three reasonable starting points: shadow (verify, log, let everything through), permissive (block on obvious failures only — bad signature, expired, replayed), strict (Web Bot Auth signature required on every call). Most merchants start shadow on day one and graduate to strict within a week. The rollout below is the day-by-day version.

Install · Quick start

From zero to a deployed Worker.

The merchant template is a Cloudflare Worker project you can clone, configure with three environment variables, and deploy. Five steps; most teams hit step five inside an hour.

  • 1. Clone the template

    git clone https://gitlab.cfdata.org/mconroy/webmcp-auth
    cd webmcp-auth
    npm install

    The repo is a small npm workspace with the verifier library (@mconroy-cf/webmcp-auth-workers) and a ready-to-deploy Worker template (webmcp-auth-template) that fronts your existing MCP origin.

  • 2. Create a KV namespace for nonce replay

    npx wrangler kv:namespace create NONCE_STORE

    Wrangler prints an ID. Paste it into the [[kv_namespaces]] block in packages/webmcp-auth-template/wrangler.toml. KV is what makes nonce_replay rejection possible — the verifier records each accepted nonce for an 8-minute window and rejects re-uses.

  • 3. Point the Worker at your MCP origin

    In the same wrangler.toml: 

    [vars]
MCP_ORIGIN_URL = "https://mcp.your-store.example.com"
BLOCK_AGENTS   = "false"
STATIC_JWKS_URLS = ""

    STATIC_JWKS_URLS empty means "trust whichever directory each agent advertises in its Signature-Agent header" — Web Bot Auth's intended default. To pin trust to a fixed list, set it to comma-separated URLs.

  • 4. Configure your tool rules

    In src/worker/index.ts, adjust the defaultPolicy and per-agent overrides to match your tool inventory: 

    defaultPolicy: { allowTools: ["search", "get_product", "list_products"] },
agents: [
  { agentId: "openai-chatgpt", allowTools: "*" },
  { agentId: "noisy-startup",  denyTools: ["checkout"] },
],

    The library checks the request body wasn't tampered with on every tool call. If you set tool rules without enabling that check, the Worker refuses to start — without it, an attacker could swap the JSON-RPC body to call a different tool than the one the agent actually signed for. The forcing function is deliberate.

  • 5. Deploy

    npx wrangler deploy

    Then point a Worker Route at your /mcp path. From the next request onwards, every call is verified before it reaches your origin.

Verify · Conformance status

Make sure your install actually works.

webmcp-auth ships 26 unit tests covering the spec's normative behaviour: every supported algorithm, every failure path in the signature pipeline, every tool-rule outcome, plus the BLOCK_ALL kill switch. The library also runs an end-to-end smoke test against a mock signed agent in CI on every push.

What's tested today

Ed25519, RSA-PSS-SHA256, and RSA-PSS-SHA512 signatures. Multi-label structured-field parsing. JWK SHA-256 thumbprint matching. Nonce replay protection. Body-integrity checks (required and optional). Per-agent tool rules. KYA token verification. The BLOCK_ALL kill switch. Every documented failure-reason code.

How to verify your install

Run npm run demo from the template package. It generates a keypair, signs a request, and runs five canonical scenarios against your local Worker — one happy path, four expected failures (missing signature, expired signature, tampered body, replayed nonce). The happy path returns 200; the four failures each return their documented status and reason code.

Two honest caveats. First, there isn't yet a standalone webmcp-auth check CLI like TAPKit's tapkit check for verifying a deployed Worker against a fixed scenario matrix — that's on the roadmap; for now the unit-test matrix and the npm run demo script are the source of truth. Second, Web Bot Auth is still an Internet Draft (currently draft-meunier-web-bot-auth-architecture-05) — the library tracks the latest published draft and the test suite rebases when the spec moves, so expect breaking changes as the standard matures.

Process · Origin handoff

Handle the verified request.

A request that survives webmcp-auth arrives at your origin with the agent's identity verified. Your existing MCP server doesn't change — it just receives a few extra headers describing which agent is calling, and (if you've wired up user-auth) which user the agent is acting for.

request to your origin What you can trust without re-checking 
POST /mcp HTTP/1.1
Host: mcp.your-store.example.com
Content-Type: application/json

X-Webmcp-Agent-Id: openai-chatgpt
X-Webmcp-Agent-Operator: OpenAI
X-Webmcp-Agent-Verified: true
X-Webmcp-Tool-Name: search
X-Webmcp-Human-Id: usr_42                (if KYA configured)

{"jsonrpc":"2.0","method":"tools/call","id":1,
 "params":{"name":"search","arguments":{"q":"skis"}}}

  • What's in the headers

    X-Webmcp-Agent-Id — the stable identity of the agent that signed the request, resolved against the directory you trust. X-Webmcp-Tool-Name — the tool the agent asked to call. The body is unchanged from what the agent sent; you can re-parse it but you don't have to.

  • Trust the agent identity without re-checking

    The signature verification, body integrity, replay protection, and directory lookup all happened at the edge before this request was forwarded. If an X-Webmcp-Agent-* header is present, it's cryptographically grounded; your origin doesn't need to redo any of the crypto.

  • You still own user-auth

    For tools that act on behalf of a user (cart, account, checkout), the agent identity isn't enough — you need to authenticate the user too. Plug in your existing API auth (OAuth bearer, session cookie, signed JWT) and check it on these tools the way you already do. The library's X-Webmcp-Human-Id header is filled in only if you wire up the KYA verifier; for everything else, your origin's session logic stays in charge.

  • Business-logic rejects work normally

    Your MCP server can still reject for reasons that have nothing to do with auth (out of stock, user over their spending limit, fraud signal, etc.). Return a structured JSON-RPC error so the agent can explain the result to the user. webmcp-auth only proves who the agent is — your origin still decides what they're allowed to do once they're in.

  • Returning a useful response

    Make your tool responses agent-friendly: stable JSON shape, machine-readable error codes, useful `description` fields. Agents will parse what you return — make it something they can act on.

Operate · In production

Run the verifier in production.

Once webmcp-auth is enforcing, three things sit on the operations team's plate: ship the verdict log somewhere queryable, wire the verdict into Bot Management, and watch a handful of signals. Each one is a one-time setup; after that it runs itself.

  • 1. Ship the verdict log

    Set up a Logpush job pointing at your SIEM, R2, or a Workers Analytics Engine dataset. webmcp-auth's decision JSON is pre-structured: fields include result, agentId, toolName, reason, and latency_ms. The shape is stable across versions, so your dashboards and alerts won't break on upgrade.

  • 2. Wire the verdict into Bot Management

    When webmcp-auth returns a pass, set a header on the forwarded request — say cf-webmcp-verified: true. In your Bot Management custom rule, allow that header through; without it, fall through to the standard bot score. Verified agents flow through unimpeded; unverified bots get the answer they always got.

  • 3. Watch four signals

    Verified-agent rate — should climb as more agent platforms adopt Web Bot Auth.
    Reject-reason mix — nonce_replay spikes signal an attacker; signature_expired spikes signal clock skew on the agent side.
    Unknown-keyid rate — alert above zero; usually means a directory or JWKS issue.
    Tool-denied rate — if a known agent suddenly hits a wall of tool_denied rejects, you've probably tightened a rule incorrectly.

Failure-reason reference

Every rejected request returns a stable machine-readable reason code. Safe to branch on in alerts and dashboards.

Reason HTTP What it means
missing_signature_headers 401 Caller didn't sign the request at all.
signature_invalid 401 Signature didn't verify against the published key.
signature_expired 401 Signature outside its 8-minute validity window. Often clock skew.
nonce_replay 401 A previously-accepted nonce showed up again. Replay attempt.
unknown_keyid 401 Key not found in any directory you trust.
content_digest_mismatch 401 Body was changed between signing and arrival.
blocked_by_policy 403 BLOCK_ALL is on. Kill switch active.
agent_not_in_directory 403 Verified signature but the agent isn't on your trust list.
tool_denied 403 Agent isn't allowed to call this tool by your rules.
rate_limited 429 Per-agent rate limit exceeded.

Full table (26 reason codes) lives in the library README. Codes are stable across library versions; new reasons may be added but existing ones don't change.

A realistic one-week rollout.

Without a Visa-style external dependency, the WebMCP rollout is much shorter than TAP's. The pattern is the same — start in shadow mode, run a conformance check, graduate to enforcing — but the calendar is days, not weeks. A typical team gets through this in a working week.

Day 0 · Prereqs

Confirm the four edge prereqs above: site on Cloudflare, WAF + bot product enabled, tool inventory written down, rollout stance picked. 1–2 hours of confirmation; nothing webmcp-auth-specific yet.

Day 1 · Install in shadow mode

Clone the template, bind a KV namespace, deploy to a staging Worker Route. Run the verifier with BLOCK_AGENTS=false and no tool rules yet — every request passes through but the verdict is logged. You're gathering signal, not enforcing.

Day 2 · Run the demo + confirm signals

npm run demo against your staging Worker. Five scenarios — one happy path, four expected failures (missing signature, expired signature, body tampering, replayed nonce). The happy path returns 200; each failure returns the documented status and reason code. Now you know the Worker is actually working.

Day 3 · Enforce on read-only tools

Switch from shadow to enforcing on your safest tools first — the read-only ones (search, get_product). Watch for unexpected missing_signature_headers or agent_not_in_directory spikes. If a known good agent is failing, your directory config is wrong; fix and continue.

Day 4 · Enforce on write tools + add rules

Add per-agent rules for your write tools (add_to_cart, checkout). The library starts checking request-body integrity automatically the moment you set tool rules. Watch for tool_denied rejects in your logs to confirm the rules behave as you expected.

Day 5 · Wire into Bot Management

Add the cf-webmcp-verified header on passes, write a Bot Management custom rule that allows verified agents through unconditionally and falls through to the bot score otherwise. Now your bot policy and your signed-agent policy work together.

Steady state. Verified-agent volume in your verdict log climbs as agent platforms adopt Web Bot Auth. nonce_replay and unknown_keyid rates stay near zero. Your Bot Management dashboard shows a clean separation between verified-agent traffic and unverified bot noise. From here, ongoing work is small: keep the package up to date and watch for new directories as more agent vendors stand them up.

Could you just build this yourself? Yes. Here's what that looks like.

webmcp-auth is MIT-licensed — you can fork it, reimplement it, or read the spec and start from scratch. Here's what each row actually costs. We're not hiding the ball: this is why we wrote the library in the first place, after we caught most of these gaps in our own initial implementation during code review.

What you need Build in-house With webmcp-auth
RFC 9421 parser Multi-label structured-field dictionaries. Covered-field parameters. Strict spelling of derived components. Easy to get subtly wrong; we did. 1–2 engineer-days, plus a sharp-eyed code reviewer. Built in. Multi-label dictionary support tested.
Algorithm coverage Web Bot Auth's normative algorithms are Ed25519 and RSA-PSS-SHA512. The JOSE default (RSA-PSS-SHA256) is a different algorithm — picking it instead means your verifier silently rejects every spec-compliant signer. Hours to fix once you spot it, weeks if you don't. Ed25519, RSA-PSS-SHA512, RSA-PSS-SHA256. Auto-detected per request.
Key resolution The spec says keyid is the JWK SHA-256 thumbprint, not whatever string the directory chooses. We initially treated it as opaque, which would have rejected any directory that publishes JWKs without a kid field. Half a day of fix-up. Computes the thumbprint and matches against it. Fallback to kid-string for legacy directories.
Body integrity Without checking that the request body wasn't tampered with, an attacker can swap the JSON-RPC payload to call a different tool than the one the agent signed for. Real bypass, easy to miss. The library refuses to start in unsafe configurations as a forcing function. Auto-enforced when tool rules are configured.
Nonce replay protection KV-backed store, check-early/write-late timing, cross-colo consistency window. 2–3 days including tests. nonceStore: env.NONCE_STORE. Done.
Directory discovery Honour the Signature-Agent header for in-band discovery; cache resolved keys per keyid; handle directory rotation without downtime. In-band Signature-Agent default; pin to a static list when you want.
Per-tool rule enforcement Allow and deny lists per agent, per tool. Default-allow versus default-deny semantics. Plus the body-integrity forcing function above, so you can't accidentally ship an unsafe combination. Two lines of config. Refuses to start unsafe.
Spec evolution Web Bot Auth is still an Internet Draft. When the spec revs, you re-read it and diff your implementation. You update the package.

Honest rule of thumb: a focused engineering team gets from zero to spec-conformant in about a week, plus a second week of integration surprises. webmcp-auth is a few hundred lines of config in your Worker. Either path is valid — we just want you to price the choice accurately.

Merchant FAQ.

The questions that come up every time we walk a merchant engineering team through webmcp-auth. The deeper FAQ (dev-focused) lives in the playbook.

  • Does this handle user authentication?

    No, and we want to be clear about that. webmcp-auth proves which agent is calling. It does not prove which user the agent is acting for. For read-only tools (search, get_product, list_products) that's enough — agent identity is the whole story. For tools that act on behalf of a user (cart, account, checkout) you need a second identity layer on top: an OAuth bearer the agent obtained on the user's behalf, a session cookie that flowed through from the user's browser, a signed JWT, whatever you already use for API auth. The library's KYA hook is the slot for surfacing that authenticated user identity to your origin once you've verified it. Credential delegation (the agent authenticating as the user without the user's credentials leaving their browser) is a real gap we're thinking about, but we don't have a shipped design yet — partner conversations are how we'll figure out the right shape.

  • Is Web Bot Auth widely adopted yet?

    Honestly: it's still early. The spec is an IETF Internet Draft authored by Cloudflare; major AI platforms have signalled support and OpenAI has published example signing code, but adoption is uneven. Today, webmcp-auth is a forward-looking install: deploy it now and your Worker is ready for the agents that adopt the spec, with a clean answer (missing_signature_headers → 401) for the ones that haven't. The BLOCK_ALL switch lets you refuse all unsigned traffic on day one if you want a stricter posture.

  • What's the latency cost of verification?

    Ed25519 verification on Workers is single-digit milliseconds. RSA-PSS is a touch more. JWKS lookups are cached per keyid (5-minute per-isolate TTL) so after the first request from any agent, you're amortising close to zero network cost. We'll publish hard numbers once we have enough deployment data to say them honestly.

  • What happens to unsigned requests?

    Policy decision, not a verifier decision. Default is missing_signature_headers → 401, and you decide what to do: enforce, log-only during rollout, or feed the result into your existing Bot Management custom rule. Read-only tools typically stay permissive during rollout; write tools go strict first.

  • How does this interact with my existing Bot Management rules?

    Complementary. Bot Management handles obvious scrapers (low bot score, no signature). webmcp-auth handles "claims to be an agent" traffic — the kind that needs cryptographic proof to act on. The typical wiring: pass-through verified agent traffic via a header, fall through to the bot score for everything else.

  • What if a known agent stops working?

    Three causes in practice. (1) The agent rotated its signing key but its directory hasn't republished — you'll see unknown_keyid in your logs. (2) Clock skew on the agent side — you'll see signature_expired. (3) The agent's directory URL changed — you'll see signature_invalid with the directory unreachable in your logs. Each one has a clean failure-reason code so triage is fast.

  • Can we run this without Workers KV?

    Yes — pass any NonceStore-shaped implementation. KV is the easy default; for cross-millisecond consistency a Durable Object works too. The interface is two methods (get, put); swap implementations as needed.

  • What about TAP and WebMCP together?

    The two verifiers run happily in the same Worker. Use TAPKit on your /checkout route and webmcp-auth on your /mcp route — they're checking different paths against different rules, so they don't step on each other. They also share the same underlying signature standard, which keeps the conceptual overhead small.

  • Is this officially supported by Cloudflare?

    webmcp-auth is open source, MIT-licensed, written by the team at Cloudflare working on agent security. The @cloudflare/ namespace reflects authorship. It's not (yet) a packaged product with a commercial SLA. If you need formal support or want to talk through a deployment, see the conversation invite below.

Want to talk it through?

We're not running a formal pilot programme for WebMCP yet — the standard is too young and the adoption picture is too thin. But if you're thinking about deploying this, we want to hear from you. Real partner conversations are how we decide what to build next.

Tell us your context

What's your tool surface? Which AI agents do you care about? Are you exposing the same tools to a browser AI (Phase 1) and a remote agent (Phase 2), or just one? What does your existing Bot Management config look like? The more concrete the question, the better the answer.

Help us prioritise

Things on the roadmap include a webmcp-auth check CLI, a first-party CF dashboard for the traffic logger, deeper Bot Management integration, and a published list of trusted agent directories. Tell us which one unblocks you.

Send a note → Open the playbook →

Typical reply: 1–2 business days.

Ready to try it?

The fastest path is the playbook — a short read that links each phase to its runnable Cloudflare Worker. If you want to start with the code, jump straight to the auth Worker template.

Open the WebMCP playbook → webmcp-auth template → Back to merchants →

The standard is still maturing. Web Bot Auth is an Internet Draft, and adoption across AI vendors is uneven. Everything on this page works today, but expect breaking changes as the spec evolves. We'll update the page as real partner deployments teach us what's missing.