Cloudflare is working with Mozilla Firefox, Google Chrome, Microsoft Edge, and Shopify on a proposed privacy-focused protocol meant to help websites separate legitimate traffic from abusive automation without leaning as heavily on logins, CAPTCHAs, or tracking.
The technology is called Private Access Control Tokens, or PACT. Cloudflare announced the initiative on June 22, 2026, describing it as a protocol the companies plan to develop and submit for standardization. A firm timeline for standardization or broad browser deployment has not been publicly confirmed.
At a high level, PACT is meant to give websites a way to receive a signal that a request is more likely to be legitimate while limiting how much identifying information gets passed around the web. That matters because the old problem of bot detection is getting harder: websites need to block scraping, fraud, credential attacks, and other automated abuse, but heavy-handed defenses can also punish real visitors and break useful automated tools.
What Cloudflare PACT Is Trying to Solve
The web’s bot problem is no longer limited to obvious spam scripts hammering login forms. Site operators are also preparing for more traffic from AI agents and other automated systems acting on behalf of users. Cloudflare’s framing is that the browser and security layers need a more precise way to identify acceptable traffic without turning every request into a tracking opportunity.
That is the hard part. A website can ask users to log in, complete a CAPTCHA, accept fingerprinting, or pass other checks, but each option has a cost. Logins create friction. CAPTCHAs annoy users and can be inaccessible. Device fingerprinting and cross-site tracking raise privacy concerns. Aggressive bot blocking can also misclassify real customers, especially in commerce flows where a delay or false positive can interrupt checkout.
PACT is aimed at that middle ground: a privacy-preserving proof that helps a site decide whether traffic is likely legitimate, without giving the site a reusable identity for the person behind the browser.
How PACT Is Supposed to Work
Cloudflare describes PACT as a token-based model. In that model, a site or service with a stronger basis for believing a real person is involved can issue an anonymous token. A browser can then present that token to another site as a signal that the request is not malicious.
The intended flow looks roughly like this:
- A user interacts with a service that has some confidence a real person is present.
- That service issues an anonymous token rather than a portable identity.
- The user’s browser can later present the token to another website.
- The receiving site gets a trust signal without learning the user’s identity or browsing history.
That design is meant to reduce the need for repeated CAPTCHA prompts and other blunt checks. It is also meant to avoid creating a new cross-site tracking system. Cloudflare says PACT is designed so sites cannot use the token mechanism to identify users or reconstruct where they have been browsing.
Those privacy guarantees will depend on the final technical design, implementation, and standardization process. The important distinction is that PACT is being positioned as infrastructure for proving legitimacy, not as a new account system or universal web ID.
Why Browser Support Matters
The browser companies are the key part of this effort. A protocol like PACT only becomes useful if browsers can handle token issuance and presentation in a consistent way across the web. That is why participation from Firefox, Chrome, and Edge is significant: these browsers represent major parts of the open web, and their involvement gives the proposal a path beyond a single vendor’s network.
Microsoft and Mozilla are participating in the standards effort, and Shopify is involved from the commerce side. Shopify’s role is especially relevant because online stores are among the places where bot protection and customer friction collide most directly. Fraud prevention, inventory abuse, scraping, fake accounts, and checkout disruption all create pressure for stronger defenses, but shoppers are quick to abandon a purchase when security checks get in the way.
For merchants, the appeal of a system like PACT is straightforward: fewer bad requests, fewer unnecessary challenges for legitimate customers, and less dependence on invasive tracking. Whether it works that cleanly in practice will depend on how broadly it is adopted and how sites decide to trust or reject the signals.
What This Means for Website Owners
For website operators, PACT is best understood as a potential future layer in the bot-management stack, not a replacement for every existing control. Even if standardized, it would likely sit alongside rate limiting, fraud detection, authentication, abuse reporting, and other security measures.
The practical upside would be a better signal at the edge: a way to distinguish a normal visitor, an authorized agent, or a suspicious automated request without forcing every user through the same challenge. That could be useful for publishers, retailers, SaaS apps, financial services, ticketing platforms, and any other site where automated abuse can become expensive or operationally disruptive.
But there are still open questions. The industry will need to work through who can issue tokens, how trust is established, how abuse of issuers is handled, how tokens expire, and how the system avoids becoming another gatekeeping mechanism for the web. A privacy-preserving protocol can still create power imbalances if only a small number of large platforms become trusted issuers.
There is also a measurement problem. If a site starts accepting PACT signals, it will need to know how much risk those signals actually reduce. A token that proves some prior interaction with a trusted context is useful only if attackers cannot reliably obtain or replay it at scale.
The Bigger Privacy Tradeoff
PACT is part of a larger shift in web security: browsers, infrastructure providers, and commerce platforms are trying to reduce reliance on hidden identifiers while still giving websites enough information to defend themselves. That is a difficult balance because privacy and abuse prevention are often treated as competing goals.
The pitch behind PACT is that they do not have to be. A website should be able to learn that a request has passed a useful legitimacy check without learning who the user is. A browser should be able to help carry that proof without becoming a tracking conduit. A merchant should be able to block abusive automation without pushing every buyer into a verification maze.
For now, PACT is still a proposed protocol with a standards path ahead of it. The near-term story is not that CAPTCHAs are disappearing or that bot detection has been solved. It is that Cloudflare, major browser vendors, and Shopify are aligning around a more private architecture for a problem that is becoming harder to ignore.
If the proposal advances, the most important test will be whether it gives websites a useful security signal without creating a new way to follow people around the internet. That is the bar PACT will have to clear.