Use Cloudflare PACT to prepare for a web with fewer CAPTCHAs
Cloudflare, Mozilla, Google, Microsoft, and Shopify are developing Private Access Control Tokens, a privacy-preserving way for sites to distinguish legitimate visitors and authorized agents from abusive automated traffic.
Cloudflare has confirmed a new browser-backed effort called Private Access Control Tokens, or PACT. Confidence level: confirmed for the collaboration and proposed direction; early for deployment, standardization, and site-by-site adoption. The practical idea is simple: let legitimate humans and authorized agents prove low-risk access without forcing a login, CAPTCHA, or trackable fingerprint on every visit.

What changed
Cloudflare announced PACT on June 22, 2026 with Mozilla Firefox, Google Chrome, Microsoft Edge, and Shopify named in the collaboration. The group plans to develop and submit a privacy-preserving protocol that helps sites separate normal traffic from abusive automation.
PACT is not a browser switch users can enable today. It is a standards-track direction for anonymous tokens that can tell a site a visitor is within an acceptable rate limit without exposing identity, browsing history, or the original source of trust.
Mozilla's technical explainer frames the core problem sharply: privacy defenses and AI-era automation both make older anti-abuse signals weaker. Sites respond with CAPTCHAs, registration walls, VPN blocks, or tracking-heavy checks. PACT tries to keep abuse controls useful without turning normal browsing into identity disclosure.
Key takeaways
- PACT is designed to prove legitimate access with anonymous credentials, not a persistent user ID.
- The proposal targets both human visitors and agents acting on behalf of a user.
- Cloudflare says the initiative is being developed with major browser and commerce stakeholders.
- Mozilla describes the technical shape as Anchors, Moderators, endorsements, and credentials built around Privacy Pass-style cryptography.
- Deployment details, browser UX, acceptance rules, and standardization timing are still unresolved.
| Surface | Best fit | Status | Caveat |
|---|---|---|---|
| PACT tokens | Reducing CAPTCHA and login friction for legitimate traffic | Proposed protocol direction | Not broadly deployed yet |
| Anchors | Sources of scarcity such as accounts, subscriptions, or other trusted relationships | Design concept | Issuer choice can create gatekeeper risk |
| Moderators | Rate-limit policy and credential updates for one or more sites | Design concept | Needs privacy-safe aggregate abuse scoring |
| Existing CAPTCHAs/logins | Fallback when no credential exists | Available today | High friction and weaker against modern bots |
Availability and access
There is no general PACT rollout date to plug into a production roadmap yet. Cloudflare says the collaborators intend to submit the protocol for standardization, while Mozilla says draft specifications should go to the IETF for cryptographic pieces and the W3C for the Web API surface when ready.
For site owners, PACT belongs in planning and policy review before it becomes an implementation ticket. Track browser support, Cloudflare product hooks, issuer and moderator options, and how the system handles privacy-sensitive users such as VPN users, private browsing users, and logged-out shoppers.
Practical LinkLoot angle
PACT matters because every site owner is being squeezed from both sides: automated abuse is rising, and users are less willing to trade identity for access. The useful move is to map where your current defenses create the most friction before this protocol reaches production.
For commerce teams, start with checkout, account creation, coupon abuse, inventory scraping, and gift-card flows. For publishers and SaaS apps, look at registration walls, comment spam, credential stuffing, rate limits, and support-form abuse. The best target is practical: keep legitimate traffic moving while making high-volume abuse expensive.
A simple readiness checklist:
- List every place where users see CAPTCHAs, forced login, or VPN blocks.
- Separate abuse controls for anonymous browsing, logged-in users, and automated agents.
- Document what data your current anti-abuse tools collect and whether it creates tracking risk.
- Decide which traffic you would classify as authorized agent activity rather than bot abuse.
- Watch for Cloudflare, browser, W3C, and IETF updates before changing customer-facing promises.
For AI-agent and automation planning, pair this with LinkLoot's guide to AI workflow automation. If browser agents become normal buyers or operators, site defenses need a way to distinguish delegated user activity from scraping or credential attacks.
What to verify before you act
Check whether Cloudflare publishes concrete product settings for PACT, not just the press announcement. A standards proposal is not the same as an available dashboard control.
Watch the Mozilla, W3C, and IETF follow-up work for privacy analysis, issuer rules, and Web API design. The hard parts are issuer trust, rate-limit updates, revocation, and avoiding a new cross-site fingerprint.
Review whether your current anti-abuse vendor supports privacy-preserving rate limits or depends on fingerprinting and forced identity. PACT may expose policy gaps before it replaces any tool.
Test customer-impact metrics before removing existing controls. Abuse rate, false positives, checkout abandonment, login completion, support tickets, and VPN/private-browser access all matter.
Source check
Confirmed by Cloudflare: PACT is a June 22, 2026 initiative with Mozilla Firefox, Google Chrome, Microsoft Edge, and Shopify to develop a privacy-preserving protocol for proving traffic is not malicious.
Confirmed by Mozilla: the design work uses anonymous credentials, Privacy Pass-style ideas, Anchors, Moderators, issuer blinding, and rate-limit credentials, with standardization work expected through IETF and W3C channels.
Independent context: TechRadar reports the same Cloudflare-browser collaboration and frames the user-facing goal as reducing intrusive verification while recognizing legitimate automated traffic.
Not as a broad production feature. It is a confirmed initiative and protocol direction, but deployment and standardization details are still early.
