Cloudflare’s Access for Workers Turns Vibe-Coded Apps Into a Zero Trust Default

Cloudflare wants to close a gap that AI-assisted coding tools have been quietly opening across corporate networks: internal applications that get built in minutes and left reachable by anyone on the open internet. On August 14, 2026, Cloudflare engineers Chythra Malapati, Matt Rothenberg, and Matt Provost announced Access for Workers, a feature that lets a team attach a zero trust authentication policy directly to a Cloudflare Worker rather than to the hostname it happens to be running on.

The framing is deliberate. Cloudflare’s own announcement is built around the risk of “vibe coding,” the now widely used term for building software by describing what you want to a large language model rather than writing the code by hand. The post states plainly that “any employee can build an application, deploy it to the public Internet, and accidentally expose internal work or company data.” That is not a hypothetical. Independent research published months before Cloudflare’s announcement had already measured how often it happens.

What Vibe Coding Has Already Exposed

In May 2026, Israeli cybersecurity firm RedAccess scanned roughly 380,000 applications built on AI app-building platforms including Lovable, Base44, Replit, and Netlify. About 5,000 of them were leaking sensitive corporate or personal data at the moment the scan caught them, according to reporting by Axios, which independently verified several of the exposed apps before RedAccess’s findings were published. RedAccess CEO Dor Zvi told Axios his team found the apps while researching “shadow AI,” the unauthorized use of AI tools inside companies, on behalf of customers.

The specific exposures Axios confirmed included a shipping company’s app detailing which vessels were expected at which ports, an internal tool at a healthcare company that tracked active clinical trials across the United Kingdom, unredacted customer service conversations for a UK cabinet supplier, and internal financial information for a Brazilian bank. RedAccess also found phishing pages built on Lovable that impersonated Bank of America, FedEx, Trader Joe’s, and McDonald’s, hosted without needing to bypass any platform guardrail, since anyone can publish a project on these tools by default.

Zvi’s diagnosis of the root cause matches Cloudflare’s own framing almost exactly: several of the major AI app-building platforms make new projects publicly accessible unless the builder manually flips a setting to private, and the people building these tools rarely have the security background to know that setting exists. “I don’t think it’s feasible to educate the whole world around security,” Zvi told Axios. Replit, Lovable, and Wix, which owns Base44, each disputed parts of RedAccess’s methodology when Axios asked for comment. Replit’s CEO said publicly accessible apps are expected behavior and that privacy settings can be changed with a single click, while also saying RedAccess gave the company only 24 hours’ notice before going to the press. A Wix spokesperson said a publicly accessible app is not, by itself, evidence of a breach or a platform flaw, and that two of the flagged apps had been deliberately set to public by their owners. Lovable said the report it received lacked the URLs and technical detail needed to investigate the claims. None of the four platforms RedAccess studied are made by Cloudflare, but the underlying pattern, software shipped public by default and faster than the controls meant to govern it, is the same one Cloudflare is now targeting inside its own developer platform.

Why Hostname-Based Access Stopped Fitting the Job

Cloudflare Access has offered zero trust authentication for years as part of Cloudflare One, the company’s umbrella product for Zero Trust and SASE tools. Per Cloudflare’s own documentation, every Access policy is built from a combination of actions (allow, block, bypass, or service auth) and rule types (include, exclude, or require) that get evaluated against a hostname. That model works well when a security team configures access for a known, relatively stable list of internal domains.

It fits far less well when one non-engineer can spin up a new Worker that is simultaneously reachable through a custom domain, a default workers.dev subdomain, and a fresh preview URL generated for every deployment, often before a security team even knows the project exists. Under the old model, someone had to attach a policy to each of those hostnames individually. Miss one, and the app stays exposed through it regardless.

How Access for Workers Closes the Gap

A Policy Attached to the Worker, Not the Address

Access for Workers moves where enforcement happens. Instead of protecting a hostname, a team now attaches the policy to the Worker itself, so every domain, subdomain, and preview URL associated with that Worker is covered automatically, with no per-hostname setup required. Cloudflare says the feature is available now to all customers through the dashboard, with no beta period or separate pricing tier mentioned in the announcement.

Two Ways to Turn It On

Organizations can apply the protection in two ways. A single Worker can be protected on its own, useful for locking down one sensitive internal tool without touching anything else. Alternatively, an organization can set an account-wide policy that makes all Workers private by default, with the option to scope that default to preview URLs only or to every hostname a Worker touches. For teams using Workers for Platforms, Cloudflare’s product for building multi-tenant platforms on top of Workers, setting Access on the dispatch Worker automatically extends the same protection to every Worker deployed inside that platform’s namespace.

Reading Identity Without Hand-Rolled JWT Checks

Once a Worker is protected, its code can read who is making the request. Developers call ctx.access.getIdentity() to retrieve the authenticated user’s email, name, and group membership, without writing custom logic to validate a JSON Web Token by hand. For local development, a project’s wrangler.jsonc configuration file can simulate a specific authenticated identity, so a developer can test access-gated behavior before ever deploying.

Cloudflare credits the underlying flexibility to FL2, the company’s “Rust-based modular proxy” that separates how a Worker is routed from how it is executed. That separation is what lets Access target an individual Worker instead of being limited to matching on hostname, the constraint that shaped the product’s design for years.

What This Fixes, and What It Doesn’t

Access for Workers only changes the default for applications built on Cloudflare’s own platform, and even there, per-Worker protection still has to be turned on unless an organization opts into the account-wide private default. It does nothing for the no-code and low-code platforms named in RedAccess’s research: Lovable, Base44, Replit, and Netlify are separate companies with their own default settings to fix, or defend, on their own terms. It also can’t retroactively secure a Worker that was already indexed by a search engine while it sat open; Cloudflare’s change affects what happens next, not what has already leaked.

What it does address is the specific failure mode both Cloudflare and RedAccess describe: a workflow fast enough that access control becomes an afterthought, if anyone remembers it at all. Cloudflare has spent much of 2026 building similar guardrails around AI-accelerated development elsewhere in its platform, including a temporary Wrangler deployment flow announced in June that lets AI agents ship Workers without needing standing credentials of their own. Access for Workers extends that same instinct to a more mundane but far more common scenario: the internal tool an employee built over a lunch break that nobody thought to tell “no visitors.”