本地 demo 分享這件事，最近被兩股力量同時推著走。一方面，coding agent 越來越常主動替你開一條通道，把手上的 localhost 服務變成一條可以點開的連結；另一方面，那條連結的問題從 2021 年 Quick Tunnels 推出以來就沒變過——任何人拿到網址都能打開。
2026 年 10 月 2 日，Cloudflare 在部落格上發表了 Protected Quick Tunnels，試著用最小的改動回答這個老問題。
一個 flag 改變的事
從 cloudflared 2026.9.3 開始，指令加上 --allowed-mail，Quick Tunnel 就只允許你指定的 email 地址或網域進來。訪客透過 Cloudflare Access 收一次性 PIN 驗證信箱所有權，兩邊都不需要 Cloudflare 帳號。不加這個 flag，行為和以前完全一樣。
對 builder 來說，這個設計聰明在於成本幾乎為零。沒有 DNS 紀錄、沒有設定檔、沒有 dashboard 要開。想換名單？停掉 cloudflared 重新啟動一條 tunnel 就好，程序一退出，所有人的 Access 立刻失效。對 demo 這種「活一個下午」的場景，這種一次性正好。
為什麼是 agent 把這件事推到前台
Cloudflare 在文中指出，自從 agent 興起，Cloudflare Tunnel 和 Quick Tunnels 的採用以指數速度成長。原因不難理解：agent 寫完程式需要一個網址給你看結果、跑在家裡 Mac mini 上的 agent 需要能從手機連到、筆電上的 MCP server 需要一個公開 endpoint 讓 hosted assistant 呼叫。Quick Tunnel 一條指令就給出網址，沒有註冊表單可以卡住 agent，加上 --output json 後 agent 甚至不用刮文字就能抓到 URL。
但熱門伴隨風險。文中引用 Hacker News 上一則留言的擔憂：什麼時候會有某人的 agent 替全世界開了一條通往最私密、最不安全半成品的通道？--allowed-mail 本質上就是把這個風險的預設解答往前推一步。
名單存在哪裡：設計上值得學的一課
這篇公告裡對 builder 最有參考價值的，其實是「沒有帳號時，政策放哪裡」這段設計取捨。Cloudflare 評估過兩個方案：在每個 Quick Tunnel 前面掛一個 Access application（但數十萬條短命 tunnel 各自需要政策，管理成本不划算），或讓 cloudflared 自建整套 email 驗證（寄信、防濫用、session、無障礙登入頁，這些 Access 早已解決的問題全部重做）。
最終方案是各取一半：Access 負責驗證信箱所有權，一個跑在 Workers 上的無狀態 broker 把驗證結果變成短時效的簽名交接，cloudflared 在你自己的機器上、在記憶體裡比對名單。結果是一個乾淨的性質：你的訪客名單永遠不離開你的機器，Cloudflare 只知道這條 tunnel 需要 email 驗證，不知道你邀請了誰。
這種「驗證與授權分層、授權留在本地」的思路，和我在 Cloudflare 把 Enterprise 級功能下放到免費用戶 一文裡觀察到的方向一致：把原本綁在帳號或付費層級的能力，重新切成可以獨立存在的最小單位。
實務上要記住的幾個限制
幾點先講清楚，免得期待錯位。這套機制只回答「這個人是否控制這個信箱」，不回答「這個人是否受歡迎」——判斷完全是字串比對。session 最長四小時，之後要重新驗證。如果需要固定 hostname、IdP 群組這類更豐富的規則，Cloudflare 的建議仍是改用完整的 Cloudflare Tunnel 加 Access。
另外，agent 不一定照指示辦事。Cloudflare 建議把 --allowed-mail 寫進 AGENTS.md 之餘，也檢查 agent 實際跑的指令——cloudflared 會印出 tunnel 是否啟用 email 驗證和規則數量，但不會印出地址。順帶一提，這個功能由兩位實習生從產品需求一路做到正式發布，也算替「實習生能交付 production」提供了一個具體樣本。
下一個 demo 之前，更新 cloudflared、加一個 flag，就夠了。