═══ 你關掉「不要拿我的資料訓練AI」，重要檔案還是被上傳了——Grok Build 事件 ═══

資安事件簿 · 更新於 2026.07.15 · 約 16 分鐘閱讀

一位資安研究者用側錄網路封包的方式發現，xAI 的程式碼助理 Grok Build 會把使用者的整個專案資料夾打包上傳到雲端——包含 AI 從來沒讀過、甚至被明確告知「不要打開」的檔案。更麻煩的是，介面上那個看起來理論上是隱私開關的選項，關掉了也擋不住。這件事表面上是開發者的問題，但它揭露的落差，每一個用 AI 工具的人都會遇到。

──────────────────────────────

［圖片：Grok ai interface with a question prompt］

◆ 本文重點

• xAI 的程式碼助理 Grok Build 被證實會把使用者的整個專案（含完整修改歷史、密碼設定檔）上傳到 Google 的雲端儲存空間，與 AI 實際讀了哪些檔案無關。

• 這不是「AI 不聽話」。上傳的是程式本身內建的一個背景元件，你在對話裡怎麼交代都攔不住。

• 介面上的「改善模型」開關，管的是要不要拿去訓練，不是資料要不要離開你的電腦。這兩件事被很多人混為一談。

• xAI 已在事發後悄悄關閉該行為並公開回應、承諾刪除資料，但至今沒有解釋預設為什麼要這樣做。

• 如果你用過這個工具處理含有密碼或金鑰的專案，請把那些金鑰全部換掉——刪掉本機檔案沒有用。

• 用 AI 寫程式的人（vibe coding）風險最高：AI 會幫你建立一個裝著金鑰的檔案，而你可能不知道它存在。問 AI 一句「這個專案有哪些檔案不能外流？」就能解決大半問題。

◆ Grok Build 到底發生了什麼事？

首先讓大家了解這個工具：Grok Build 是 xAI 在 2026 年 5 月推出的「程式碼助理」——工程師在自己的電腦上打開它，用白話交代「幫我修好這個功能」，它就會去讀專案裡的檔案、想辦法、然後動手改。這類工具現在很普遍，Google、OpenAI、Anthropic 都有自己的版本。

2026 年 7 月 10 日，一位以 cereblab 為代號的研究者發表了一份技術分析報告 (https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547)，內容是把 Grok Build 執行時所有進出電腦的網路流量全部錄下來，逐一檢查。

用一個生活化的比喻：

你請一位師傅到家裡修一個抽屜。師傅拉開抽屜、看了一眼、修好了——這部分完全合理。但同時，師傅還在你沒注意的時候，把整個房間的所有東西打包裝箱，寄到公司的倉庫去。包括你放在櫃子最裡面、明確跟師傅說「這個不要碰」的那個盒子。

而且比例懸殊到荒謬。研究者拿一個 12 GB 的測試專案做實驗：AI 實際處理任務所需要的資料，只傳了大約 192 KB；但在同一時間，另一條通道往雲端送出了 5.10 GB。兩者相差約 27,800 倍。

換句話說：那 5 GB 的資料，AI 根本沒用到、也不需要。它就是被送去某個地方了。

◆ 這不是「AI 不聽話」的問題，這是設計失誤

這件事在社群上流傳時，最常見的說法是「AI 無視使用者的規定」。這個框架聽起來很聳動，但它其實弱化了問題，也讓人抓錯重點。

研究者從程式檔案內部找到證據：這個上傳功能是一個獨立的資料蒐集元件，跟 AI 的判斷、跟你在對話框裡寫了什麼，完全沒有關係。它是另一條線路，在背景自己跑。

最能說明這件事的實驗是這樣的：研究者在專案裡放了一個檔案，裡面寫了一串獨一無二的暗號，然後下達指令——「只要回我一個 OK 就好，不要打開任何檔案」。AI 確實乖乖照做，什麼都沒讀。但同一時間，整個專案還是被打包上傳了；研究者把上傳的封包攔截下來、解開，那個「不准打開」的檔案就在裡面，暗號一字不差。

◆ 常見誤區：以為「跟 AI 說清楚」就有用

很多人以為只要在對話裡交代「不要碰這個檔案」「不要外傳」，AI 就會遵守。但這次事件說明：資料傳輸的行為不一定發生在 AI 的層次。它可能發生在你安裝的那個「殼」——也就是連接你電腦和雲端的那支程式——身上。AI 再聽話，也擋不住主程式在背後做的事。

◆ 證據有多強？也講清楚哪些還沒被證實

這份報告的品質在資安爆料裡算是相當高的。研究者測試的是 Grok Build 0.2.93 版，提供了完整的重現步驟、每個證據檔案的雜湊值，並且把上傳被攔下來的封包直接還原成一個可以打開的專案，證明「整個專案 + 完整修改歷史」確實離開了電腦，而伺服器也確實收下了（回應碼 200）。同樣的實驗在另一個無關的專案上重做一次，結果相同。

資料的目的地是一個叫做 grok-code-session-traces 的 Google 雲端儲存空間。

但研究者也非常克制地寫了一整節，標題叫做「我們沒有證明什麼」——這一點值得我們學習，也值得如實轉述：

• 沒有證明 xAI 拿這些程式碼去訓練模型。已證明的只有「傳輸、接收、儲存」三件事。

• 沒有證明每一個帳號都是同樣的行為。

• 沒有證明 xAI 的員工看過這些內容。

這個分寸很重要。「你的程式碼被上傳並保存」已經夠嚴重了，不需要加油添醋成「你的程式碼被偷去訓練 AI」——後者目前沒有證據。

◆ 研究者是怎麼查出來的？

封包側錄：在自己的電腦和網際網路之間架一個「檢查哨」，把程式送出去的每一筆資料都攔下來看一眼。這是資安研究的標準做法，工具（例如 mitmproxy）是免費的。

金絲雀（canary）：在檔案裡放一串世界上不會重複的暗號。如果這串暗號出現在流出去的資料裡，就百分之百確定是這個檔案被送走了，沒有模糊空間。名字來自礦工帶金絲雀下坑偵測毒氣的典故。

◆ 那個隱私開關，不是你想的「開關」

這是整起事件裡最值得每個人記住的一段——就算你這輩子不會碰程式碼。

Grok Build 的設定裡有一個開關，叫做「改善模型」（Improve the model）。多數人看到這個開關，會理所當然地理解成：關掉它，我的東西就不會被拿走。

研究者把它關掉，重跑一次。結果：整個專案照樣被打包上傳，伺服器回傳的設定值裡，那個真正控制「要不要上傳」的參數仍然是「開啟」。

因為那個開關管的是訓練同意，不是資料傳輸。這是兩件事：

• 「不要拿我的資料訓練」＝ 你的資料還是會傳到對方的伺服器上、還是會被存起來，只是（據稱）不會被丟進訓練模型的流程。

• 「不要把我的資料傳出去」＝ 資料根本不離開你的電腦。

絕大多數 AI 工具給你的，是第一種。而多數使用者以為自己拿到的，是第二種。

這個落差不是 Grok 獨有的。它是整個 AI 產業目前的常態。差別只在於，這次有人拿封包側錄把它攤在陽光下。

◆ xAI 說與沒說的部份

這起事件在短短四天內變化很快，時間軸值得完整記錄：

• 7 月 10 日：研究者公開技術分析報告，隨即登上 Hacker News 首頁，引發大量討論 (https://news.ycombinator.com/item?id=48892468)。

• 7 月 11–12 日：研究者複測時發現，伺服器端的設定已被改成「停用程式碼庫上傳」，重測六次都不再出現整包上傳。也就是說，xAI 不需要更新使用者電腦上的程式，遠端改一個開關就讓行為變了。當時官方更新日誌完全沒提到這件事，狀態頁也沒有任何事件公告。

• 7 月 13–14 日：xAI 官方帳號與 Grok Build 負責人 Andrew Milich 陸續公開回應 (https://x.com/SpaceXAI/status/2076692402442846289)，說明企業版的「零資料保留」（ZDR）不會保存任何程式碼；一般使用者可以在工具裡輸入 /privacy 指令關閉資料保留，並會一併刪除先前已經同步上去的資料。Elon Musk 隨後表示，先前上傳的資料將被完全刪除。

所以「xAI 完全沉默」的說法，在 7 月 14 日已經不成立了——如果你在網路上看到還在這樣寫的文章，請注意發文時間。

但截至本文查核時間，xAI 仍然沒有回答幾個關鍵問題：Neowin 指出 (https://www.neowin.net/news/elon-musk-says-spacexai-will-delete-all-grok-build-user-data-following-privacy-concerns/)，官方至今未發布正式的資安公告說明哪些檔案被上傳、保存了多久、刪除何時完成，也從未解釋一開始為什麼要預設上傳整個專案。「悄悄關掉」可以止血，但無法回頭給出保證。

◆ 「xAI 曾宣稱程式碼不會離開你的電腦」

有不少報導寫「xAI 曾宣稱程式碼不會離開你的電腦」。我們去查了 xAI 在 5 月 25 日的官方發布公告 (https://x.ai/news/grok-build-cli)，並未找到這句話。「本機優先」（local-first）確實是這個工具在發布時被媒體與開發者社群廣泛接受的形象，但我們無法證實那是 xAI 官方的原始文案。所以本文的說法是：普遍印象與實際封包行為之間有落差。

◆ 如果你用過 Grok Build，現在該做什麼

這一段是給工程師朋友的。如果你不寫程式，可以直接跳到下一段。

• 先把金鑰換掉，這件事最急。如果你的專案裡有 .env 或任何存放密碼、API 金鑰、資料庫連線字串的檔案，請假設它們已經外流，全部重新產生一次。刪掉本機的檔案不會讓已經流出去的金鑰失效——這是最多人搞錯的一點。

• 在工具裡輸入 /privacy，關閉資料保留。依 xAI 官方說法，這個動作也會刪除先前已同步的資料。

• 在設定檔加上永久防線：在 ~/.grok/config.toml 裡設定 disable_codebase_upload = true。

• 不要只靠版本號判斷安全。這次的修復是伺服器端遠端切換的——同一個版本的程式，在不同日子可能有不同的行為。版本號在這裡不是可靠的安全指標。

• 檢查 git 修改歷史。就算你現在的檔案裡沒有密碼，如果過去某次提交曾經不小心把密碼寫進去，它仍然存在於歷史裡——而上傳的是完整歷史。

◆ 如果你是「用 AI 寫程式」的人，請一定要看

過去一兩年出現一個新的族群：不是工程師，但會用 AI 寫程式。可能是想做一個記帳小工具、一個報名表單、一個自動整理資料的腳本。你不需要看懂程式碼，只要一直跟 AI 說「幫我加這個」「這裡壞掉了幫我修」，東西就跑起來了。英文社群把這種做法叫做 vibe coding——憑感覺寫程式。

這是好事。它讓做東西的門檻大幅降低，讓很多原本做不出來的人做得出來。

但這次事件暴露了一個很殘酷的落差：你不需要懂程式碼，也能把程式跑起來；可是你不懂程式碼的話，你不會知道 AI 在你的電腦裡放了什麼、那些東西有多敏感。工程師至少知道要保護哪些檔案。vibe coding 的人，往往連那個檔案存在都不知道。

◆ AI 會幫你新增一個裝滿鑰匙的檔案，而你可能沒發現

當你請 AI 幫你「接上 OpenAI 的 API」「連到我的資料庫」「串金流」，它通常會做一件事：建立一個檔名叫 .env 的檔案（名字前面有個點，在很多系統上預設是隱藏的），把你的金鑰、密碼寫進去。

用生活化的說法：AI 幫你在專案資料夾裡放了一串鑰匙。那串鑰匙可以開的門包括——

• 你的 AI 服務帳號：別人拿到可以拿去大量呼叫，帳單算你的。這是最常見的災情，一夜之間刷出幾萬塊不是傳說。

• 你的雲端主機：可以被拿去挖礦、當跳板。

• 你的資料庫：如果你的小工具存了任何人的資料——哪怕只是朋友的 email——那些資料都在裡面。

• 你串接的金流、簡訊、寄信服務：可以被拿去發詐騙簡訊、寄釣魚信，而且發信人是你。

「我只是做個小工具，沒什麼好偷的」——這是最危險的想法。攻擊者要偷的不是你的程式碼，是你的鑰匙。你的程式碼可能真的沒人有興趣，但那把能刷雲端帳單的金鑰，人人有興趣。

◆ 最容易踩的坑：直接在「桌面」或「使用者資料夾」開工

這次事件延燒時，社群上出現一則貼文，說 AI 工具把他整個使用者資料夾都上傳了。討論串裡有人指出：他是直接在使用者資料夾（也就是裝著你所有文件、下載、桌面的那個最上層資料夾）裡啟動工具的——工具會上傳「你在哪個資料夾開工」的所有內容，所以它照做了。

這裡我們不責備使用者。一個工具在第一次執行時就把你整台電腦的文件傳出去，本來就不該是使用者要防的事。但在廠商把事情做對之前，這是你可以保護自己的方式：永遠幫每個專案開一個乾淨的空資料夾，在那裡面做事。不要在桌面、下載、文件的根目錄直接叫出 AI 工具。

◆ 另一個更常見的災難：把金鑰推上 GitHub

老實說，比起「AI 廠商偷偷上傳」，vibe coding 的人更常遇到的其實是這個：把 AI 生成的專案原封不動上傳到 GitHub 公開倉庫，金鑰就寫在裡面。

網路上有自動化程式，二十四小時在掃描 GitHub 上新出現的金鑰，從公開到被盜用往往只要幾分鐘。這不是危言聳聽，是這幾年最穩定的攻擊產業之一。

而且——把檔案刪掉、重新上傳一次是沒有用的。Git 會保留完整的修改歷史，你刪掉的那一版還在裡面，任何人都翻得出來。（這也正是這次 Grok Build 事件的嚴重之處：它上傳的是「完整歷史」，不只是現在的檔案。）

◆ 那我該怎麼做？

• 問 AI 一個問題：「這個專案裡有哪些檔案含有金鑰或密碼？」就這樣問，用白話問。AI 會告訴你。這是你不需要學任何技術就能做的第一步，而且非常有效。

• 接著問：「請幫我建立 .gitignore，把這些檔案排除掉。」.gitignore 是一張「不要上傳的名單」。AI 知道怎麼寫，你只要記得叫它寫。

• 每個專案開一個乾淨的新資料夾。不要在桌面、文件、下載的根目錄直接開工。

• 如果你曾經把專案傳上 GitHub，先確認它是「私人」還是「公開」。不確定的話，直接問 AI：「幫我確認這個倉庫是不是公開的。」如果是公開的，而且裡面有金鑰——立刻去把那些金鑰換掉，不要只是刪檔案。

• 金鑰只要可能外洩過，就換掉。去你申請金鑰的那個網站（OpenAI、Google Cloud、你的資料庫服務商），刪掉舊的、產生一把新的。這個動作叫「輪替」，通常只要點兩三下。刪掉本機檔案不會讓已經流出去的鑰匙失效——只有換鎖才會。

• 幫你的雲端服務設定用量上限與帳單警示。就算金鑰真的被盜，這是你最後一道停損線。

◆ 一個好用的小作法

你不需要懂程式碼，但你可以把 AI 當成你的資安顧問，而不只是你的工人。

每做完一個小工具，多問一句：「這個專案裡有什麼東西是不能給別人看到的？我該怎麼保護它？」你會很驚訝它答得多完整。真正的風險不是 AI 不懂資安——它其實懂——而是沒有人想到要問它。

◆ 更重要的：這不只是 Grok 的問題

如果我們把這件事講成「Grok 很糟，換一個工具就好」，不是那麼全面。

真正的反思是：任何一個能讀取你檔案的 AI 助理，你都無法從介面上知道它實際傳了什麼出去。設定頁上寫什麼，和網路線上實際跑什麼，是兩件需要分別驗證的事。而絕大多數人沒有能力、也沒有義務去側錄自己的封包。

這件事的適用範圍遠比「工程師的程式碼」寬得多：

• 能讀取你雲端硬碟的 AI 助理，讀得到的可能不只是你請它整理的那一份文件。

• 能存取你信箱的 AI 摘要功能，範圍可能是整個信箱，不是你點開的那一封。

• 手機上內建的 AI 功能，「本機處理」和「上傳處理」的界線，往往寫在你沒讀的說明文件裡。

這不是要你不要用 AI 工具。這些工具是真的有用。但「有用」和「知道它拿走了什麼」可以並存——而後者需要你主動去問。

◆ 給每個人的 AI 工具隱私檢查清單

下次要授權一個 AI 工具存取你的檔案、信箱或雲端硬碟之前，花三分鐘想一想：

• 這個工具能讀到的範圍有多大？是「我指定的這一個資料夾」，還是「整個帳號」？

• 那個隱私開關的說明文字，實際上寫的是什麼？是「不用於訓練」，還是「不會上傳」？兩者差很多。

• 我要它處理的資料夾裡，有沒有不相干但敏感的東西？（密碼備份、掃描的證件、財務檔案、個案紀錄）如果有，先移出去。

• 如果我是用 AI 寫程式：這個專案裡有沒有 .env 或其他裝著金鑰的檔案？我問過 AI 了嗎？

• 這個工具有沒有「私密／臨時模式」？處理敏感內容時，優先使用。

• 如果哪天出事，我知道去哪裡撤銷授權、刪除資料嗎？

• 這個廠商過去發生問題時，是主動說明，還是悄悄修掉？（這一題沒有標準答案，但值得列入你的判斷。）

◆ 最後

這起事件裡，那個「不要拿我的資料訓練」的核取方塊，從頭到尾都在那裡，安安靜靜地被勾選著。它沒有壞掉、沒有失效——它只是從來就不管那件事。

設定頁上寫什麼，不等於網路線上跑什麼。這句話，值得你在下一次點「同意」之前想一遍。

如果你正在為自己、為工作單位，或為你服務的對象評估某個 AI 工具的隱私風險，不確定該問什麼問題，歡迎跟我們聊聊 (/contact/)——個人諮詢也可以，歡迎來問。

◆ 參考資料

• cereblab，〈What xAI’s Grok Build CLI Actually Sends to xAI: A Wire-Level Analysis〉，2026/7/10 — GitHub Gist (https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547)（本文主要事實依據）

• Hacker News 討論串 — news.ycombinator.com (https://news.ycombinator.com/item?id=48892468)

• xAI，〈Introducing Grok Build〉，2026/5/25 — x.ai/news (https://x.ai/news/grok-build-cli)

• @SpaceXAI 官方回應，2026/7/13 — x.com (https://x.com/SpaceXAI/status/2076692402442846289)

• Andrew Milich（Grok Build 負責人）回應，2026/7/13 — x.com (https://x.com/milichab/status/2076693464016994685)

• Neowin，〈Elon Musk says SpaceXAI will delete all Grok Build user data following privacy concerns〉，2026/7/14 — neowin.net (https://www.neowin.net/news/elon-musk-says-spacexai-will-delete-all-grok-build-user-data-following-privacy-concerns/)

• International Cyber Digest，2026/7/13 — internationalcyberdigest.com (https://www.internationalcyberdigest.com/xais-grok-build-cli-uploads-entire-git-repositories-to-a-google-cloud-bucket/)

• ByteIota，2026/7/12 — byteiota.com (https://byteiota.com/grok-build-cli-uploads-repo-xai-servers/)

• iThome，〈xAI推出Grok Build，加入AI程式代理工具戰局〉，2026/5/18 — ithome.com.tw (https://www.ithome.com.tw/news/175886)

本文事實查核時間為 2026 年 7 月 14 日。此事件仍在發展中，xAI 的說法與工具行為可能持續變動。

──────────────────────────────
來源：https://ethome.cc/grok-build-code-upload-ai-privacy/
ethome.cc — 生活化的資安科普