Protected Quick Tunnels Add Email Gatekeeping for Local Services

The problem with a link that anyone can open #

Developers often need to show a half-finished feature to someone else in seconds. A local dev server on a laptop is reachable only from that machine, so the fastest route is a temporary public URL. Cloudflare's Cloudflare Blog describes Quick Tunnels as the shortest path from a local port to a link, and that convenience has always carried one obvious risk: anyone who has the link can open it.

The source article frames the problem around coding agents. An agent that has just finished a feature may start a dev server and offer to share it, running a single command that returns a random public address. That workflow is useful, but it means a work-in-progress application can become reachable by people the developer never meant to invite. The article also notes that a commenter on a popular discussion thread asked how long it would take before someone's agent exposed sensitive or insecure work this way.

Before this change, the only protection was the secrecy of the URL. Quick Tunnels were designed to be accountless and fast, so adding an identity step had to avoid the friction that made them useful in the first place. The new flag tries to add access control without asking the developer to create an account, write a configuration file, or open a dashboard.

What changed in cloudflared 2026.9.3 #

The key change is a new option on the existing command. Starting with cloudflared 2026.9.3, a developer can add --allowed-mail to a Quick Tunnel. The tunnel then admits only the email addresses and domains listed. The source says visitors prove they control one of those addresses with a one-time PIN issued through Cloudflare Access, and neither side needs a Cloudflare account.

The article gives a concrete example. A developer runs cloudflared tunnel --url http://localhost:8080 --allowed-mail alice@example.com. Alice opens the generated URL, enters her email address, types the code sent to her inbox, and reaches the application. Anyone else is stopped before a request reaches the developer's machine. No DNS record or configuration file is required.

• Feature: a new --allowed-mail flag on Quick Tunnels, available starting with cloudflared 2026.9.3.
• Visitor verification: a one-time PIN delivered through Cloudflare Access to the visitor's mailbox.
• Accounts: neither the developer nor the visitor needs a Cloudflare account.
• Rule types: individual addresses, repeated flags for more addresses, whole domains, and wildcard domain patterns such as '*@example.com'.
• Default behaviour: without the flag, public Quick Tunnels behave exactly as before.
• Lifetime: access ends for everyone when the cloudflared process exits.
• Cost: the source describes email protection for Quick Tunnels as free, like Quick Tunnels themselves.

The rules are additive. The article says developers can repeat the flag to admit more people, or allow an entire domain. Because the guest list is tied to the running process, stopping cloudflared and starting a new tunnel is the way to change who gets in. For a stable hostname or richer policies, such as identity provider groups, the article points developers to Cloudflare Tunnel combined with Cloudflare Access instead.

Making protection the agent's default #

Because protection is a single flag, it can be added to the instructions that a coding agent reads when it starts work. The source suggests adding one line to an instructions file such as AGENTS.md, telling the agent to always include the flag with the developer's own address. After that, previews shared by the agent should open only for the developer.

The article also acknowledges that agents do not always follow instructions. For that reason, cloudflared prints whether a tunnel uses email authentication and how many rules it holds, without printing the addresses themselves. A developer can therefore check what the agent actually started without exposing the guest list in the terminal output.

The source also describes a Wrangler path. Developers building on Workers can run npx wrangler tunnel quick-start with the same kind of protection, using the latest version of Wrangler. The article states that Wrangler supports repeated flags, comma-separated values, and wildcard domains, and that it removes --allowed-mail values from its debug logs.

How the authentication flow separates identity from permission #

The most interesting part of the design is how the authors split two questions. Authentication asks who the visitor is. Authorization asks whether that visitor should be allowed in. The article argues that Cloudflare Access handles the first question, because it can confirm that a person controls an email address. The second question is answered by cloudflared on the developer's machine, by comparing the verified address with the rules typed on the command line.

The authors explain why they did not simply put a Cloudflare Access application in front of every Quick Tunnel hostname. Hundreds of thousands of Quick Tunnels can run at once, many only for a few minutes. Giving each one its own application and policy would require inventing a new namespace and routing applications dynamically, just to store a list that exists for a short period. They also considered having cloudflared handle the entire login flow, but rejected that because email delivery, abuse prevention, secure challenges, session handling, and an accessible sign-in page are hard to operate at scale. Cloudflare Access already provides those pieces.

The chosen design uses a small authentication broker running on Cloudflare Workers. The article says the broker is stateless. It stores no tunnel policies, no visitor sessions, and no identity records, and it never sees the guest list. It turns a verified identity into a short-lived, signed handoff. cloudflared checks that handoff and makes the authorization decision in memory. The result, as the article puts it, is that the guest list never leaves the developer's machine. Cloudflare learns that a tunnel requires email authentication, but it does not learn whom the developer invited.

What a visitor sees on each request #

The article walks through a first visit in some detail. When a visitor has no session, cloudflared redirects the browser to a Cloudflare login host with a random, single-use state value tied to that browser. That state is valid for 10 minutes. Cloudflare Access sends a one-time PIN to the visitor's email address and verifies it. The broker then returns a signed assertion bound to the tunnel hostname and to that state. The browser delivers the assertion in a form POST, so it does not appear in the URL, browser history, or logs.

cloudflared verifies the assertion, uses up the state so it cannot be reused, and checks the email against the developer's rules. On a match, cloudflared creates a local session and sends the visitor to the page they originally requested. If the check fails, the visitor receives a generic response that reveals nothing about the list. The article notes that a failed check means the request never reaches the local service.

Later requests use the local session for up to four hours, or less if the visitor's Access sign-in expires sooner. The session cookie holds a random value and an expiry time, and nothing about who the visitor is. The article also states that cloudflared removes authentication credentials before forwarding requests, so the developer's application never sees them and never has to implement its own login flow.

Why it matters #

The change matters because it removes a trade-off that developers previously faced. Before, the choice was between a fast public link with no access control and a heavier setup with accounts, domains, and configuration. The article presents email protection as a single flag that keeps the one-command workflow intact. That makes it more likely that developers will protect previews by default, which reduces the chance that a temporary tunnel exposes private or unfinished work.

The design also says something about how access control can be split across systems. The authentication step relies on an existing Cloudflare product, while the policy stays local. That keeps the Quick Tunnel accountless and avoids a central policy lookup on every request after sign-in. For teams that already use agents to start services, the flag provides a way to add a guardrail in the same instructions file that shapes everything else the agent does.

The limits are also clear from the source. Restricting access stops when the cloudflared process exits, and the feature is meant for temporary sharing rather than a stable production endpoint. Stable hostnames and group-based rules are described as a different product path. Anyone evaluating the feature should treat it as a quick and inexpensive gate for development previews, not as a replacement for a long-lived access policy.

Who is affected #

The most direct audience is developers who use Quick Tunnels to share local applications, dev servers, or Model Context Protocol servers running on a laptop. The source lists these use cases alongside agents that run on a home machine and need to be reachable from a phone. Those users can add --allowed-mail to their existing commands and keep the same workflow, provided they update to cloudflared 2026.9.3 or a version that includes the flag.

Teams that run coding agents are also affected, because the article recommends placing the protection rule in an instructions file the agent reads. Platform and security teams may want to review how agents start tunnels and whether the rule is applied consistently. The article's advice to check the cloudflared output for the authentication mode and rule count gives those teams a simple verification point.

Developers building on Workers are affected in a similar way, since the source describes the same protection through the latest version of Wrangler. Visitors to protected previews are affected as well. They will be asked to enter an email address and a one-time PIN before reaching the application, and the article notes that the sign-in step answers only whether they control that address, not whether they are welcome.

Takeaways #