Claude Code 隱私爭議：讀網頁為何帶出電子郵件？看懂防護與證據邊界（2026）

2026 年 11 月 5 日（UTC），GitHub 使用者 taylor-edwards 在 Anthropic 的 Claude Code 儲存庫公開了〈Bug Report: Privacy violation in User-Agent header〉。這則 Claude Code 隱私通報指稱：代理查資料時，把帳戶電子郵件放進對外請求的 User-Agent 標頭。它提出的問題很直接：你同意 AI 讀取網頁，是否也同意它把你的身分交給那個網站？

下面先還原通報與回覆，再對照官方公開的防護說明，最後判斷該把責任放在哪一層。目前足以確認的是：有具名通報，官方也公開了一個範圍有限的 privacy 模組；個別帳戶究竟送出過什麼，仍要用那次執行的證據判斷。

本文查閱資料至 2026 年 11 月 7 日，採公開通報與文件分析，未啟動 Claude Code 做帳戶資料外傳測試。封面是 AlphaLab 原創編輯插畫，以身分卡、閘門與封包路徑表達資料出口，並非產品介面或事件重現。

一、Claude Code 隱私通報，原作者到底指控了什麼？

作者填寫的環境是 macOS、tmux 與 Claude Code 2.1.318。他把收到詐騙郵件與先前的電子郵件外傳連在一起，要求從執行層移除這類行為，而非把它留給使用者選擇開關。這是原作者的指控與訴求，並非一份已完成因果鑑定的事故報告。

without my permission

中文：未經我的許可。

taylor-edwards，GitHub issue #107757 節錄

這四個字，比「有沒有用 HTTPS」更接近爭議核心。使用者交辦的是查資料，電子郵件卻可能被當成替軟體聯絡人的欄位。即使任務本身獲得授權，也需要另外說明：哪些身分資料可以提供給哪個接收者。

11 月 6 日，同串留言中的 mkubenka 另稱，在自己的紀錄找到兩個案例，請求將專案或工具名稱與帳戶電子郵件放在一起；其中一例涉及先寫入腳本、再執行腳本。他也回報 2.1.319 的檢查疑慮。這些是該使用者的紀錄摘述與測試自報，不是 AlphaLab 重現，也不能據此估計所有安裝的受影響比例。

本次擷取的原頁已有數百個讚；那代表關注度。它既不是受害帳戶數，也不是獨立驗證次數。至於垃圾郵件，還需要同一地址的既有曝光、收件時間與接收端等證據，才有辦法把相關性往因果關係推進。

二、User-Agent 為何會變成身分出口？

HTTP 標準 RFC 9110把 User-Agent 定義為描述發出請求之軟體的標頭，通常包含產品識別與版本等資訊。可以把它想成請求外面的工具名牌：網站讀取它，了解是哪種客戶端在連線。把私人電子郵件加進名牌，則多給了一項可識別人的資訊。

同份標準也提醒，過細的 User-Agent 資訊會增加辨識與追蹤風險。因此「欄位裝得下」不等於「任務需要它」。Wikimedia 的官方政策確實要求自動化客戶端提供可辨識資訊與聯絡方式，並列出電子郵件、網站或 wiki 使用者等形式。這解釋了代理可能遇到的任務壓力，卻沒有授權它自行選用私人帳戶地址。某個網站若要求自動化客戶端提供聯絡方式，團隊可評估提供獲准的公共服務信箱；代理不應自行把登入帳戶地址當成已核准的聯絡人。這是本文的資料最小化判斷。

HTTPS 保護傳輸途中遭旁觀者讀取的風險，接收網站仍必須讀到請求才能處理。若身分、專案名稱與查詢內容一起送到同一端，對方就可能將它們連在一起。問題因此是接收者是否獲准拿到這些欄位，加密無法代替這項決定。

三、官方說有防護，為何仍不能直接宣布結案？

GitHub 標示為 Contributor 的 poteat 在同串回覆稱，2.1.317 起加入內建 cc-plugin-privacy，並表示它預設開啟。這是有身分標記的貢獻者說法，應與實際公開文件一起看。

The built-in privacy mod is enabled by default

中文：內建隱私模組預設啟用。

poteat，GitHub issue #107757 節錄

另可獨立核對的是官方 CHANGELOG 的 2.1.317 條目：它記載新增檢查，當網頁或 shell 工具呼叫把帳戶電子郵件送往網路前會詢問。這支持「官方確實加入相關檢查」；它不能替所有工具、設定與版本的實際結果背書。

更有判讀價值的是官方儲存庫現已公開的 privacy 模組 README。文件描述：它在工具檢查時，對 Bash、PowerShell 或 Monitor 的輸入做比對，當輸入同時含帳戶地址與 User-Agent 的識別形式便拒絕。這份模組文件描述的是拒絕而不彈出詢問；CHANGELOG 的較廣義詢問敘述，不能直接當成同一層檢查的完整規格。

This is a courtesy, not a boundary

中文：這是一項輔助防護，而不是安全邊界。

Anthropic 官方 privacy 模組 README 節錄

README 明列該模組的範圍：WebFetch、WebSearch 與 MCP 工具不在這個檢查內；執行時才取得的值、變數及另存腳本等，也有列出的限制。這是該模組的限制，不等於那些工具都沒有其他保護。文件也交代模組可能因設定、伺服器開關或 hook 載入情況而停止作用，所以「預設啟用」與「這次確實被攔」要分別驗證。

公開規則讓外界更容易檢查，這是進步。可是規則存在、宣稱已啟用、特定請求遭拒，以及資料沒有送達，是四種不同證據。把其中一種代替另外三種，容易過早放心，也容易過度指控。

四、這次 Claude Code 隱私爭議，應該怎樣分證據？

目前材料	支持的判斷	還不能推出的結論
原始通報與使用者留言	作者回報了哪些環境、動作與疑慮	所有使用者都受影響、垃圾郵件必由此而來
官方更新紀錄與模組文件	相關檢查已被記載，模組有明示範圍	每次執行都載入、所有出口都被覆蓋
綁定同一次動作的工具與接收端紀錄	特定欄位是否送出、送往哪裡	其他版本與其他工作也有相同結果

對個別通報，最有力的下一份材料會是去識別化的完整事件鏈：版本與有效設定、產生的請求、檢查結果、實際執行結果，以及接收端看見的欄位。只展示一行會被允許的本機文字，能質疑檢查行為；要證明資料到了外部網站，仍需要另一層收據。歷史比對如何讀，可接著看 Stroq 舊 Session 掃描教學。

五、AlphaLab 的判讀：該改的是資料與權限的連接方式

1. 便利的個人化，也會擴大可以被拿來組請求的材料

知道使用者是誰，能幫助代理理解任務；但代理替外部服務組裝請求時，同一份資訊可能被挪用。官方 README 已說明帳戶地址會進入模型脈絡，這使「哪些資料需要先提供給模型」成為值得審視的產品決策。

較穩健的設計方向，是把身分資料的用途寫清楚，盡量讓不需要私人地址的任務拿不到它。若確實需要對外提供聯絡方式，就以目的地與用途為單位取得授權。這仍要兼顧工作流程；只是便利所需的資料，應有明確的使用範圍。

2. 模型提出的請求，應由執行層決定能不能送

模型可以建議帶哪些欄位，真正的傳送權應由可執行的政策承接。這也是 Agent Harness 的關鍵分工：讓創意與權限分開。特定字樣比對適合快速減少已知錯誤；若任務涉及機密專案，還需要限制程序真正能讀哪些檔案、到達哪些主機。

Claude Code 官方安全文件也區分「按命令文字匹配的 deny 規則」與網路隔離。sandbox 文件則明確說明，內建 sandbox 包住 shell 指令及其子程序，檔案工具、MCP 與 hooks 有不同範圍；若需要同一個外部邊界，應考慮把整個程序放進受控環境。允許某個網域，仍不能證明送往那個網域的每項資料都合適。

3. 問責應該追可驗證的修補，而不是要求使用者猜設定

我同意原通報最重要的訴求：代理自行加入私人聯絡資料，應有清楚的產品防護與可查的行為。公開模組與限制，比只說「我們重視隱私」更有資訊；下一步則應讓版本、載入狀態、失敗案例與適用範圍更容易對帳。

我存疑的是兩個過快的結論：「出現回報，所以每次連線都外洩」與「已有預設模組，所以問題全面解決」。前者跳過發生比例與執行條件，後者跳過實際啟用與出口範圍。對採用決策，兩種跳躍都會增加誤判。

六、現在可以做什麼？先縮小資料，再驗收出口

個人使用者：先保留涉及這類請求的時間與版本，檢查當時實際產生的 URL、標頭、查詢及送出內容。對外分享前，遮掉私人地址、專案與客戶資訊。可以用 出站流量稽核 的證據觀念，分開看「寫進請求」與「真的送達」，別為了重現而把真實地址再傳一次。

團隊負責人：更新到團隊核准的版本後，用合成身分與自己控制的接收端驗收；每個測例都要同時記錄是否遭拒、是否真正執行及接收端收到什麼。分開涵蓋直接請求、腳本與已使用的工具路徑，測試標籤也不放真實客戶名。這是本文提出的驗收設計，並非已完成的全面測試。

處理敏感工作的人：將資料讀取與網路權限壓到任務需要的範圍，並先確認官方 sandbox 對自己工具的涵蓋情況。AI Agent 密鑰安全可補上機密如何少進入工作脈絡；需要串接控制時，再讀 Harness 實作。一張「查資料」授權，不應自動變成公開私人身分的空白支票。

值得追蹤的後續很具體：官方能否提供涵蓋不同工具的測例、可辨識的啟用狀態，以及能用同樣條件核對的修補結果。先讓每一項對外資料都有目的地、用途與證據，再決定要交給代理多少自主權。