The best part of a Quick Tunnel is also the worst part: anyone with the link gets in. Starting with cloudflared 2026.9.3, released October 2, 2026, Cloudflare lets you fix that with a single flag. Add —allowed-mail and your tunnel only admits the email addresses (or whole domains) you name, verified by a one-time PIN through Cloudflare Access. No account, no DNS record, no dashboard.
cloudflared tunnel --url localhost:5173 --allowed-mail you@example.com --allowed-mail @yourteam.devLeave the flag off and nothing changes. Stop the process and access ends for everyone.
Why this landed now
Quick Tunnels have quietly become the default way coding agents show you their work. A command the agent can run by itself produces a public URL — no signup form to get stuck on. —output json even turns logs into parseable objects so the agent can fish out the link without scraping text. Cloudflare notes that since agents took off, adoption has grown exponentially, and a Hacker News thread about Quick Tunnels hit over 800 points on September 18, 2026, full of agent workflows.
That same thread contained the objection this feature answers: how long until an agent publishes your sensitive files or an insecure work-in-progress app to the whole internet? With a public URL and no gate, the answer was “any minute.” Now the gate is one flag the agent can set itself.
Making it the default
Because protection is just a flag, the obvious move is to put it in the instructions file your coding agent reads, like AGENTS.md, so every shared preview opens only for you. Agents don’t always follow instructions, so verify: cloudflared prints whether a tunnel uses email authentication and how many rules it holds — without echoing the addresses. Wrangler supports the same flag for Workers developers, including repeated flags, comma-separated values, and wildcard domains, and it scrubs —allowed-mail values from debug logs.
This fits the pattern from Cloudflare’s agent-facing security work: build the guardrail into the step the agent already takes, rather than hoping it remembers an extra procedure.
The interesting design choice: authorization lives on your machine
The deeper question Cloudflare had to solve was where the guest list lives when there’s no account to store it. Their answer splits authentication from authorization. Cloudflare Access proves a visitor controls an email address; a stateless authentication broker on Workers turns that into a short-lived signed assertion; then cloudflared itself checks the address against the rules you typed, in memory.
The consequence is worth understanding: your guest list never leaves your machine. Cloudflare learns that a tunnel requires email authentication — it never learns who you invited. Sessions last up to four hours, the cookie holds no identity data, credentials are stripped before requests reach your app, and a failed check returns a generic response that reveals nothing about the list. A protected tunnel never falls back to public mode; if the service doesn’t confirm the auth mode, cloudflared refuses to start.
Know the limits
Email sign-in answers exactly one question: does this visitor control this address? If someone forwards you the PIN, they’re in. For stable hostnames or rules tied to identity provider groups, you still want Cloudflare Tunnel with Access; for private device-to-agent connectivity, Cloudflare Mesh is the better fit. It’s also worth reading how stateful login history becomes investigative evidence once you move to account-backed flows.
Practical next step: add the —allowed-mail line to your agent’s instructions file today, and check its output the first time it shares a link. The feature is free, shipped by two Cloudflare interns, and costs you exactly one flag.