Cloudflare adds one-click access controls for Workers apps

Cloudflare has introduced new controls that put applications built on its Workers platform behind authentication by default. The change is aimed at organizations where employees can rapidly create and deploy “vibe-coded” tools, but may accidentally expose internal projects or data. CloudFlare announced the update in a company blog post.

Teams can now apply Cloudflare Access to an individual Worker or enforce it across an entire account. Account-level policies can cover preview traffic, production traffic, or both, ensuring that current and future Workers require a company login unless an administrator explicitly makes one public.

Protection follows the application

The policy is attached to the Worker rather than a hostname. That means custom domains, routes, workers.dev subdomains, and preview URLs are protected automatically. Developers no longer need to update separate Access rules whenever they add a domain or deploy a new preview.

Administrators can connect an existing identity provider or limit access by email address, domain, or group. Service tokens are also available for agents, which could help teams secure automated workflows and internal AI applications.

The update also simplifies application development. Authenticated request identity is exposed through ctx.access.getIdentity(), providing a user’s email, name, and groups without requiring developers to parse and validate a JWT themselves. Cloudflare provides a local-development configuration for wrangler dev, allowing teams to test simulated identities before deployment.

For AI builders, the practical benefit is a safer default: fast internal prototypes can remain private even when their creators overlook security configuration. Cloudflare has also open-sourced an example internal platform where every deployed Worker is private by default.

Source: CloudFlare