AI 代理人失控？Google Antigravity Secure Mode 實戰：在受限沙盒中馴服你的 AI Coding 助理

AI Coding 助理該不該擁有完整權限？

讓 AI Coding 助理握有完整的 Shell、檔案與網路權限，等於把伺服器鑰匙交給一個偶爾會幻想的實習生。正確做法是把它關進受限沙盒，只給完成任務所需的最小權限——Google Antigravity 的 Secure Mode（安全模式）正是為此而生：透過容器化隔離、檔案系統與網路白名單、指令攔截，讓 AI 盡情重構程式碼，卻碰不到 .env、.git 或系統敏感區。

本文用一個 Laravel 專案的實戰情境，帶你把 Secure Mode 從「開關」變成「可稽核的防禦策略」：哪些目錄該唯讀、哪些該拉黑、網路該怎麼鎖、以及當 AI 想執行 rm -rf 時系統如何把決定權交還給你。

嗨，我是 Eric，浪花科技的資深工程師。軟體開發已經從「Copilot 給建議、人類寫 Code」跨入「AI Agent 直接操作 IDE」的 Agentic Era。Antigravity 確實強大，能從零 Scaffold 一個 Laravel 專案、自動補上單元測試。但身為在 production 摔過坑的老鳥，我得嚴肅問你一句：你真的敢讓 AI 擁有你電腦的 Root 權限嗎？

上週聽到一個恐怖故事：某位新手開發者讓 AI Agent「優化專案結構」，結果 AI 認為「刪除所有非必要檔案」是個好主意，把 .env 和 .git 當成暫存檔誤刪。那一刻，他的本地開發環境瞬間回到石器時代。這就是我們今天要聊 Secure Mode 的原因。

為什麼 AI Coding 需要「防爆沙盒」？

像 Google Antigravity 這樣的 AI 代理人，本質上是一個跑在你本機的「執行者」。它不只是生成文字，它會呼叫 Shell Command、讀寫檔案、甚至發送 HTTP 請求。這帶來兩個核心風險：

• 破壞性操作：AI 可能誤解 Prompt，執行了 rm -rf、覆寫關鍵配置檔，或在錯誤的目錄下動手。
• 資料外洩：AI 為了 Debug，可能把你的 API Key 或資料庫連線字串送往外部伺服器分析。這在以「最小權限」為原則的安全模型裡是絕對要堵住的破口。

沙盒的價值在於它把「信任邊界」明確畫出來。傳統上我們對使用者輸入抱持零信任；對自主性越來越高的 AI Agent，同樣的零信任心態才是負責任的工程實務。Secure Mode 利用容器化技術（類似 Docker 但更輕量，基於 gVisor 或 Firecracker 這類隔離層），為 AI 劃定一個受限範圍——在這個圈圈裡 AI 可以盡情玩耍，卻永遠摸不到系統的敏感神經。

沙盒隔離到底擋掉了什麼？

理解防禦的層次，比記住設定檔語法更重要。一個健全的 AI 執行沙盒通常在三個面向設限：

• 檔案系統：限制 AI 看得到、寫得到哪些路徑。
• 網路：限制 AI 能對外連到哪些主機。
• 系統資源與行為：限制 CPU、記憶體、執行時間，以及對高風險系統呼叫（syscall）的攔截。

接下來逐一拆解 Antigravity 在這三個面向的做法。

Antigravity Secure Mode 的運作原理

Secure Mode 不是單純的權限開關，而是一套分層防禦系統。身為工程師，我們需要理解它的設定檔（ag.config.json）是怎麼描述策略的。

1. 檔案系統隔離（File System Isolation）

預設情況下，開啟 Secure Mode 後 AI 只能看見專案根目錄下的檔案。但這還不夠——我強烈建議你進一步切出三個區域：可寫（allow_write）、唯讀（read_only）、完全禁止（deny_access）。三者的優先順序原則是：禁止 > 唯讀 > 可寫，最嚴格的規則應該蓋過寬鬆的規則。

以下是一個標準 Laravel 專案的防護配置範例：

{
  "security": {
    "mode": "strict",
    "filesystem": {
      "allow_write": [
        "app/",
        "resources/",
        "tests/",
        "database/migrations/"
      ],
      "read_only": [
        "config/",
        "composer.json",
        "public/index.php"
      ],
      "deny_access": [
        ".env",
        ".git/",
        "storage/logs/laravel.log",
        "**/*.pem"
      ]
    }
  }
}

這份配置的意圖很清楚：允許 AI 修改業務邏輯（app/）、視圖（resources/）、測試與資料庫遷移檔，但禁止它動核心配置（config/ 設為唯讀），並徹底擋住環境變數（.env）、版本控制中繼資料（.git/）與任何私鑰（**/*.pem）。這就像給實習生開權限：你可以寫 Code，但別想碰我的 Server Config。

設計白名單時的三個原則

1. 從拒絕開始，再開放：預設一律不可寫，只把確定需要的目錄加進 allow_write，而不是反過來「先全開、再補黑名單」。
2. 祕密一律 deny，不只是 read_only：.env、私鑰、token 檔案要放進 deny_access 讓 AI「連讀都不能讀」，避免內容被寫進對話脈絡而外流。
3. 把產出物與來源分離：讓 AI 寫遷移檔（database/migrations/）沒問題，但鎖死它寫不到的快取、日誌與編譯產物，避免它「為了讓測試過」而去動到不該動的東西。

2. 網路白名單（Network Whitelisting）

AI 有時會為了安裝套件而聯網。在 Secure Mode 中，所有對外連線預設都是被阻擋的，你需要明確列出允許的網域。在供應鏈攻擊（Supply Chain Attack）頻傳的當下，這點至關重要——你不會希望 AI 自動下載一個被植入後門的套件吧？

{
  "security": {
    "network": {
      "policy": "whitelist_only",
      "allowed_hosts": [
        "repo.packagist.org",
        "registry.npmjs.org",
        "github.com"
      ]
    }
  }
}

白名單只放任務真正需要的套件來源（這裡是 Composer 的 Packagist 與 npm registry，以及 GitHub）。原則同樣是最小化：每多開一個網域，就多一條潛在的外洩或下毒通道。如果某次任務不需要安裝任何套件，最安全的策略是連 allowed_hosts 都留空，等於完全離線執行。

實戰：在受限環境中執行 AI 重構任務

讓我們模擬一個真實場景：你希望 Antigravity 幫你重構一個龐大的 Controller，但很怕它把整個專案搞爛。

步驟一：以沙盒模式啟動

在終端機中，用 --sandbox 參數啟動 Antigravity，並指定剛才寫好的安全配置：

ag run --task "refactor UserController" --sandbox --config ./ag-secure.json

步驟二：指令攔截（Syscall Interception）

當 AI 嘗試執行 Shell 指令時，Secure Mode 會進行攔截。若指令屬於高風險操作——例如刪除檔案、修改權限，或對未知 URL 發出 curl——Antigravity 會暫停執行，彈出 Human-in-the-loop（HITL）請求，把決定權交還給你。

你會在 IDE 上看到類似這樣的提示：

[Security Alert] Agent 試圖執行：rm -rf ./storage/framework/views/*
原因：清除快取以套用變更。
[允許] / [拒絕] / [在沙盒中模擬]

步驟三：先模擬，再套用

「在沙盒中模擬」會先在一個臨時、用完即丟的 File Layer 上執行，讓你預覽結果。確認沒問題，再按下套用，變更才會落到真實檔案系統。這個「先預演、後提交」的流程，正是 HITL 的精髓：人類保留最終否決權，AI 只負責提案與執行被核准的動作。

把 HITL 用對地方

HITL 不是要你逐條手動點「允許」到崩潰。實務上的訣竅是：讓低風險、可逆的操作自動通過，把人力集中在高風險、不可逆的決策點。哪些該攔、哪些放行，正好對應前面的白名單設計——可寫目錄內的檔案修改可以從寬，但任何刪除、權限變更、對外連線、或觸及 deny_access 範圍的嘗試，都應該強制走 HITL。

進階防護：資源配額與 Time-to-Live（TTL）

有些 AI Agent 會寫出無窮迴圈（Infinite Loop）的程式碼，讓筆電風扇起飛甚至當機。在 Secure Mode 中，我們可以替沙盒設定資源上限：

{
  "resource_limits": {
    "cpu_usage": "50%",
    "memory": "4GB",
    "execution_timeout": "300s",
    "max_file_operations": 1000
  }
}

這幾個參數各自守住一條底線：

• cpu_usage / memory：避免單一沙盒吃光主機資源，把你其他工作一起拖垮。
• execution_timeout：等同於 TTL（Time-to-Live）。超時即終止，是對付無窮迴圈與卡死任務最簡單有效的手段。
• max_file_operations：最有意思的一個。當 AI 在短時間內試圖修改超過設定上限的檔案（往往意味著它「發瘋了」或正在進行毀滅性重構），系統會強制終止程序。這是你的最後一道防線。

Eric 的資深工程師碎碎念

我知道配置這些 JSON 很麻煩，你可能會想：「我只是寫個小功能，AI 不會那麼笨吧？」

但在浪花科技，我們的原則是：永遠不要信任 AI 的自主性，就像永遠不要信任使用者輸入一樣。

Secure Mode 不只是防範 AI 做壞事，更是為了防範「幻覺」（Hallucinations）。模型越強大，往往也越自信；而一個自信但錯誤的 AI，比一個無知的 AI 更危險。建立受限沙盒不是在限制 AI 的能力，而是在保護你的數位資產——讓 AI 在籠子裡跳舞，它依然是個好舞者，但至少不會踩壞你的地板。

延伸閱讀

• Antigravity、Claude Code、Codex 三大 AI Coding Agent 完整比較
• AI 寫 Code 只是基本功？深度解析：AI Coding Agent 的真正價值是當你的『技術決策軍師』
• Cursor AI 其實不是 Copilot 的對手？錯！深度解析：它想當的是你的『大腦外掛』
• 突破 AI 亂講話災難！企業專屬 AI 大腦建置實戰：用 RAG 技術讓 LLM 讀懂內部機密文件