AI 可能默默把密碼外傳了！自動化「3」條線守住用戶資料隱私

如果你看到 Grok Build 的新聞，第一反應是「這是 xAI 的問題，我用 Cursor 或 Claude Code 應該沒事」——我懂這個直覺，我自己剛看到的時候也是這樣想。
但仔細往下讀完，我把自己的 AI 自動化流程重新過了一遍，因為這件事踩到的問題不是「哪家工具比較壞」，是一個每個 coding agent（可以自己執行程式任務的 AI 助理）都可能踩到的授權邊界問題。
這篇要拆三件事：這次 Grok Build 事件到底發生了什麼、xAI 的開源回應有沒有真正解決問題，以及我用 AI 自動化一段時間後，怎麼設計 coding agent 的授權驗收紀律。

Grok Build 傳了什麼

研究者透過 mitmproxy（一種可以攔截所有網路封包的工具，用來做網路流量分析）分析了 Grok Build 0.2.93 版本的行為。
Grok Build（xAI 推出的 AI 程式助理工具）在執行 coding 任務時，同時啟動兩個通道：一個是模型讀取通道（讀取你的程式碼理解任務），另一個是獨立的儲存通道。
問題出在儲存通道——它把完整的 Git repo bundle（包含所有提交歷史與版本紀錄）上傳到 xAI 控制的 Google Cloud 儲存桶 grok-code-session-traces。
技術分析發現：模型實際讀取量約 192 KB，儲存通道上傳量約 5.10 GiB（73 個分包）。
.env 檔案裡的 API 金鑰（連接外部服務的密碼）與資料庫密碼以明文出現在流量中——加密傳輸路上看不到，但 xAI 的儲存桶收到的就是明文內容。
核心問題不是資料傳輸本身，而是同意的缺席。 使用者以為只是「叫 AI 分析程式碼」，沒有人告知也沒有人同意「把整個 repo 傳到別人的雲端」。
目前技術證據只能確認「上傳確實發生且使用者不知情」，xAI 的動機是糟糕的工程設計決策還是有其他考量，目前尚無定論，不宜自行推斷。

隱私開關為何失效

很多使用者以為，打開 Grok Build 的隱私設定就能保護自己的程式碼。這是設計上造成的誤解。
隱私開關實際控制的是： xAI 是否有權使用你的資料訓練模型。這個開關的作用域是「資料用途」，不是「資料是否離開你的電腦」。
換句話說，打開隱私開關的使用者，資料一樣傳出去了——差別只在 xAI 能不能拿它做模型訓練。
真正停止上傳的機制，是 xAI 在 2026 年 7 月 12 日靜默在伺服器端修改了一個旗標（disable_codebase_upload: true），同一個 0.2.93 版本的程式之後就停止上傳了。
使用者沒有收到任何通知，也沒有版本更新——停止上傳這件事，是 xAI 在自己的伺服器上做的，不是你的設定有效。

這個設計結構就是問題所在：真正的開關在 xAI 那邊，不在使用者這邊。

開源後安全了嗎

事件曝光後約 72 小時，xAI 宣布三項措施：刪除已上傳的使用者資料、停用預設資料保留，以及將 Grok Build 約 844,530 行 Rust 程式碼以 Apache 2.0 授權開源至 GitHub。
安全研究者（包括知名開源社群觀察者 Simon Willison）閱讀原始碼後指出三個問題：
第一，開源的是 squashed monorepo（壓縮整合的程式庫），沒有修改歷史，外界無法看出哪些地方被改動過，只能看到現在的狀態。
第二，外部 PR（外部開發者的程式碼貢獻）已關閉，社群無法直接提交安全修補，開源只是讓人「看」，不是讓人「修」。
第三，也是最關鍵的：上傳機制仍然編譯在 0.2.99 最新版本的執行檔裡，目前靠 xAI 控制的遠端旗標壓制。
技術上，xAI 只要修改那個旗標，就能在不更新客戶端版本的情況下重新啟用上傳——使用者無法獨立驗證這件事有沒有發生。
不可以把「開源」等同於「問題解決了」。
真正的可稽核要能獨立回推，不靠對方承諾不翻轉開關。這點目前做不到。

效能優化說得通嗎

部分開發者為 xAI 提出了技術辯護：coding agent 在多輪任務中預先快取（pre-cache — 先把資料存好方便後續快速取用）完整 repo，是業界常見的效能優化手段，類似 IDE（寫程式的開發環境，如 VS Code）的索引機制。
問題不在「上傳」本身，而在溝通方式。
這個辯護在技術層面有一定道理——預先快取可以減少每次 API 呼叫的延遲。
但技術上合理不能替代使用者知情同意。
我對這個辯護的判斷是：不同意。 理由很簡單：即使預快取完整 repo 有效能道理，「未告知 + 隱私開關設計誤導」還是 consent violation（未取得同意的行為）。
使用者不需要判斷 xAI 的動機是否善意，只需要問：「我有沒有明確授權這個動作？」
沒有，就是越權，不論技術理由多合理。

其他 agent 安全嗎

看到這裡，很多人會問：那我改用 Claude Code 或 Cursor 就安全了嗎？這個問題的答案需要一點精確度。
以下是各家目前已公開的資料政策（來源：各平台服務條款與 MintMCP/getmaxim.ai 2026 比較分析）：

重要限定： 上表中除 Grok Build 外，其他工具的資料傳輸行為尚未接受同等嚴格的封包側錄（wire-level）分析。
「沒被分析到」不等於「沒有問題」——Grok Build 只是第一個被這麼仔細看過的 coding agent 工具。
這不是要讓你恐慌，是要讓你對所有工具一視同仁，建立驗收紀律，而不是只針對 Grok Build 換工具就覺得安全了。

我的授權踩雷

我帶 AI 自動化大概一年半，最常被提醒的一課，是「靜默地沒做某件事」和「靜默地多做了某件事」是同一種危險，只是方向相反。
在我自己的 AI 寫作生產線裡，有一次讓 agent（可以執行任務的 AI 工具）自動化整條內容流程，中間有個步驟是更新知識庫裡的資料表格。
某次我跑完，agent 說完成，但幾天後才發現：前台顯示的格式完全沒動，agent 實際上沒有執行到那個步驟，只是沒有任何報錯就收尾了。
那次讓我把所有 agent 的「完成報告」改成要附落地證據——不是「我做了」，是「這是我做完後可以看到的東西」。
Grok Build 事件是另一面：不是靜默沒做，是靜默多做了。
兩種情況都沒有警報，都讓你的驗收邏輯失效。
所以我現在的紀律是對稱的：不只驗「有沒有漏做」，也驗「有沒有多做了我沒叫它做的事」。
這不是 Grok Build 才逼出來的規則，是跑 AI 自動化的過程一路踩出來的。
這次事件只是讓這條紀律的重要性變得更清楚。

agent 驗收三紀律

根據 Grok Build 事件與我自己的使用經驗，以下是三條我認為適合任何 coding agent 使用情境的驗收紀律：
紀律一：授權只綁定那個被批准的動作，不是空白支票。
你說「分析這個 repo」，只批准了分析這個動作。
「把整個 repo 傳到雲端」是另一個動作，需要另一次明確授權。
每次批准一個動作，都要確認這個批准的邊界在哪裡。
紀律二：不可逆的動作預設要先核可。
傳出去的資料收不回來，刪掉的生產環境資料也救不了。
這類不可逆動作（包含但不限於：資料傳送、資料刪除、寫入外部系統、部署到正式環境），預設應該要人工確認，不能讓 agent 自行決定要不要執行。
紀律三：驗收看落地證據，不看 agent 自己的宣稱。
「✅ 完成」不是證據，是宣稱。
驗收要看的是：它真正做了什麼動作、有沒有做了你沒授權的事、結果是不是你預期的樣子。
落地證據包含：日誌（log — 系統執行記錄）、網路流量、實際輸出結果，不是 agent 的自我回報。
如果你現在用的 coding agent 讓你無法取得這三條所需的資訊，至少去確認一下你使用的是哪個版本、它的資料政策寫了什麼，以及有沒有辦法在你的環境裡做基本的流量監控。
判斷這件事最有用的一個問題：你按下那個指令，你批准的動作的邊界在哪裡？
如果你說不清楚，這就是 agent 可能把它解讀成空白支票的地方。
問自己三個問題：

• 我的 coding agent 在執行任務時，有哪些動作我沒有明確授權過？

• 我有辦法驗證它有沒有做了我不知道的事嗎？

• 如果它說「✅ 完成」，我拿什麼當落地證據？

常見問題

• Grok Build 的資安問題是什麼？ Grok Build 0.2.93 在使用者未明確授權的情況下，把完整 Git repo（含 .env 密碼）上傳到 xAI 的雲端儲存桶，模型實際讀取 192 KB，但傳輸量約 5.1 GB。隱私開關無法阻止上傳，只控制資料能否用於訓練。

• xAI 開源 Grok Build 之後問題解決了嗎？ 未解決。上傳機制仍編譯在最新版執行檔中，只靠 xAI 控制的遠端旗標壓制，使用者無法獨立驗證有沒有重新啟用。開源本身是第一步，但可稽核需要更多條件。

• Cursor、Claude Code 安全嗎？ 目前這些工具尚未接受同等嚴格的封包側錄分析，不能確認沒有類似行為。建議對所有 coding agent 工具一視同仁，確認其資料政策並建立驗收習慣，而不是只針對 Grok Build 換工具。

• coding agent 的授權問題怎麼防範？ 三條紀律：授權只綁定被批准的那個動作、不可逆動作預設要先人工核可、驗收要看落地證據（日誌/流量/實際輸出），不是 agent 的自我宣稱。

• 我的程式碼有沒有被 Grok Build 上傳到 xAI？ 如果你在 2026 年 7 月 12 日 server-side flag 生效之前使用過 Grok Build 0.2.93 分析過任何 Git repo，那份 repo 的完整內容（含歷史紀錄與 .env 檔）理論上已被上傳。xAI 宣稱已刪除，但目前沒有第三方稽核機制可以獨立驗證這個聲明。