Cloudflare Workers can now be locked down with Access in one click!

Hey everyone, it's Shii! Today Cloudflare shipped a feature that helps stop the classic mistake of accidentally leaving an internal Worker open to the public, so let me walk you through it!

Cloudflare Blog blog.cloudflare.com

What was announced?

Cloudflare Blog announced "Cloudflare Access for Workers." You can now attach an Access policy directly to a Worker, and that policy automatically applies everywhere the Worker runs: custom domains, routes, the workers.dev subdomain, and preview URLs.

The motivation behind this is that as AI-assisted coding makes it faster than ever to build apps, the risk grows that developers accidentally expose internal data to the public internet.

The story so far

Workers can be reached through several different entry points: custom domains, routes, the workers.dev subdomain, and preview URLs. Until now, you had to think about access control for each of those entry points separately, and if you forgot to configure even one of them, a Worker that was only meant for internal use could end up sitting on the open internet.

What changes

With Cloudflare Access for Workers, you can now set policies at two levels:

• Account level: require your company login by default for every Worker, both the ones running today and any you deploy in the future. You can choose to protect just preview URLs, or production traffic too
• Single-Worker level: attach a policy to a specific Worker, and authentication becomes required no matter which domain it's accessed through

If you use Workers for Platforms, attaching an Access policy to the dispatch Worker makes every Worker running on that platform private by default. Being able to protect a whole fleet of Workers from a single platform-level setting is a huge win operationally.

Dive Deep

There's a clear precedence order for when multiple policies overlap: hostname-level policy, then Worker-level policy, then account-level policy. The more specific rule wins, which keeps the logic simple.

On the code side, you can now read the authenticated user's identity without verifying a JWT yourself.

const identity = await ctx.access.getIdentity();

That gives you the user's email, name, and group membership, which makes it easy to write logic that changes behavior or checks permissions per user.

Even in local development, you can add an Access block to your wrangler.jsonc and test how the Worker behaves for different users before you ever deploy.

On the authentication side, you can integrate with your existing identity provider, restrict access by specific email addresses, domains, or groups, and grant access to agents through service tokens.

Under the hood, this is powered by FL2, a new Rust-based modular proxy. By separating a Worker's routing logic from its execution phase, Access can now see which Worker a request is actually headed for.

Wrap-up

• You can now attach an Access policy directly to a Worker
• Protection automatically covers custom domains, routes, workers.dev, and preview URLs
• Policies can be set at the account level or per Worker, with hostname > Worker > account precedence
• ctx.access.getIdentity() gives you user identity without manual JWT verification
• With Workers for Platforms, one dispatch-Worker setting locks down every Worker underneath it

If you're spinning up internal tools or admin dashboards on Workers, especially while shipping apps fast with AI assistance, this is a reassuring way to avoid an accidental public exposure!