Agent 誤刪專案的慘劇可以避免：Google Antigravity 三道防線配置實戰
☰ 目錄 table-of-contents.md
所謂 Agentic IDE，本質上就是把終端機和檔案系統的鑰匙交給 AI——Google Antigravity 給它的幾乎是上帝視角：能敲指令、能讀寫專案，自然也就能誤刪與外洩。我的做法是用三道防線把 AI 的權限關進籠子：專案層級的權限白名單、拋棄式沙盒隔離，以及「人類介入迴圈」的審核機制。下面逐項帶你配置，讓 AI 幫你做事，但奪不走你的方向盤。
本文以 Google Antigravity 為示範環境，但其中的安全心法（最小權限、隔離執行、人工審核）適用於任何具備執行權限的 AI 代理工具。
嗨，我是 Eric，浪花科技的資深工程師。如果你的 IDE 還停留在 2024 年那種「你問它答」的 Copilot 時代，那你可能還沒意識到 2026 年的今天，我們正面臨著什麼樣的風險。
自從 Google Antigravity 成為主流開發環境後，我們終於解放了雙手。Agentic IDE 不再只是補全程式碼，它能直接操作終端機（Terminal）、讀寫檔案系統，甚至幫你部署 Docker 容器。這聽起來很美好，對吧？直到上週，我看到我們公司的一位實習生，眼睜睜看著他的 AI 代理人為了「清理暫存檔」，順手執行了一行 rm -rf ./src/*，然後還很有禮貌地回報：「任務已完成，環境已清理。」
那一刻，辦公室的空氣都凝結了。雖然有 Git，但那些還沒 Commit 的 3 小時心血直接化為烏有。
這就是 2026 年開發者必須面對的全新課題——開發者風險管理。當 AI 擁有對你電腦的「上帝視角」與執行權限時，你該如何確保它不會變成破壞王？今天這篇文章，不談虛無縹緲的理論，直接帶你實作 Google Antigravity 中的指令與檔案操作安全防禦策略。
從 Copilot 到 Agent：為什麼風險指數呈幾何級數上升？
在舊時代的 VS Code + Copilot 模式中，AI 的產出僅限於「編輯器」視窗內。它建議了一段爛 Code，你只要不存檔、不執行，它就傷害不了你。那是一個「被動諮詢」的時代。
但 Google Antigravity 是「主動執行」的。為了實現 Vibe Coding（氛圍編碼）和全自動除錯，Antigravity 預設會請求終端機的存取權限。差別在哪？關鍵在於「副作用（Side Effects）」：被動建議的 AI 只會產生文字，主動執行的 AI 會直接改變你的檔案系統、套件相依關係，甚至對外網路連線。一旦這些動作出錯，往往是不可逆的。
具體來說，主動執行型 Agent 帶來三類新風險：
- 檔案操作風險：AI 可能誤判檔案的重要性而進行覆寫或刪除，尤其是尚未 Commit 的暫存變更。
- 指令執行風險：AI 可能為了安裝套件，執行了來源不明的 npm install scripts，或者修改了系統層級的 config。
- 資料洩漏風險：AI 可能將含有 API Key 的
.env檔案內容作為 Context 傳送給第三方插件。
這三類風險背後其實是同一個資安老原則被打破了——最小權限原則（Principle of Least Privilege）。我們從來不會給一個新進員工 root 權限，卻常常一鍵把整台電腦的執行權交給一個會「產生幻覺」的 AI。下面三道防線，本質上就是把這個老原則重新套回 Agent 身上。
所以，別再讓你的 Agent 在「裸奔」狀態下工作了。以下是三個我在專案中強制實施的安全配置。
第一道防線：用 .antigravity/permissions.json 白名單鎖死權限
Google Antigravity 引入了專案層級的權限控制檔，這有點像是 Android App 的權限宣告。很多開發者為了方便，直接設為 "mode": "unrestricted"，這跟把家裡大門打開請小偷進來沒兩樣。
建議的基準配置
在你的專案根目錄下，檢查或建立 .antigravity/permissions.json。我建議的標準設定如下：
{
"version": "2.0",
"file_system": {
"scope": "project_only",
"protected_paths": [
".env",
".git/",
"config/production.json"
],
"allowed_actions": ["read", "write", "create"],
"require_approval_for": ["delete"]
},
"terminal": {
"allow_sudo": false,
"blocked_commands": [
"rm -rf /",
"mkfs",
"shutdown",
":(){ :|:& };:"
],
"network_access": {
"allow_domains": ["npm.pkg.github.com", "registry.npmjs.org"]
}
}
}這段配置在防什麼？
- 鎖定敏感檔案（
protected_paths）：AI 無法讀取或修改.env和 Git 目錄，直接從源頭切斷「機密被當成 Context 外傳」的路徑。 - 限縮活動範圍（
scope: project_only）：AI 的檔案操作被框死在專案資料夾內，碰不到你家目錄底下的其他東西。 - 刪除需審核（
require_approval_for: delete）：AI 可以寫程式碼、可以新增檔案，但只要動作是刪除，IDE 就會彈出視窗要求你按 Y 確認。寫入和刪除被刻意分級，正是因為刪除往往不可逆。 - 禁止危險指令（
blocked_commands）：直接封殺sudo權限與毀滅性指令，連經典的 fork bomb:(){ :|:& };:都列入黑名單。 - 收斂網路出口（
allow_domains）：只放行可信的套件來源網域，降低 AI 被引導去拉取惡意來源的機會。
實務上的小提醒
白名單（明確列出可做的）通常比黑名單（列出禁止的）更安全，因為黑名單永遠列不完。上面的 blocked_commands 是補強性質的「保險絲」，真正撐住安全底線的是 scope 與 require_approval_for 這類「預設拒絕」的設計。別把希望全押在黑名單上。
第二道防線：用「沙盒模式（Sandbox Mode）」隔離高風險操作
如果你正在開發一個需要大量系統操作的腳本（例如自動化部署工具），上面的白名單可能會讓 AI 綁手綁腳。這時候，千萬不要解開權限，而是應該使用 Antigravity 內建的「Ephemeral Sandbox（拋棄式沙盒）」。
這是一個基於 WebAssembly 和微型 VM 的技術。當你開啟沙盒模式時，AI 看到的是一個虛擬的檔案系統。它可以盡情地 rm -rf，搞壞了只要按一個「Reset」鍵，你的實體硬碟毫髮無傷。
核心觀念是「爆炸半徑（Blast Radius）」：把可能出錯的操作關進一個用完即丟的環境，就算它徹底失控，受損範圍也僅限於那個拋棄式容器，而不會波及你的真實專案與系統。
在 Antigravity 的 Command Palette（Cmd+Shift+P）中，輸入：
> Antigravity: Start Session in Isolated Container這對於測試那些「你看起來有點怕怕的」Shell Script 特別有用。身為資深工程師，我的習慣是：只要涉及到檔案系統的批量操作，一律先在沙盒跑一次。確認 AI 的計畫和實際行為一致，再放到真實環境執行。
第三道防線：用「人類介入迴圈（Human-in-the-Loop）」守住最後關卡
技術防線再強，也比不上人類的直覺。Google Antigravity 允許我們設定 AI 的「自主層級（Autonomy Level）」。
在 settings.json 中，我建議將開發環境設定為「協作模式」而非「全自動模式」：
"antigravity.agent.autonomyLevel": "collaborative",
"antigravity.agent.confirmations": {
"terminalExecution": "always",
"fileModification": "on_save",
"dependencyInstallation": "always"
}這個設定的核心邏輯是：AI 可以幫我寫 Code，但要「執行」任何改變世界的動作（安裝套件、跑指令），必須經過我點頭。注意它的分級——fileModification 設為 on_save（一般編輯不打擾你），但 terminalExecution 和 dependencyInstallation 都設為 always，因為這兩者最容易製造不可逆的後果。
雖然這會讓你多按幾次 Enter，但在 2026 年這個 AI 幻覺（Hallucination）仍未完全根除的年代，這就是你的保命符。我看過太多案例是 AI 為了修一個 Bug，擅自升級了專案的 Node.js 版本，導致整個專案的相依性地獄。
三道防線怎麼互補？
很多人會問：有了白名單，還需要沙盒和人工審核嗎？答案是三者守的是不同層次：
- 白名單（permissions.json）：事前限制——規定 AI 「能碰什麼」。
- 沙盒（Sandbox）：事中隔離——把「不確定會不會出事」的操作關進安全箱。
- 人工審核（Human-in-the-Loop）：臨門攔截——在不可逆動作真正發生前，留一個人按下確認的機會。
縱深防禦（Defense in Depth）的精神就是不依賴單一防線。任何一道被繞過，後面還有人在守。
Eric 的小囉嗦：別把方便當隨便
我知道，大家用 AI 就是為了圖快。Antigravity 的強大在於它模糊了 IDE 和工程師的界線，但這也模糊了「責任」的界線。
當 AI 搞砸了你的環境，主管不會聽你解釋說「是 Gemini 做的」。Git log 上顯示的 Author 還是你的名字。做好風險管理，配置好這些安全防線，不僅是保護專案，也是保護你作為工程師的專業信譽。
記住，AI 是最強的副駕駛，但方向盤永遠要握在你自己手裡。
需要團隊導入協助？
浪花科技專注於 2026 最新 AI 開發流程與資安防護。無論是團隊導入 Google Antigravity 的安全培訓，還是企業級的程式碼風險管理，我們都能提供協助。立即填寫表單聯繫我們。
延伸閱讀
常見問題
Agentic IDE 為什麼比傳統 Copilot 的風險更高？
如何防止 AI 代理人誤刪檔案或執行危險指令？
拋棄式沙盒模式有什麼用？什麼時候該用？
什麼是 AI 代理人的人類介入迴圈（Human-in-the-Loop）？
白名單、沙盒、人工審核三道防線有什麼差別？
訂閱免費電子報
把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧，整理成電子報寄給你。只寄精選內容、不灌垃圾信，一鍵就能退訂。