# 你關掉「不要拿我的資料訓練AI」，重要檔案還是被上傳了——Grok Build 事件 > 一位資安研究者用側錄網路封包的方式發現，xAI 的程式碼助理 Grok Build 會把使用者的整個專案資料夾打包上傳到雲端——包含 AI 從來沒讀過、甚至被明確告知「不要打開」的檔案。更麻煩的是，介面上那個看起來理論上是隱私開關的選項，關掉了也擋不住。這件事表面上是開發者的問題，但它揭露的落差，每一個用 AI 工具的人都會遇到。 *資安事件簿 · 更新於 2026.07.15 · 約 16 分鐘閱讀* --- ![Grok ai interface with a question prompt](https://ethome.cc/wp-content/uploads/2026/07/m2ykfuhgxay-edited-1024x576.jpg) ### 本文重點 - 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 金鑰](https://ethome.cc/glossary/api-key/)、資料庫連線字串的檔案，請假設它們已經外流，全部重新產生一次。**刪掉本機的檔案不會讓已經流出去的金鑰失效**——這是最多人搞錯的一點。 - **在工具裡輸入 /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](/glossary/gitignore/) 是一張「不要上傳的名單」。AI 知道怎麼寫，你只要記得叫它寫。 - **每個專案開一個乾淨的新資料夾。**不要在桌面、文件、下載的根目錄直接開工。 - **如果你曾經把專案傳上 GitHub，先確認它是「私人」還是「公開」。**不確定的話，直接問 AI：「幫我確認這個倉庫是不是公開的。」如果是公開的，而且裡面有金鑰——**立刻去把那些金鑰換掉**，不要只是刪檔案。 - **金鑰只要可能外洩過，就換掉。**去你申請金鑰的那個網站（OpenAI、Google Cloud、你的資料庫服務商），刪掉舊的、產生一把新的。這個動作叫「[輪替](/glossary/key-rotation/)」，通常只要點兩三下。**刪掉本機檔案不會讓已經流出去的鑰匙失效——只有換鎖才會。** - **幫你的雲端服務設定用量上限與帳單警示。**就算金鑰真的被盜，這是你最後一道停損線。 ### 一個好用的小作法 你不需要懂程式碼，但你可以**把 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 的說法與工具行為可能持續變動。* --- 來源：[你關掉「不要拿我的資料訓練AI」，重要檔案還是被上傳了——Grok Build 事件](https://ethome.cc/grok-build-code-upload-ai-privacy/) ethome.cc — 生活化的資安科普