摘要： Cloudflare 在 2026 年 11 月 5 日由 Bryan Becker 發表的文章指出，遠端託管的 AI Agent（例如 Meta 的 Muse、OpenAI 的 dots）正在成為使用者和網站之間的新中介層，讓網站失去辨識、服務與問責使用者的能力。文章提出的核心主張是 Intermediation Principle：無論經過什麼中介，使用者與網站之間的業務關係和各方安全責任都必須被保留。對做 Agent 產品的人來說，這直接影響你的產品能不能被網站放行、出了糾紛誰承擔成本。
網站看到的是 Agent，不是使用者
文章定義的「Personal AI Agent」是接收人類指令、透過控制雲端電腦或瀏覽器來達成目標的自動化程式，通常由一個 Operator 以受管服務的形式託管。關鍵結構在於：Agent 是中介者。網站本來直接看到使用者，現在只看到 Agent，而且一個 Agent 可能同時代表多個使用者行事。
這不是全新的問題——雲端瀏覽器和 VPN 早就都是中介者，網站過去的對策很簡單：擋掉。但 Cloudflare 的判斷是，agentic traffic 增長很快，可能在不遠的將來超過傳統的人類瀏覽流量。等到大部分流量都是 Agent，封鎖就不再是可行的選項，網站被迫在缺少使用者資訊的情況下決定要不要信任中介者。
要理解這個問題，傳統安全與反詐欺體系依賴三樣東西：Identity（對方是否如實宣稱自己是誰）、Reputation（這個人可不可信）、Accountability（出了事誰負責）。Device fingerprint、session、瀏覽歷史這些訊號，原本就是為了回答這三個問題而存在的——而遠端 Agent 恰好把它們全部切斷。
Ezra 的比喻：一個助理帶來的四種麻煩
Cloudflare 用一個助理的比喻把問題講得非常具體。Ezra 為 Amy、Bob、Charlie、Debra 四個人跑腿買東西。
雜貨店老闆原本認得 Amy，知道她的偏好；現在只看到 Ezra 一個人替四個人採購，分不清誰要什麼——這對應網站上的 account sharing 與 user attribution 問題：一個訂閱被多個使用者共用、個人化和忠誠度計畫失去依據。Bob 買了 iPhone 之後否認授權、留下貨品（friendly fraud），商店要贏得爭議得證明是 Bob 本人下的單，但它從頭到尾只見過 Ezra——Agent 的購買來自 Agent 的基礎設施，過去那套「同一台裝置、同一個 IP」的間接證據不存在了。Charlie 交給 Ezra 一堆密碼去銀行試，銀行看得出攻擊正在發生，唯一能封鎖的對象卻是 Ezra，而封鎖 Ezra 等於連 Amy、Bob、Debra 一起封掉——這是 traffic commingling。
文章列出的挑戰清單還包括：合規與年齡地域限制無法驗證、liveness 和 KYC 檢查假設「在場的人就是要驗證的人」而失效、攻擊者抄襲知名 Agent 的 user agent string 冒充身份、實驗性 Agent 下錯單的 misalignment 成本由網站吸收、Agent 持續輪詢耗盡免費額度、還有 Agent 讀走內容卻不帶來任何 visit、ad impression 或購買的 uncompensated consumption。文章的總結很直白：在幾乎每一項挑戰裡，承擔主要成本的都是網站本身。
CAPTCHA 為什麼不是答案
一個常見提議是讓 Agent 把 CAPTCHA 轉交給使用者去解。Cloudflare 認為這頂多證明當下有個人類在場（human in the loop），解決的只是 misalignment——也就是 Agent 替使用者做出錯誤動作的問題。它分不出 Bob 和其他人，也說明不了其餘時間這個 Agent 在替誰行事。
更麻煩的是激勵結構：Agent 產品存在的目的就是移除摩擦，HITL 卻把摩擦加回來，所以 Operator 有充分的動機繞過或移除它。這是一個真正的 trade-off——你把多少操作交還給使用者確認，直接決定你的 Agent 產品在網站眼中是更可信還是更可疑，同時也決定你的使用者體驗。文章還提到，使用者過去可以用私密瀏覽模式保護隱私，Agent 理論上也應該享有同等待遇，但代價是它大概無法在沒有額外驗證的情況下登入銀行。
需要說明的是：我取得的原文在討論另一個提議——「tightly scoped access」開頭之處被截斷，後續內容未能取得，所以 Cloudflare 完整的技術方案是什麼，這篇文章無法證實。目前能確認的是它提出的原則，而不是任何已經落地的機制。
建造者該注意什麼
Cloudflare 給出的框架是 Intermediation Principle：使用者與網站的業務關係、以及各參與者的安全責任，必須在有任何中介的情況下都成立。翻譯成產品語言：你的 Agent 不能只對使用者負責，還得讓網站能辨識它背後的 Operator 和使用者。
對做 Agent 產品的人，下一步很實際：檢查你的 Agent 存取第三方網站時帶了什麼身份訊號——它有沒有如實表明自己是 Agent？它能不能在使用者授權時，向網站證明「這個動作背後是這位使用者」？如果你的產品在網站眼裡只是一個共用幾千個使用者的匿名客戶端，你遲早會撞上被封鎖、被要求人工驗證、或替使用者糾紛背鍋的問題。這和 hosted agent 的整體基礎設施問題是同一條線——我們先前在 Runtime 把沙盒化 coding agents 開放給整個團隊 一文裡也討論過，遠端執行環境的信任邊界遲早要面對同樣的設計。
限制也要說清楚：這篇文章是問題框架與原則主張，並未提供具體採用數據或證明任何機制已經解決上述挑戰。agentic traffic 何時超過人類瀏覽、哪些 Operator 會率先提供可驗證的委託機制，都還是未知數。但在這些機制出現之前，先把「使用者身份如何穿過 Agent 傳遞到網站」納入你的產品設計，是成本最低的準備。