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 announcement pitches this as the moment the web finally shakes off CAPTCHAs. That 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 once 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.

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, and 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. That is worth having on its own. 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.

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 cannot 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 a 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. The precedent operators reach for is the CA world, where public browser root-store policy, the CA/Browser Forum and Certificate Transparency logs took roughly two decades to converge into a workable governance stack. Let's Encrypt then operates inside that stack rather than being the stack. PACT has none of the three equivalents yet: no public issuer-list policy, no cross-browser standards forum specifically for personhood attestation, and no per-issuance transparency mechanism. A CT-style log is also harder to build here than for CAs, because the whole point of a blinded token is that the issuer does not see what it signs. Issuer key rotations and aggregate issuance volumes can be logged, but per-token issuance cannot be logged without breaking the privacy property the protocol exists to deliver. The IETF Privacy Pass working group is the closest thing to an open forcing function today. A Chrome-Root-Program-style unilateral trust list per browser is the club outcome. Neither the announcement nor the accompanying press coverage takes a firm position on which of these paths the coalition intends.

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.

In practice, PACT 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. Those are cleared with no friction, which is the whole 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.

Implementation status: Edge Canary ships Automatic Verification (August 2026)

Microsoft has begun rolling out an "Automatic Verification" setting in Edge Canary for desktop, reported by The Win Central on 6 August 2026. The feature lets participating websites exchange secure verification tokens so that a user who has recently completed a CAPTCHA on one supported site is not challenged again on another. The token exchange happens in the background with no user-visible prompt, and Microsoft describes the mechanism as an industry approach for verifying humanity without exposing personal information. That is the same design pattern as PACT, even though the writeup does not name the protocol directly.

The setting lives under Settings → Privacy, Search, and Services → Automatic Verification. Edge Canary is the first of the four announced browsers to expose a user-facing surface for this behaviour, with rollout to the Dev, Beta and Stable channels expected in future releases.

This is a browser implementation of the accept-a-token path. It does not close any of the design gaps PACT still leaves open. Users on unattested devices, users on Safari, and adversarial traffic without a token still need a decision from somewhere, and that is where a specialist detection layer comes in.

Under the hood: what Edge is actually calling

The token surface Edge Canary exposes sits on top of a stack that already exists in Chromium as Private State Tokens (formerly Trust Tokens), a network-service subsystem living under services/network/trust_tokens/ and gated by the PrivateStateTokens feature flag. It speaks the Privacy Pass HTTP authentication scheme that the IETF Privacy Pass working group formalised as RFC 9576. In that flow the origin sends a WWW-Authenticate: PrivateToken challenge naming issuers it will accept, the browser blinds a token and sends it to a trusted issuer over an HTTPS issuance endpoint, the issuer signs the blinded token, and the browser unblinds the signature and attaches it to the next request via Authorization: PrivateToken. The origin verifies the signature against the issuer's public key. Because the token was blinded during issuance, the issuer cannot link the signed token back to a redemption, and the origin cannot link the redemption back to the issuance session.

The novel piece PACT adds is the credential-with-state extension. The construction cited in the Mozilla Hacks writeup is Anonymous Credit Tokens (ACT), a CFRG draft from Samuel Schlesinger and Jonathan Katz at Google published February 2026 as draft-schlesinger-cfrg-act-01. ACT is built on keyed-verification anonymous credentials and BBS-style blind signatures. A credential carries an internal counter; on presentation the client uses a sigma protocol with Fiat-Shamir and a bit-decomposition range proof to show the counter is above a threshold and to authorise a mutation, without revealing the counter's actual value. That is the primitive that lets an origin adjust a credential when its perception of the holder improves or worsens without giving up unlinkability between presentations.

Put together, Edge's "Automatic Verification" toggle is a user-facing wrapper over the existing Chromium PrivateStateTokens plumbing plus Microsoft's own trusted-issuer list. The C++ that issues and redeems tokens is upstream Chromium and inspectable. The Edge-branded behaviour is the trust list and the settings UI, not the crypto.

How Prosopo Fits

Prosopo is a specialist bot and agent trust management platform, in the category Forrester renamed earlier in 2026. Its position in a PACT world is straightforward.

If a request arrives with a valid Private Access Token from an issuer the operator trusts, Prosopo honours it and skips 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 claim 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.