For bot-defense and edge networks

One policy switch that returns an agent's tier.

Your customers no longer want to block all automation. They want the agent that buys, and the person behind it, and not the one that scrapes. The check reads every issuer's papers in one format and hands your rules engine one tier to write rules against, plus a shared ban list no single network can build.

Written for bot-management product and engineering teams at Cloudflare, Fastly, F5 and Akamai, and for the websites and platforms behind them.

01 — What your customers are asking now

The question has changed from "bot or not".

To "which agent, and who is behind it"

A merchant no longer wants to block all automation. It wants the agent that buys, and the person behind it, and not the one that scrapes. F5 says its own bot defenses "can also block legitimate agent-driven commerce".

Blocking fails in both directions

Amazon cut off Meta's Muse within two weeks while Shopify, Instacart and Expedia signed it up. Perplexity's agent disguised its sessions as Chrome; Amazon blocked it, it was back within 24 hours, and a federal court had to step in.

Identification is becoming a term of service

Amazon now requires every agent to identify itself when it accesses its services. Your customers will write the same clause, and they will ask you to enforce it at the edge.

Three answers are needed for every arriving agent: which platform and agent, who is responsible for it, and whether it is still in good standing anywhere.

Sources: F5–Skyfire announcement (2026); a16z, Top 100 Gen AI Consumer Apps (2026); Amazon v. Perplexity, N.D. Cal., preliminary injunction, March 2026.

02 — What you have today

Good programs, each stopping one step short.

Signed agents and Web Bot Auth

You validate a platform's signature and keep a list of registered operators. It tells a customer "this is OpenAI's traffic" or "this is Browserbase's", not which agent it is, who is responsible for it, or whether it was banned elsewhere last night.

One token vendor at a time

Skyfire inside F5 and Fastly; Skyfire through Experian on Cloudflare. Each is one integration for one token, and the result is a yes or no per vendor rather than a tier your customer can write rules against.

No shared standing

An agent banned by one of your customers is unknown to the next, and unknown to a rival network's customers entirely. Nothing connects the ban lists, and a blocked agent is back under a new name within the hour.

None of these are bugs. They are what happens when every issuer's paper is read by a separate integration and nobody reads the whole file.

Sources: Cloudflare, "The age of agents: cryptographically recognizing agent traffic" (2026); Skyfire announcements with F5, Fastly and Experian (2026).

03 — What we add

One format, one directory, one list, one switch.

What the check reads

The platform's Web Bot Auth signature; our registration (operator, purpose, model, scope); an identity vendor's "verified person or company" note; a token vendor's token; an enterprise's own agent certificate; an institution's note. It confirms every paper names the same agent and the same key, that the agent holds that key, and that nothing is on the shared revocation list.

What you expose

One policy switch per rule, keyed to a tier rather than a vendor. A customer writes "unbound agents may browse; company-backed may buy; person-backed may check out above $500 or change account settings; failed is challenged or blocked." The same rule works for every issuer you add later, with no new integration.

TierBrowseAdd to cartCheck outAccount changes
Person-backedA verified person is bound to the agentAllowAllowAllowAllow
Company-backedA verified company is bound to the agentAllowAllowAllowDeny
UnboundRegistered, no one behind itAllowDenyDenyDeny
FailedMissing, forged, borrowed or revokedChallengeDenyDenyDeny

Defaults for a commerce customer. Each customer sets its own, per action, in the console it already uses.

04 — How it fits at the edge

In the request path, without leaving it.

No outside calls

Signatures verify against issuer keys published in advance and cached, exactly as certificate checks do. The directory and the revocation list are feeds you pull on a schedule. Milliseconds, and nothing to wait on.

A challenge you already issue

An unregistered agent gets a standard "registration required" response carrying the registry address. Honest agents register once and come back with papers; disguised ones are refused, and when caught, reported.

Your program becomes the on-ramp

Operators already on your signed-agents list get a registration that also works at computing providers and API vendors, and your list becomes an issuer in the directory. Nothing you built is thrown away.

Delivered your way

A module in your edge runtime, a managed app in your marketplace, or a library. We align to Web Bot Auth at the IETF and will contribute the extensions rather than fork them.

05 — What your customers get

Good agents in, bad agents out, as one setting.

Tiers instead of a binary

A store can let an unowned agent browse, a company's agent buy, and a person's agent check out, instead of choosing between blocking all automation and admitting all of it.

Resistance to stolen credentials

Every paper is issued to a key only the real agent holds, and every request is signed with it. A leaked token is useless to whoever picked it up, which no bearer token offers today.

Bans that travel

An agent one customer bans is flagged at every other customer, and at doors on other networks and at computing providers. Today a ban is a technical block at one site and the agent is back within the hour.

Someone accountable

When an agent does harm, the record names its operator and the person or company behind it, which is what a fraud team, a lawyer or a regulator asks for first.

For the customer this is one switch in a console they already use, which is how the first agent token reached merchants, and why it reached so many.

06 — What you get

The feature customers ask for, without the parts you don't want to own.

No vendor-by-vendor integrations

One format and one directory replace a separate integration for every token vendor, identity vendor and enterprise identity system, now and as new ones appear.

A list you do not have to govern

Evidence standards, appeals and antitrust-safe rules for a shared ban list are held by a neutral operator, so you are never the party deciding who is blacklisted across the industry.

A revenue line

Sold as a bundle, a marketplace app or a revenue share, on top of the bot-management product your customers already pay for.

Portability for your registrants

The operators who registered with your signed-agents program gain papers that work at computing providers and API vendors too, which makes your program the place to register first.

07 — The proposal

A pilot on one customer segment.

What we provide

Module, feeds, standards work

  • The checker as a module for your edge runtime, or a library, free during the pilot.
  • The directory and revocation feeds, and the registry your signed-agent operators register with.
  • Integration support, and standards work at the IETF alongside your Web Bot Auth drafts.
What we ask

A format, a switch, a mention

  • Recognize the paper format at the edge and expose one policy switch that returns a tier.
  • Pass your customers' bans of registered agents to the shared list, under the consortium rules.
  • Name the registration in your signed-agents documentation, so operators find it.
The pilot

One segment, 90 days

  • Commerce customers or API customers, whichever asks loudest.
  • Measured together: legitimate agents wrongly blocked, fraud on agent sessions, and time for an operator to get from blocked to admitted.
  • Commercial terms after the pilot: bundle, marketplace or revenue share, your choice.

08 — Proof

Built and tested. It reads Web Bot Auth signatures today.

Forged signatures, altered requests, borrowed and stolen papers, revoked and expired registrations are refused with the reason named; honest agents are admitted with the right tier.

11kinds of arrival, honest and dishonest, run through the check against four kinds of door
23automated tests covering the signatures, the papers, the bindings, the key proof, revocation and expiry
2implementations, one server-side and one in a web browser, cross-checked against each other: they agree on every verdict

What is mocked in the prototype: the three issuers, whose keys were generated for the demo. What is real: every signature, format and check.

09 — The next step

A 45-minute working session.

With your bot-management product and engineering leads: how the check sits in your request path, how the tier maps to your rules engine, and which customer segment to pilot.

  • The clickable demonstration, and the code and tests that travel with it.
  • The tier as a field your rules engine already understands.
  • Your signed-agents program as the first issuer in the directory.

Request a briefing

For bot-management product and engineering teams, and the platforms behind them.