Cloudflare 推動 Trusted Agent Delegation，網站如何辨識 AI 代理與背後使用者？
Cloudflare 推動 Trusted Agent Delegation 聯盟，並增加代理流量分析、存取政策與帳號風險控制。本文區分代理和使用者身分、現有功能與開發中協定，整理方案及早期開放限制。
當 AI 代理代替使用者登入網站或購物，網站看到的可能是同一套雲端服務。
這使站方更難分辨哪些請求來自同一個人，以及問題發生後應處理哪個帳號。
Cloudflare 在二〇二六年十一月五日提出新的 Trusted Agent Delegation 聯盟與網站管理措施。
其中有些功能本週已進入正式環境，開放協定的協調則仍在進行。這次消息需要把產品控制、聯盟討論與既有標準分開，才能看清楚網站現在能做什麼，以及哪些問題仍待解決。
我認為網站團隊應先從自己看得到的流量與帳號風險著手，再決定需要哪些身分資訊。因此，第一步是把代理服務的身分和委託它的使用者分開理解，接著檢查現有存取政策是否還能對到正確對象。
代理身分與使用者身分為何要分開？
同一個代理服務可以同時為許多人工作，站方卻可能只看到共同的來源。傳統網站經常根據帳號、連線環境與操作紀錄判斷風險。當請求經過雲端瀏覽器或代理平台，這些訊號就可能和使用者親自開啟網站時不同。
例如，一位顧客請代理查詢訂單，另一位使用者透過同一平台反覆嘗試登入。若站方只能辨識平台，封鎖來源可能連正常顧客一起擋住。若全部允許，又可能讓有問題的活動繼續。
這是官方文章討論的流量混合問題，重點在於如何把行為對回適當的使用者或工作階段。
購物與訂閱也有類似落差。網站需要知道某項動作是否獲得委託，以及後續爭議可以查閱什麼紀錄。代理能完成操作，不代表網站自動取得了足夠的授權證據。
這些問題涉及不同參與者的資訊與責任，不能只靠辨認「這是不是機器人」就全部回答。
Cloudflare 的主要討論對象是遠端代管的個人代理，也就是服務商在自己的基礎設施上替人操作。使用者裝置裡的本機代理、自己瀏覽器中的自動化，具有不同條件，並非這次聯盟初期處理的主要範圍。
這項界線有助於避免把所有自動化工具都視為相同架構。
官方提出的方向，是讓代理、營運者與使用者之間的關係能被合理辨識，同時保留依情境選擇揭露程度的空間。知道這個資訊缺口之後，才適合安排請求簽章、帳號授權與其他證明各自的任務。
Web Bot Auth、OAuth 與聲明各自處理什麼？
請求簽章能幫助站方辨識代理服務，帳號與其他聲明則回答不同層次的問題。Cloudflare 在文章中把 Web Bot Auth 列為偏好的代理識別方式。
透過簽署請求，代理可以表明自己來自哪個服務，站方也有機會驗證這個資訊。
這項驗證和辨識背後使用者有所區別。知道某個請求來自可信的平台，仍不代表已知是哪位顧客，也不代表每一項交易都已獲得授權。
網站若需要帳號關聯，可能還需要 OAuth 或其他帳號機制。若需要年齡或持卡資格等條件，則需要對應的聲明與查核方式。
官方把識別需求描述成一個光譜。有些公開內容可在沒有個人識別資訊時提供，有些情境只需把同一次工作階段的請求連起來。有些服務需要跨次登入的帳號關聯，更高風險動作才可能需要較強的唯一性證明。
這不等於所有代理請求都必須上傳政府證件或使用特定身分供應商。
隱私與存取控制也需要一起設計。站方希望確認請求是否符合條件，未必需要收集使用者的完整身分。
Cloudflare 提到 Privacy Pass 與正在發展的 MOLE 等方向，目標是在部分情境下提供可用的信任訊號，同時減少不必要的個人資訊。
MOLE 在原文中仍被描述為即將發展的方案，不能把它寫成已經全面完成部署的共同標準。Web Bot Auth、OAuth 與其他協定也各有處理範圍。這些機制需要協調，因此聯盟的角色與可用產品功能必須分開看。
Cloudflare 的 TAD 聯盟目前推動到哪一步？
新聯盟要整理跨服務問題並和既有標準工作接軌。
Trusted Agent Delegation 簡稱 TAD，Cloudflare 希望透過聯盟讓代理平台、網站、支付、身分與基礎設施相關參與者討論共同問題，再把更明確的需求帶到適合的標準工作裡。
這次公告不代表代理委託的所有技術與責任問題已經解決。聯盟仍需要檢視既有協定能處理哪些需求、哪些地方需要補充，以及不同服務能否互通。文章也提到未來透過會議與工作坊促進討論，顯示這是持續進行的協調工作。
網站政策的表達，是其中一個例子。傳統 robots.txt 能表達爬蟲可存取的位置，卻不容易涵蓋代理能否登入、提交表單或完成交易等動作。
若代理只能不斷嘗試，再從封鎖結果猜規則，雙方都會增加成本，也可能讓正常活動看起來像攻擊。
Cloudflare 希望網站能以機器可讀方式表達允許的行動與條件。不過，內容偏好、身分、付款與委託責任分屬不同問題，未必能由單一欄位或一種權杖全部處理。
公開文章也沒有宣布已完成一套可以自動解決退款爭議或轉移法律責任的機制。
對站方而言，可以把聯盟視為值得追蹤的標準方向，同時繼續檢查現有產品能力。標準仍在演進時，站方已能先使用本週增加的可觀測與存取控制，處理眼前能夠確認的流量問題。
網站現在可以做哪三件事？
Cloudflare 提供的起點涵蓋可觀測、依代理控制與帳號風險處理。網站可以先查看哪些代理正在存取。
Security Analytics 新增個人助理流量分類，並提供代理請求量、路徑與錯誤等資訊，讓站方更容易理解自動化流量的實際用途。
這類資料可以先回答幾個具體問題。流量集中在哪些頁面？代理是否反覆查詢昂貴的搜尋端點？錯誤是否出現在登入或購物流程？先觀察這些行為，才能區分正常需求與需要調整的使用方式。
若要查看更廣泛的爬取與回流商業資訊，文章提到的 Business Insights 有 Enterprise Bot Management 資格限制。
第二項是依代理設定存取政策。官方表示，網站可透過 AI Crawler and Agent access policies，對不同代理採取允許、限制某些廣告頁面，或全面阻擋等方式。
搜尋與訓練政策維持獨立，站方不必把每一種 AI 用途都綁成同一個決定。
這個區分對內容網站尤其有意義。允許某個服務協助使用者查詢內容，不代表也必須同意相同服務將內容用於模型訓練。實際能設哪些規則，仍要依帳號介面、產品資格與官方文件確認，不能把公告中的所有能力推成每個方案自動具備。
第三項是把代理請求和帳號風險連起來。使用 Account Abuse Protection 早期開放功能的網站，可在登入與註冊事件看到是否由個人代理操作，以及是哪個代理。
官方也說明，可利用雜湊使用者識別碼建立 WAF 規則，針對特定帳號處理問題，減少封鎖整個共用代理服務的需要。
這不表示站方因此取得每位使用者完整身分，也不代表早期開放功能已對所有客戶提供。它處理的是特定事件與帳號層級的可見性。不同起點有各自的方案與開放條件，導入前需要先確認帳號可見範圍。
讓不同動作使用適當強度的證明
以公開文章、會員內容與付款三種動作為例，網站需要回答的問題可能逐步增加。公開文章也許只需控制請求速度，會員內容需要確認訂閱資格，付款則可能還要確認交易委託與帳號風險。
這是依官方問題架構提出的情境分析，並非新協定已完整提供的產品流程。
如果把三種動作一律要求最強身分驗證，正常查詢會增加不必要的摩擦。若全部只看代理平台名稱，會員與付款的條件又可能不足。比較務實的做法，是先列出每一種動作的必要條件，再看現有工具能取得哪些證據，缺少的部分如何處理。
同時也要保留例外路徑。當代理無法提供某項必要資訊時，網站可以根據自己的流程決定是否要求額外步驟，或只提供較低風險的功能。這類政策應清楚表達並能回到紀錄檢查，避免同一使用者在不同入口遇到互相矛盾的結果。
對聯盟與標準的追蹤，也可以回到這份需求清單。當新協定宣稱解決某個問題時，就檢查它是否能補上站方實際缺少的資訊，而不是只因名稱相近就認定整個代理流程已經獲得授權。
如何從單一流程開始驗證？
網站團隊可以先挑登入或訂單查詢等一個具體流程，確認流量、帳號與政策是否能對得上。第一次評估不需要同時改變整站的存取規則，先理解代理目前做了哪些動作，通常比較容易找到值得處理的問題。
例如，站方可以在既有紀錄中比較一般使用者與代理的登入結果，查看失敗位置與頻率。如果某個代理經常在同一步遇到錯誤，應先釐清是正常防護、介面不相容，還是資訊不足。
這種分析能讓後續政策有具體理由，也有機會改善合法使用者的流程。
若要新增限制，可以先選範圍明確的路徑與行為，再檢查正常請求是否仍能完成。記錄規則變更前後的請求與錯誤，有助於判斷是否把問題轉移到另一個地方。這是網站管理上的驗證建議，並非本文已在讀者網站執行的測試結果。
個人資訊也應依任務需求處理。公開資訊查詢、登入帳號與付款操作，需要的證明強度可能不同。先說清楚網站想確認什麼，再選擇適合的機制，才能避免收集一堆資料卻仍回答不了真正的存取問題。
這次 Cloudflare 消息顯示，AI 代理進入網站後，管理重點正在從單純辨識自動化，延伸到代理與使用者的關係。聯盟會持續發展，現有控制則可以先從具體流程評估。
當允許與限制都能回到請求紀錄時，代理存取才有可持續調整的依據。
常見問題
TAD 是否已經成為所有網站通用的完成標準？
目前公告的是聯盟與持續進行的協調方向，會檢視既有協定並提出更明確需求。本文沒有把它當成已完成、所有服務都互通的統一標準。
驗證代理簽章就能知道背後使用者是誰嗎？
代理簽章主要協助辨識服務或營運者。帳號關聯、個別使用者條件與交易授權，仍可能需要其他機制，應依動作需求分開確認。
Cloudflare 三項控制是否都對所有方案開放？
官方對部分能力列有條件，Business Insights 涉及 Enterprise Bot Management，Account Abuse Protection 則屬早期開放。
實際可用範圍應核對自己的帳號與產品資格。
