What happened
Cloudflare Workers runs app code without requiring you to manage a server. Cloudflare just made it possible to put every Worker behind your company login automatically, instead of relying on each person who builds one to add that protection themselves.
The feature is called Access for Workers, and Cloudflare frames the problem it solves directly: “any employee can build an application, deploy it to the public Internet, and accidentally expose internal work or company data.” That’s the risk when someone quickly builds an internal tool with an AI agent and deploys it before adding access controls. It’s quick to build and quick to ship, and nothing stops it from being reachable by anyone on the internet unless someone remembers to lock it down.
You can now apply Cloudflare Access, the company’s login-gate product, in one of two ways. Set an account-level policy for previews alone, or for both preview and production deployments. Check more specific app or hostname policies, which take precedence. Or set a policy on one specific app so it stays protected no matter which domain or URL it’s reached through. Once it’s on, Cloudflare checks the login before a request ever reaches your app’s code, not after.
The feature also removes a step developers used to have to build themselves. Getting a signed-in user’s identity into your code usually means validating a JWT (JSON Web Token), a piece of proof a login system hands you to confirm who’s asking. For directly authenticated Worker requests, ctx.access can provide identity without extra token parsing. App permissions still need testing.
Current documentation notes that this identity context does not pass through service bindings or static-assets routers. Those paths need separate handling.
Why it matters
The risk here isn’t hypothetical. An AI coding agent can spin up a working internal dashboard, an admin tool, or a data viewer in minutes. None of those are things you’d want a stranger to find, but “deployed” and “protected” aren’t the same thing, and a tool built fast is easy to ship before you’ve thought about who else can see it.
Account-wide defaults reduce the chance of publishing an internal Worker without login controls. Confirm production coverage and any overriding policies.
Who should care
This matters most if you or your team deploy internal tools on Cloudflare Workers, things meant for your own use, not the public: an admin panel, a data lookup tool, an internal API. If what you’re building is meant to be public, like a customer-facing site or app, this feature isn’t the fix you need, since blocking it with a login defeats the point.
It also matters if you manage a Cloudflare account for other people, since the account-level policy is the piece that protects everyone under you by default, not just the app you personally remembered to lock down.
What builders should do next
If you’re on Cloudflare Workers, don’t assume anything you’ve already deployed is private just because it “feels internal.” Check it directly: open the URL for any internal tool you’ve shipped in a private or incognito browser window, logged out of everything. If internal data or privileged actions are available without sign-in, investigate the access policy. A public page shell alone does not prove private data is exposed.
To fix that, turn on Access from the Cloudflare dashboard, under your account’s Workers & Pages settings, either as an account-wide default covering every current and future Worker, or on the specific app you just tested. Cloudflare’s documentation walks through both. After you turn it on, repeat the same logged-out check. Confirm unauthenticated visitors cannot access the internal data or actions, including through alternate app URLs.
Check existing internal tools as well as new ones. Also verify that an authenticated user has only the permissions their role needs.
End of article