Grok Build 是 xAI 放進終端機的 Coding Agent，核心用 Grok 4.5 搭配本機檔案讀取、Shell、搜尋與程式修改工具，可理解專案、改碼、測試甚至操作 Git。這次爭議是使用者聲稱，它把整個 user directory 傳到 xAI 伺服器，當中包含 SSH keys、密碼管理器資料庫、文件與照片。目前公開證據主要是一則 X 貼文，尚未看到 xAI 的事故說明，因此只能確認「有人提出具體指控」，不能直接認定所有 Grok Build 安裝都會自動上傳家目錄。

現實應用

這類工具適合開發者做 repo 導覽、跨檔重構、測試、Code Review 與 CI 自動化；但也正因為它能讀檔和執行指令，開發機上的憑證、客戶資料、.env 與個人文件都可能進入可觸及範圍。個人 Side Project 還能靠隔離環境控管，企業、接案團隊與維運人員則應先建立權限政策，不能把它當一般聊天機器人使用。

期望評估

我認為低標期望，是這起事件會逼使用者養成「只在專案目錄啟動 Agent」的習慣，並用 sandbox、容器或獨立帳號隔離秘密。高標期望則是 xAI 補上預設拒絕家目錄、上傳前顯示檔案清單與資料量、敏感檔案偵測及可稽核紀錄。若仍靠使用者自己讀文件避險，我猜相同問題還會重演。

商業策略分析

我認為最受影響的是 xAI 的企業採用與資安信任，而 Claude Code、Codex 等競品也會被用同一標準檢查。Coding Agent 的競爭已不只模型答得好不好，而是權限預設、資料保留與管理端能否真正鎖死高風險模式。企業值得跟進功能，但應先做 DLP、最小權限與 Zero Data Retention 評估；沒有隔離環境就不該碰正式憑證或客戶程式碼。

實作細節

官方安裝方式是 curl -fsSL https://x.ai/cli/install.sh | bash，接著進入專案目錄執行 grok。已知風險是官方文件顯示 sandbox 預設為 off，可讀寫範圍不受限制；建議從乾淨工作目錄啟動，搭配 --sandbox strict、--permission-mode dontAsk 與明確 deny 規則。若懷疑秘密已外傳，應立即撤銷並輪替 SSH keys、API keys 與密碼，而不是只刪對話。

延伸連結

• 原始 X 貼文
• Grok Build 官方介紹
• Grok Build 安裝文件
• 官方安全、Sandbox 與資料生命週期說明
• xAI 隱私政策

註：原文全文只有單一使用者貼文，缺少可獨立驗證的技術紀錄與 xAI 回應，資料來源有限。