有一個事實應該會改變你對代理安全的理解方式：2026 年 7 月，研究人員突破了四款被廣泛使用的 AI 程式代理——Cursor、Codex CLI、Gemini CLI 與 Antigravity——而他們一次都沒有打破沙箱。

那七項已揭露的問題，沒有任何一項直接擊敗沙箱。它們全部利用了同一件事：沙箱限制的範圍，與沙箱之外某個受信任的元件後來所讀取、執行或掃描的內容之間，存在一道落差。

如果你已經鎖緊了「接上代理的東西」——工具描述、你貼進去的那些伺服器——那些工作是實在的，但它並沒有涵蓋這裡。這是另一半：不是你接上了什麼，而是代理接上之後能做什麼。

這個模式有名字：信任交付（the trust handoff）

雲端安全聯盟（CSA）針對這次揭露的研究報告說得很直白：「一個沙箱的強度，取決於它下游所有東西所做的假設。」

代理不需要逃逸。它只需要寫下某樣東西，而那樣東西之後會被其他東西信任。接著那個受信任的元件就會代替它、在邊界之外、用你的權限執行它。

看看這每一項有多麼平常：

  • Cursor，CVE-2026-48124（CVSS 8.5）。 一個由工作區控制的 .claude/settings.local.json「Stop」hook，會在每一輪代理結束時自動執行一個未受沙箱隔離的本機指令。沒有任何核准提示。已於 3.0.0 修補。
  • Codex CLI，「GitPwned」（CVSS 8.6）。 安全指令允許清單只信任了 git show 這個名稱，卻沒有對它的參數建模。git show --output=./.git/config 寫入了一個惡意的外部 diff 工具項目，並在受害者下次執行 git diff 時以完整的使用者權限執行。已於 0.95.0 修補。
  • Cursor「DuneSlide」，CVE-2026-50548 + CVE-2026-50549（各為 CVSS 9.8）。 經提示注入的指令操縱了工作目錄與符號連結的驗證邏輯，覆寫了沙箱輔助程式本身。已於 3.0 修補。
  • Antigravity。 代理在沙箱內寫入了一份 .vscode 任務設定；主機端在該產品的 Secure Mode 邊界之外執行了那個任務。Google 將其歸類為「其他有效安全漏洞」，且在揭露時尚未修補。
  • Cursor、Codex CLI、Gemini CLI。 一個具備特權的本機 Docker socket，變成了其他受限制代理也能觸及、不受沙箱隔離的執行環境——掛載 VirtioFS 共享目錄，取得家目錄的讀寫權限。

再讀一次這些案例，注意其中少了什麼：沒有惡意軟體、沒有憑證竊取、沒有零時差漏洞。 每一件都是代理寫了一個檔案，然後某個受信任的東西讀了它。

那一個完全不需要漏洞利用

如果沙箱突破聽起來像別人的問題——你不跑帶 hook 的 IDE 代理——那接下來這個就是獨立開發者的版本。

GitLost（Noma Labs，2026-07-06 揭露）的目標是 GitHub 的 Agentic Workflows。一個工作流程會在 issue 被指派時觸發、讀取 issue 的標題與內文，再用代理的留言工具張貼回覆。為了把這件事做好，團隊給了代理組織內每一個儲存庫的讀取權限——包括私有儲存庫。

攻擊者開了一個看起來像例行內部請求的公開 issue。內文裡用平白的英文藏了一段指令，要求代理去取出某個私有儲存庫裡的檔案，並把內容貼進回覆。代理照做了。私有原始碼，幾分鐘內被公開貼出。

要利用它，你需要：沒有寫程式的技能、沒有憑證、沒有帳號。只要能開一個 issue 就行。

GitHub 是有防護的——預設唯讀 token，加上在張貼前掃描代理的輸出。Noma 像攻擊者那樣反覆調整措辭，最後發現那道防護被一個詞破了：在注入指令前面加上 「Additionally」，就能讓模型把一次劫持當成合理的後續任務，而不是該拒絕的東西。

截至發表時，仍然沒有程式碼層面的修補。這類提示注入基本上無法靠修補解決，因為根本原因不是一個 bug——而是模型無法可靠地區分「來自主人的指令」與「埋在它讀取的內容裡的指令」。

為什麼這特別落在獨立開發者身上

企業級事故佔了新聞版面，但讓 GitLost 得以成立的那個設定，正是獨立開發者會憑直覺採用的設定——而且基於完全合理的理由：

  • 你只有一個人，所以廣泛的權限很方便。 一個能看全部的 token，勝過五個你得輪替的受限 token。
  • 你跑得快，所以你設定一次範圍，之後再也不回頭看。 你某個星期二貼進去的那把金鑰，到了十一月還在。
  • 你沒有第二道防線，所以沒有別人會發現那個異常。 團隊有審查步驟；你只有一個正在跑的代理和一個截止日。

⚠️ 而且這是誠實的部分，沒有廠商頁面會告訴你： 上述大部分問題的解法不是買東西或升級方案，而是你必須放棄一些便利。 一個有範圍、會過期的憑證，比長期有效的憑證更麻煩。一份目的地位址允許清單，比開放外連更麻煩。如果你在找一種「既完全開放又安全」的做法，那個設定並不存在。

值得帶走的那個重新框架

注意這些事故彼此之間——以及與 MCP 信任問題之間——有什麼共同點：

你接上了什麼      →  你在設定時所信任的工具描述
代理碰得到什麼    →  你授予的長期存取權，以及它能寫下什麼

它們是同一個問題的兩半：我交出了什麼，而那份交付又延伸到誰手上？

代理的影響範圍不是代理行程本身，而是代理能寫下、且之後會被其他東西信任的一切。 這句就是該記住的話，因為它把你的注意力從模型——你無法稽核的那部分——移到了邊界上，而邊界是你稽核得了的。

檢查你自己的設定

這是一個大約兩分鐘就能測的說法：

為你自己的曝險程度打個分

六個關於你目前實際上線設定的敘述。勾選符合的項目。這裡不會送出任何資料——計分完全在你的瀏覽器裡完成。

你的曝險分數: 0 / 10

還沒勾選任何項目。把所有符合你設定狀況的敘述都勾起來。

分數對應的是處理優先順序，不是恐慌清單。長期有效的憑證是單一投報率最高的修正——它正是把一個被侷限的錯誤變成一道敞開大門的那個因素。

這週可以做的兩件事

1. 讓某樣東西過期。 找出任何代理碰得到、效期最長的那組憑證，給它一個輪替日期。這是唯一能同時對付上述所有變體的改動。

2. 移動信任邊界，而不是模型。 對那個會碰觸不受信任輸入的工作流程——公開 issue、爬來的頁面、使用者提交的表單——問它：這個特定的代理碰得到什麼？然後把它縮到只剩那些。讓讀取不受信任公開輸入的代理，遠離那些碰觸私有資料的代理，並把每一個 issue、PR 與留言都當成惡意輸入，直到證明不是為止。

這兩件事都不需要一支安全團隊。兩件都要求放棄一點便利——而那正是這整類漏洞的真正代價，也是它為何一再發生的原因。

容器化只是更大轉變裡的「安全」那一半——一個獨立開發者現在每天到底在做什麼：〈監督者世代〉講從「寫程式」變成「指揮程式」，〈無限長的待辦清單〉講為什麼 AI 讓清單變長而不是變短，〈AI 帳單在漲〉講價目表沒動、電錶卻動了的那件事。

容器化限制的是觸及範圍，它本身並不決定代理可以做什麼。那是另一個判斷，而且是逐動作判的：哪一個答案，你可以直接照著行動？——分類依據是可逆性與影響範圍，不是你對模型的信任。

資料來源

  • 雲端安全聯盟（Cloud Security Alliance）——《AI Coding Agent Sandbox Escapes: The Trust Handoff Flaw》（研究報告，2026-07-22）。 ——Pillar Security 的「沙箱逃逸之週」：橫跨 Cursor、Codex CLI、Gemini CLI 與 Antigravity 的七項問題；「那七項已揭露的問題，沒有任何一項打破了沙箱本身。」 以及「沙箱的強度取決於其下游所有東西的假設」這個框架，還有上文引用的具體 CVE、CVSS 分數與修補版本。（註：CSA 標示此報告為 AI 輔助的快速研究，未經 CSA 官方審查流程。）
  • Pillar Security——〈The Week of Sandbox Escapes〉（2026-07-20 起）。 ——第一手揭露系列；每天一條跨越邊界的不同路徑。Pillar 自己的總結：「代理的影響範圍不是代理行程；它包含代理能寫下、且主機之後會信任的一切。」
  • Noma Labs——〈GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos〉（2026-07-06）。 ——GitHub Agentic Workflows 的提示注入鏈：公開 issue → 組織級讀取 token → 內容被貼成公開留言。「Additionally」防護繞過，以及不需要任何憑證或寫程式技能即可利用的發現。報導指出發表時仍未修補（The Register，2026-07-07）。
  • BleepingComputer（2026-07-21）——〈Cursor, Codex, Gemini CLI, Antigravity hit by sandbox escapes〉。同期報導，證實四款受影響的代理，以及這些發現並未打破沙箱的性質。