What happened
Cloudflare Workers is the company’s platform for running app code without managing a server yourself, the kind of setup a coding agent reaches for by default when it deploys something for you. 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 exact failure mode of vibe coding an internal tool. 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 a policy at the account level so every Worker your team deploys, previews and production alike, requires login by default. 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. Cloudflare now hands you the visitor’s email, name, and group membership directly, so you skip writing and testing that verification code yourself.
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.
This closes that gap without asking the builder to remember anything mid-project. If your organization turns on the account-wide default, a new Worker is private the moment it goes live, before anyone has to configure login by hand.
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 it loads without asking you to sign in, it’s public right now, regardless of what you intended.
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. You should now be stopped at a login screen before the app itself ever loads.
That two-step test, check first, fix, check again, is worth doing for every internal tool you’ve already shipped, not just new ones. A feature like this only protects what you remember to point it at.
End of article