Article · Jul 23, 2026 · 10 min read

Private Access Control Tokens (PACT): Cloudflare's Anti-Bot Protocol with Chrome, Edge and Firefox

Cloudflare, Chrome, Edge, Firefox and Shopify announced Private Access Control Tokens (PACT) on 22 June 2026, a privacy-preserving protocol for proving legitimate traffic without CAPTCHAs. Here is what the proposal does, what it does not, and what it means for bot management.

Private Access Control Tokens (PACT): Cloudflare's Anti-Bot Protocol with Chrome, Edge and Firefox

On 22 June 2026, Cloudflare announced Private Access Control Tokens (PACT), a proposal for a privacy-preserving anti-bot protocol developed with Google (Chrome), Microsoft (Edge), Mozilla (Firefox) and Shopify. The idea is that browsers hand websites a cryptographically blinded token proving the request is legitimate, so the site does not have to fall back on a CAPTCHA or other visible friction.

The framing in the announcement is that this is how the web finally shakes off CAPTCHAs. That framing is worth taking seriously. It is also worth being precise about what PACT actually replaces, what it does not, and what a specialist bot management layer still has to do in the world after PACT ships.

PACT is an emerging technology. This article covers the state of the proposal as of the June 2026 announcement and will be updated as the specification advances, browser implementations ship, and the open questions around Apple, issuer trust and governance are resolved.

Background

The design lineage runs back to Privacy Pass, a token protocol Cloudflare and Apple published together in 2022 to skip CAPTCHAs on Safari via iOS device attestation. That original scheme, later formalised as Private Access Tokens, used the underlying operating system as the attester: iOS App Attest for iPhone and iPad, Android Play Integrity for Android. Private Access Tokens shipped in Safari and worked in exactly one browser. A parallel Google-led experiment, Chrome Trust Tokens (later renamed Private State Tokens), tried the same blinded-token pattern from the Chrome side but never landed multi-vendor support.

PACT keeps the same cryptographic core as Private Access Tokens (blinded tokens over trusted issuers, backed by browser attestation) but broadens the alliance. The June 2026 announcement puts Chrome, Edge, Firefox and Shopify on board with Cloudflare. The coalition intends to submit the specification for standardisation.

One notable absence is Apple, which co-developed Privacy Pass with Cloudflare and shipped Private Access Tokens in Safari four years earlier. Whether Apple joins the PACT coalition later, or continues its own PAT track separately, is not resolved.

The other reason the timing matters is the traffic mix. Cloudflare's own Radar data, cited in the announcement, put automated requests at 58% of HTTP traffic as of June 2026. Cloudflare CEO Matthew Prince had projected the human-minority tipping point for 2027 at SXSW earlier in the year. It landed early.

How PACT Works

The protocol borrows the blinded-token pattern that Privacy Pass and Private Access Tokens already use.

When a browser wants to fetch a resource from a PACT-supporting origin, the origin can respond with an HTTP challenge that names one or more trusted issuers it will accept. The browser then asks a trusted issuer (a service run by a party the origin trusts) for a token. The issuer decides, using whatever criteria it publishes, whether to issue one. Cryptographically the token is blinded so the issuer does not learn where it will be redeemed and the accepting origin cannot link the token back to a specific user or session. The browser attaches the token to the request. The origin verifies the signature against the issuer's public key and treats the request as legitimate.

Two things about the design are worth calling out.

What the token proves

The token proves the issuer signed for something (a real personhood check, a valid device attestation, a policy-compliant client, a whitelisted agent). It does not prove anything about the underlying user. That is what makes the design privacy-preserving.

Human tokens and agent tokens

PACT explicitly covers both human tokens (a person is at the end of this browser) and agent tokens (an authorised software agent is making this request on behalf of a person or workflow). Cloudflare's writeup positions PACT as accommodating the agentic-AI shift the announcement uses to justify the whole project.

For an end user on Chrome, Edge or Firefox once PACT ships, none of this is visible. The token exchange happens in the background, legitimate requests go through, and no CAPTCHA appears.

What PACT Solves

For the traffic pattern the design was aimed at, PACT is a real improvement.

Legitimate humans on well-maintained mainstream browsers stop seeing CAPTCHAs. Whatever else you think of Cloudflare's positioning, that is worth having. CAPTCHA friction hurts conversion and creates accessibility problems for users with disabilities. In reCAPTCHA v3's case it also comes with real privacy trade-offs. Replacing that with a blinded token verified in the background improves both UX and privacy at the same time.

Legitimate first-party agents can be identified. The agent-token branch of PACT is the more interesting half. If an agentic workflow (a Shopify checkout agent, a personal assistant working on behalf of a user, a customer-service bot representing a company) can be issued a token by an issuer the origin trusts, that origin can distinguish it from an unauthorised scraper without asking the operator to maintain an allow-list by hand.

Third-party surveillance moves down the stack. The design constraint is that neither the issuer nor the origin can link a token to a user. That is a stronger privacy story than most behavioural-scoring systems that are today's default.

Taken together, these are meaningful improvements. PACT is a good protocol design for the case it targets.

What PACT Does Not Solve

PACT verifies specifically what an issuer signed for. Several categories of traffic sit outside that design entirely.

Unattested and unattestable devices. A desktop Linux user, a Windows workstation with an older TPM, a corporate laptop where IT has disabled attestation, a browser running inside a container, a privacy-focused user on Tor: none of these produce a PACT-issuable device attestation. All of them are legitimate. If an origin only accepts traffic that arrives with a valid token, it locks these users out. If it accepts traffic without a token, the operator's bot problem is completely untouched for that segment, because that is exactly the segment adversarial automation lives on.

Residential-proxy stealth automation. Modern scraping and credential-stuffing frameworks run on non-attested Linux containers, route through residential proxy pools to defeat IP reputation, and imitate mainstream browsers well enough to defeat passive fingerprinting. They never call an attestation API and never receive a token. From the origin's point of view, a stealth scraper with no token looks identical to a legitimate desktop Linux user with no token. PACT does not distinguish them.

Adversarial autonomous agents. The agent-token branch of PACT is only useful when the agent is willing to be identified. Adversarial agents (scraping bots pretending to be legitimate, ad-fraud automation, ticket-touting bots, credential-stuffing frameworks) will not walk up to a trusted issuer and ask to be signed for. They will run without tokens, on the unattested surface, exactly as they do today. This is the growth story in bot traffic. PACT does not touch it.

Non-consumer bot traffic. Ticket scalping, credential stuffing, account takeover, free-trial abuse, generic scraping. None of these run on attested consumer hardware as a matter of design. They are engineered to run on the unattested Linux surface precisely because attestation is the thing they cannot pass.

The Apple gap. Apple's absence is a governance problem, not just a marketing one. Safari's share of desktop and mobile traffic is not small. If PACT ships without Safari participating, origins that want the CAPTCHA-free UX have to either accept Safari sessions without a token (the whole non-adversarial iOS user base arrives on the unattested surface) or serve Safari users a fallback CAPTCHA anyway. Either choice weakens the "no more CAPTCHAs" story.

The issuer-trust question. Who gets to be a trusted issuer, and who decides, remains unresolved. If Cloudflare is the only large issuer at launch, PACT becomes a Cloudflare-managed trust perimeter on top of the browser it does not run. If the issuer list becomes a permissioned club negotiated between browsers and CDNs, that is a real centralisation problem for the open web. Neither the announcement nor the accompanying press coverage takes a firm position on this.

Cloudflare's own product portfolio confirms this reading. Alongside the PACT announcement Cloudflare launched Precursor, a client-side runtime detection product analysing mouse movement, cognitive load and other behavioural signals to distinguish humans from agents. Cloudflare is shipping PACT and Precursor together because PACT alone does not cover the adversarial surface. Precursor is Cloudflare's own answer to the traffic PACT does not attest for.

The specialist bot and agent trust management category exists for the same reason. Forrester's Q2 2026 Wave named DataDome, HUMAN and Kasada as Leaders. Prosopo sits in the same category as the specialist entry, aimed at the same traffic PACT deliberately does not judge.

The honest way to read PACT is that it authenticates the well-behaved half of the internet on the four browsers that have signed up. That half is worth authenticating. The operator's real bot problem sits mostly outside it.

Where Challenges Still Belong

Once PACT ships, an origin sees two populations of traffic. The first is browsers and agents arriving with a valid token from a trusted issuer, and those are cleared with no friction, which is the point of the protocol. The second is everything else: users on unattested browsers, users on Safari for as long as Apple stays out, legitimate agents that predate the issuer ecosystem, and, mixed in with all of them, the entire adversarial traffic surface. This second population still needs a decision, and a missing token cannot be that decision. Rejecting the traffic locks out real users; accepting it invisibly leaves the bot problem intact.

The decision that segment needs is what a challenge is for, and in practice it is not a visible CAPTCHA in most cases. Prosopo runs invisible-first: behavioural signal, JA4 fingerprinting, adaptive proof-of-work, and ML-driven Access Rules, all applied to unattested traffic without asking the user to do anything visible. When the underlying signal is suspicious (residential-proxy stealth automation, an agent hitting a login endpoint at machine cadence, credential-stuffing patterns) the challenge escalates. Legitimate users on the unattested surface see nothing, adversarial traffic is asked to do work that is expensive at scale or blocked outright, and after PACT ships, a challenge exists specifically to decide on the traffic the protocol deliberately does not judge.

How Prosopo Fits

Prosopo is a specialist bot and agent trust management platform, in the category Forrester renamed earlier in 2026. The natural position for it in a PACT world is direct.

If a request arrives with a valid Private Access Token from an issuer the operator trusts, Prosopo can honour it and skip its own detection. That accept-and-trust path is a small integration on the ingress side and keeps operators standards-compatible with the PACT and Private Access Tokens ecosystem.

If a request arrives without a token, or with a token from an untrusted issuer, Prosopo runs its full stack: behavioural analysis, browser fingerprinting, adaptive challenge escalation and human-readable Access Rules with a reason on every verdict. Two delivery modes are available. The first is a drop-in widget for form-scoped protection. The second is invisible enforcement at the edge for whole-site protection, running on Cloudflare Workers, AWS Lambda@Edge, Fastly Compute@Edge, Vercel and Netlify edge runtimes, or on-premise via the Prosopo backend SDK. Both delivery modes run the same detection stack.

The two layers are not competitors. They cover different halves of the traffic mix, and after PACT ships the second half is where the operator's real bot problem still lives.

What Operators Should Do Now

PACT is a proposal, not a shipping standard. Timelines from proposal to browser rollout to origin adoption typically run in years, and the standardisation, governance and Apple questions above are all live. There is no urgency to reconfigure anything today.

Accept Private Access Control Tokens at ingress when they start arriving. Do not build custom rejection logic around them, and treat a valid token as one strong positive signal.

Do not accept the framing that PACT ends the operator's bot problem. It ends the CAPTCHA problem for a specific well-behaved segment of the internet. The problem operators are paying to solve (credential stuffing, scraping, agent-driven abuse) sits on the unattested surface where PACT does not go.

Keep a specialist bot management layer on the unattested traffic. The operators who ship first with the hybrid setup (accept the token where it is offered, run specialist detection on everything else) will have both the best UX for legitimate traffic and the best defence in place when the transition finishes.

PACT improves the internet for the well-behaved half of its traffic. Most of the operator's bot problem lives outside PACT's design, on the unattested surface. Prosopo is built as the specialist detection layer that covers exactly that surface.

Tagged

pact private-access-control-tokens cloudflare browser-attestation bot-protection captcha-alternative procaptcha
Chris Taylor

Chris Taylor

Building privacy-first bot protection at Prosopo.

More articles by Chris Taylor
Ready to ditch Google reCAPTCHA?

Start for free today. No credit card required.