Cloudflare shipped the ability to apply Access directly to a Worker, or to every Worker in an account, so applications are behind company login by default. The stated reason is the one keeping security teams awake: AI tooling means any employee can build an application and deploy it to the public Internet, accidentally exposing internal work or company data.
The implementation detail is what makes it a control rather than a setting. When Access is enabled on a Worker, Cloudflare enforces authentication before any request reaches application code, regardless of how the request arrived — custom domain, route, workers.dev subdomain or preview URL. Previously this was configured per hostname, so adding a new custom domain to a Worker meant updating the Access policy first or leaving that hostname reachable unauthenticated. Moving the boundary from the hostname to the deployment removes a failure mode that depended on someone remembering. Authenticated identity — email, name and groups — is then available in code without JWT validation.
Enforcing before the request reaches application code is the same principle as agent security moving outside the model and as Cloudflare's network enforcement layer for MCP: the check belongs in the path, not in the thing being protected. The agent security hub tracks where those checks sit.
This is a product announcement describing the new default and its coverage, without published adoption data or a review of preview-URL edge cases. The condition to watch is whether account-wide Access reports which Workers are exempt, because a default that can be individually overridden needs an inventory of the overrides.