Accountless tunnels meet access control
Quick Tunnels arrived in 2021 as a way to publish a service running in a local development environment. Since then the tooling around them has changed, but the workflow has not: cloudflared, Cloudflare's lightweight connector, exposes a local port at a random trycloudflare.com URL with no account, domain or cost.
The longstanding drawback is that anyone holding the link can open it. Starting with cloudflared 2026.9.3, the --allowed-mail flag restricts a Quick Tunnel to the email addresses and domains you specify. Visitors authenticate by entering a one-time PIN sent to their inbox through Cloudflare Access. Neither side needs a Cloudflare account.
Why agents pushed adoption
An agent that writes code needs a place to show the result, and a machine sitting at home needs to be reachable from a phone. Model Context Protocol servers on a laptop need a public endpoint before a hosted assistant can call them. A Quick Tunnel produces a URL from one command the agent can run unaided, with no signup form to stall on. With --output json, every log line becomes a JSON object the agent can parse instead of scraping text.
Adoption of Cloudflare Tunnel and Quick Tunnels has grown since agents became common. On September 18, 2026, a link to the Quick Tunnels page reached the top of Hacker News with more than 800 points and 300 comments, many describing agent workflows — including one AI that found Quick Tunnels on its own to publish a site it had built. A commenter in that thread asked the question this feature addresses: how long until an agent exposes sensitive or unfinished work to the world through a tunnel?
Configuring a protected tunnel
Pass an email address to the flag:
cloudflared tunnel --url http://localhost:8080 \
--allowed-mail [email protected]A visitor opens the URL, enters their address, types the code from their inbox and reaches the app. Everyone else is stopped before a single request reaches your machine, and no DNS record, configuration file or dashboard visit is involved. To admit more people, repeat the flag or allow a whole domain:
cloudflared tunnel --url http://localhost:8080 \
--allowed-mail [email protected] \
--allowed-mail [email protected] \
--allowed-mail '*@example.com'Omitting --allowed-mail changes nothing; public Quick Tunnels behave as before. Changing the guest list means stopping cloudflared and starting a new tunnel, and access ends for everyone when the process exits.
Stable hostnames or richer rules such as identity provider groups call for Cloudflare Tunnel with Cloudflare Access. Reaching an agent at home from your own devices, with no public URL and bidirectional connectivity, is a job for Cloudflare Mesh.
Agent defaults and Wrangler
Because protection is one flag, an agent can apply it as readily as a person. A single line in the instructions file your agent reads, such as AGENTS.md, is enough:
When you start a Quick Tunnel, always add --allowed-mail [email protected].Instructions are not always followed, so verify what ran: cloudflared prints whether a tunnel uses email authentication and how many rules it holds, without printing the addresses themselves.
Workers developers can start the same tunnel type from the latest wrangler:
npx wrangler tunnel quick-start http://localhost:8080 \
--allowed-mail [email protected]Wrangler accepts repeated flags, comma-separated values and wildcard domains, and it strips --allowed-mail values from debug logs.
Split responsibilities: verify, then decide
A protected URL sends visitors to the Cloudflare Access sign-in page, where they enter an address and then the one-time PIN delivered to that mailbox. Email sign-in targets browser users and answers exactly one question: does this person control this address? Admission is a separate matter, decided by cloudflared on your machine, which compares the verified address against the rules you supplied.
Where the policy lives
Authentication establishes identity; authorization decides admission. Every Cloudflare product enforcing access rules keeps the authorization half in your Cloudflare account — which a Quick Tunnel does not have. Sending a code was never the hard part; placing the guest list was. Four requirements shaped the design:
- Quick Tunnels had to stay accountless, since a signup step would defeat the one-command premise.
- The request path for public Quick Tunnels had to be untouched.
- There could be no central policy lookup on each request after sign-in.
- The email addresses developers type into their terminals had to stay private.
A Cloudflare Access application in front of every Quick Tunnel hostname was the first idea, since Access checks visitors before traffic reaches cloudflared. But hundreds of thousands of tunnels can run at once, many for mere minutes, and each would need its own application and policy — owned by no account, in a namespace that would have to be invented and routed dynamically to hold a list lasting an afternoon.
Building the flow in house was the second idea: cloudflared holds the rules, a Tunnel service sends and checks codes. The authorization half scaled well — each connector checks its own list, keeping rules on the developer's machine. The authentication half did not. Code delivery is the easy part of email login; email deliverability, abuse prevention, secure challenges, session management, and an accessible, translated sign-in page all have to be operated safely for years. Access already handles them.
The final design keeps the better half of each. Access verifies that the visitor controls the address. A small authentication broker on Cloudflare Workers converts that verified identity into a short-lived, signed handoff. The broker is stateless, storing no tunnel policies, visitor sessions or identity records, and it never sees a tunnel's guest list. cloudflared validates the handoff and authorizes in memory against your rules. Your guest list never leaves your machine; Cloudflare learns that a tunnel requires email authentication, not who was invited.
Request flow
A protected tunnel is created accountlessly, like a public one. The only extra data cloudflared sends is the authentication mode, never the rules, and if the service fails to confirm that mode, cloudflared refuses to start rather than hand out a public URL by mistake. On a visitor's first request:
cloudflaredsees a request with no session and redirects the browser tologin.trycloudflare.comwith a random, single-use state tied to that browser and valid for 10 minutes.- Cloudflare Access sends a one-time PIN to the visitor's email address and verifies it.
- The broker checks the Access identity and returns a short-lived, signed assertion bound to the tunnel hostname and to that state. The browser delivers it in a form POST, so it never lands in a URL, browser history, or logs.
cloudflaredverifies the assertion, consumes the state, and checks the email against your rules. A match creates a local session and forwards the visitor to the requested page; otherwise the visitor gets a generic response that reveals nothing about the list.- Later requests use that session for up to four hours (less if the visitor's Access sign-in expires first), or until you stop
cloudflared. No central lookup or policy service is involved.
The session cookie carries a random value and an expiry, nothing about the visitor's identity. Authentication credentials are stripped before requests are forwarded, so your app never sees them and needs no login flow. A failed check means the request never reaches your local service, and a protected tunnel never reverts to public mode.
Provenance and availability
Two interns shipped the feature: Hugo Vicente on product and Alessandro Frigerio on engineering, taking it from requirements through the authentication broker to the cloudflared release.
Email protection is free, like Quick Tunnels themselves. Install or update cloudflared, start your local server, and add the flag:
cloudflared tunnel --url http://localhost:8080 --allowed-mail [email protected]Setup details, matching rules and limits are documented under Quick Tunnels.
