Cloudflare Adds Accountless Email Authentication to Quick Tunnels

Cloudflare Adds Accountless Email Authentication to Quick Tunnels Cloudflare has introduced protected Quick Tunnels in cloudflared, allowing developers and coding agents to secure temporary public tunnels using one-time email PINs without requiring a Cloudflare account or configuration dashboard. Quick Tunnels now support the `--allowed-mail` flag in cloudflared (starting in version 2026.9.3) and wrangler to restrict access to specified email addresses or wildcard domains. Authentication is handled via Cloudflare Access email PINs, but authorization occurs locally inside cloudflared, ensuring allowed email lists never leave the developer's machine. The feature requires no Cloudflare account for either the host or the visitor and remains free to use. Unauthenticated requests are blocked before reaching local services, and tunnels refuse to start if authentication mode cannot be confirmed, preventing accidental public exposure. Agentic Workflows and Exposure Risks Quick Tunnels provide an instant route from a local development port to a random `trycloudflare.com` URL without accounts or setup, making them widely adopted by automated coding agents. However, public URLs expose work-in-progress applications to anyone with the link. The new protection flag allows humans and automated agents to restrict access directly via CLI arguments or agent instruction files like `AGENTS.md`. CLI Usage and Integration Developers specify access rules by appending `--allowed-mail` with an address or wildcard domain (such as `'*@example.com'`) to `cloudflared tunnel` or `npx wrangler tunnel quick-start`. Access ceases immediately when the process terminates. If richer identity provider policies or persistent hostnames are required, standard Cloudflare Tunnel with Access or Cloudflare Mesh should be used instead. Architectural Separation of Auth and Guest Lists To protect privacy without creating account-bound Access policies for ephemeral tunnels, Cloudflare decoupled identity verification from access control. Cloudflare Access verifies email ownership via one-time PINs, and a stateless broker running on Cloudflare Workers produces a signed handoff. Local `cloudflared` instances then evaluate the visitor's verified identity against the memory-resident guest list, stripping authentication credentials before proxying traffic.

Cloudflare 为 Quick Tunnels 推出基于邮箱验证的免账户访问保护 Cloudflare 在 Quick Tunnels 中新增了受保护模式，开发者无需 Cloudflare 账户或域名，仅需添加单个参数即可通过邮箱一次性验证码限制本地开发服务的访问权限，特别适用于 AI Agent 等自动化工作流。 自 cloudflared 2026.9.3 起，通过 `--allowed-mail` 参数即可限制访问者邮箱或域名，访客需通过 Cloudflare Access 发送的一次性 PIN 验证身份。 整个流程双向均无需 Cloudflare 账户，允许的邮箱名单完全保留在本地内存中，Cloudflare 平台不会获取具体访客白名单。 架构上将认证与授权解耦：Cloudflare Access 负责验证邮箱所有权，本地 cloudflared 负责根据用户设置的规则进行授权判定。 该功能免费提供，同时也已集成进最新版本的 Wrangler CLI 工具中。 功能背景与 Agent 工作流适配 Quick Tunnels 最初用于将本地端口快速映射至公网 URL。随着 AI 编程 Agent 的普及，Agent 频繁自动启动隧道以展示成果或提供 MCP 接口，但传统公共隧道存在公开泄露敏感信息或半成品项目的风险。新版本允许人类或 Agent 在命令行中直接添加 `--allowed-mail`，实现仅对特定邮箱开放，同时保持无需注册账户、无需配置文件的轻量特性。 使用方式与控制逻辑 用户可多次声明 `--allowed-mail` 参数或使用通配符（如 `*@example.com`）指定允许访问的群体，若省略该参数则隧道仍为公开模式。通过 Wrangler 也可以直接调用此能力。访客打开链接时需在 Cloudflare Access 页面输入邮箱及收到的 PIN 码。一旦本地 cloudflared 进程退出，所有访问权限随即终止；若需要静态域名或更复杂的 IdP 规则，则建议迁移至完整版 Cloudflare Tunnel。 认证与授权解耦的隐私架构设计 为了解决免账户体系下白名单存放和海量临时隧道的扩展问题，Cloudflare 拆分了认证与授权。运行在 Cloudflare Workers 上的无状态中介服务结合 Cloudflare Access 验证访客确实拥有该邮箱，并生成短期签名凭证；本地的 cloudflared 负责在内存中比对签名凭证与用户指定的规则，决定是否放行。这确保了访客名单永远不会上传至 Cloudflare 服务端，同时在转发至本地服务前会剔除认证凭据。

We launched [Quick Tunnels](https://blog.cloudflare.com/quick-tunnels-anytime-anywhere/) in 2021 to give developers an easy way to share their latest service, application, or project running in their local development environment. A lot has changed since then, but the core use case remains the same. Your coding agent has just finished the feature. The dev server is up on `localhost:5173`, and before you ask, the agent offers to let you try it on your phone. It runs one command and hands you a link: `cloudflared tunnel --url http://localhost:5173` That command starts a [Quick Tunnel](https://developers.cloudflare.com/tunnel/get-started/quick-tunnels/). `cloudflared`, Cloudflare's lightweight connector, publishes your local service at a random `trycloudflare.com` URL. No account, no domain, no cost. Agents now use Quick Tunnels for the same reason people do: they are the shortest path from a local port to a URL. The catch has always been the same. Anyone with the link can open it. Starting with `cloudflared` 2026.9.3, you can add `--allowed-mail` to the command, and your Quick Tunnel only lets in the email addresses and domains you choose. Visitors prove they own one of those addresses with a one-time PIN from [Cloudflare Access](https://www.cloudflare.com/sase/products/access/). Nobody, on either side, needs a Cloudflare account. Agents that write code need somewhere to show you the result. Agents that live on a Mac mini at home need to be reachable from your phone. Model Context Protocol servers on a laptop need a public endpoint before a hosted assistant can call them. Each of these needs a URL, and a Quick Tunnel produces one from a single command an agent can run by itself. There is no signup form for it to get stuck on. Add `--` and every log line becomes a JSON object, so the agent can pick out the URL without scraping text.[output json](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/run-parameters/#output) Since agents took off, Cloudflare Tunnel and Quick Tunnels adoption has grown exponentially. On September 18, 2026, a link to the Quick Tunnels page climbed to the top of [Hacker News](https://news.ycombinator.com/item?id=49754785) and gathered more than 800 points and 300 comments. The thread reads like a catalog of agent workflows. One person's AI had found Quick Tunnels on its own to publish a site it had just built. Another called them "insanely helpful when doing agentic work on the go." And one [commenter](https://news.ycombinator.com/item?id=49756881) asked this post answers: *"how long until someone's agent sets up a tunnel for the world to see one's most sensitive, private and embarrassing information or insecure work-in-progress app?"* Pass an email address to `--allowed-mail`: ``` cloudflared tunnel --url http://localhost:8080 \ --allowed-mail alice@example.com ``` Alice opens the URL, enters her email address, types in the code sent to her inbox, and reaches your app. Anyone else is stopped before a single request reaches your machine. You still don't create a DNS record, write a configuration file, or open a dashboard. To let in more people, repeat the flag or allow an entire domain: ``` cloudflared tunnel --url http://localhost:8080 \ --allowed-mail alice@example.com \ --allowed-mail bob@example.com \ --allowed-mail '*@example.com' ``` If you leave out `--allowed-mail`, nothing changes. Public Quick Tunnels behave exactly as they always have. To change who can get in, stop `cloudflared` and start a new tunnel. Access ends for everyone the moment the process exits. For a stable hostname or richer rules, such as identity provider groups, use [Cloudflare Tunnel](https://developers.cloudflare.com/tunnel/get-started/) with Cloudflare Access. To reach an agent at home from your own devices without any public URL and establish bidirectional connectivity, use [Cloudflare Mesh](https://blog.cloudflare.com/mesh/). Because protection is a single flag, agents can use it as easily as people can. Add one line to the instructions file your coding agent reads, such as `AGENTS.md`: `When you start a Quick Tunnel, always add --allowed-mail me@example.com.` From then on, the previews your agent shares should open only for you. Agents don't always follow instructions, so check what it ran: `cloudflared` prints whether a tunnel uses email authentication and how many rules it holds, without printing the addresses. If you build on Workers, you can start the same kind of tunnel from the latest version of `wrangler`: ``` npx wrangler tunnel quick-start http://localhost:8080 \ --allowed-mail alice@example.com ``` Wrangler supports repeated flags, comma-separated values, and wildcard domains, and it removes `--allowed-mail` values from its debug logs. When someone opens a protected URL, they land on the Cloudflare Access sign-in page. They enter their email address, then the one-time PIN sent to that mailbox. Email sign-in is built for people using a browser. That step answers one question only: does this person control this email address? It doesn't decide whether they're welcome. `cloudflared` makes that decision on your machine by comparing the verified address with the rules you typed. Separating those two questions is the core of the design. Authentication proves who a visitor is. Authorization decides whether that visitor gets in. Every Cloudflare product that enforces access rules keeps the authorization half in the same place: your Cloudflare account. A Quick Tunnel doesn't have one. So the hard part was never sending someone a code. It was deciding where the guest list should live. We started with four requirements. The design had to: Our first idea was to put a Cloudflare Access application in front of every Quick Tunnel hostname. Access already checks visitors before traffic reaches `cloudflared`, so reusing it looked like the shortest path. But hundreds of thousands of Quick Tunnels can be running at once, many for only a few minutes, and each would need its own application and policy. With no account to own them, we would have had to invent a new namespace and route applications dynamically, just to store a list that lives for an afternoon. Our second idea was to build the whole flow. `cloudflared` would hold the rules, and a Tunnel service would send and check the codes. The authorization half of this idea was good: each connector checks its own list, which scales naturally and keeps the rules on the developer's machine. The authentication half was not. Sending a code is the easy part of email login. The hard parts are getting email delivered, stopping abuse, building secure challenges, managing sessions, and serving a sign-in page that is accessible and translated, then operating all of it safely for years. Cloudflare Access has already solved those problems. So we kept the best half of each idea. Access verifies that the visitor controls the email address. A small authentication broker running on [Cloudflare Workers](https://www.cloudflare.com/products/workers/) turns that verified identity into a short-lived, signed handoff. The broker is stateless by design. It stores no tunnel policies, no visitor sessions, and no identity records, and it never sees a tunnel's guest list. `cloudflared` checks the handoff and makes the authorization decision itself, in memory, against the rules you typed. The result is the property we cared about most: your guest list never leaves your machine. Cloudflare learns that a tunnel requires email authentication. It doesn't learn who you invited. A protected tunnel is created the same accountless way as a public one. The only extra thing `cloudflared` sends is the authentication mode, never your rules. If the service doesn't confirm that mode, `cloudflared` refuses to start rather than hand you a public URL by mistake. The first time a visitor opens the URL: `cloudflared` sees a request with no session. It redirects the browser to `login.trycloudflare.com` with a random, single-use state tied to that browser and valid for 10 minutes. The session cookie holds a random value and an expiry time, and nothing about who the visitor is. `cloudflared` strips authentication credentials before forwarding requests, so your app never sees them and never has to implement a login flow. If any check fails, the request never reaches your local service. A protected tunnel never falls back to public mode. Protected Quick Tunnels were shipped by two interns: Hugo Vicente on product and Alessandro Frigerio on engineering. They took it from the product requirements to the authentication broker to the `cloudflared` release. That's how [internships](https://blog.cloudflare.com/cloudflare-1111-intern-program/) work at Cloudflare: interns own real problems and deliver solutions to production. Email protection for Quick Tunnels is free, like Quick Tunnels themselves. [Install or update](https://developers.cloudflare.com/tunnel/downloads/) `cloudflared`, start your local server, and add the `--allowed-mail` flag: `cloudflared tunnel --url http://localhost:8080 --allowed-mail you@example.com` Setup details, matching rules, and limits are in the [Quick Tunnels documentation](https://developers.cloudflare.com/tunnel/get-started/quick-tunnels/). The next time you or your agent shares what you're building, the link will only open for the people you chose.