新聞

資安業者Pillar公開一系列AI程式代理安全研究，指出Cursor、OpenAI Codex CLI、Google Gemini CLI及Antigravity等開發工具，出現多條可跨越沙箱邊界的途徑。多數案例並非AI代理直接突破沙箱，而是先在程式專案資料夾內建立或修改檔案，再由沙箱外的開發工具或Git功能執行，另有案例是代理透過位於沙箱外的Docker服務，在特定設定下間接取得主機操作能力。

沙箱是限制AI代理只能在指定目錄及權限範圍內活動的隔離機制。不過，現代開發工具會自動讀取專案中的設定、尋找Python執行環境、檢查Git儲存庫，或依設定啟動工作。當AI代理可以修改這些檔案，沙箱外的程式便可能把代理產生的內容當成可信任指令執行。

Cursor已被確認的一項高風險問題，是允許代理更換專案內Python虛擬環境的執行檔。Cursor內建的Microsoft Python擴充套件之後會在沙箱外執行該檔案，使攻擊指令取得使用者權限，並可修改專案目錄外的檔案。這項問題影響3.1.2以前版本，已在3.1.2修補。

另一項Cursor漏洞涉及專案內的自動執行指令設定。惡意專案或AI代理建立的設定檔，可在一次代理作業結束時執行本機命令，過程不會另外要求使用者核准。該漏洞編號為CVE-2026-48124，影響Cursor Desktop 2.4.37，已在3.0.0修補。

Docker也可能成為越過沙箱的管道，Cursor安全公告指出，在macOS上以Auto-Run Sandbox模式執行代理，且電腦安裝Docker Desktop與Dev Containers CLI、允許代理使用網路時，代理可能啟動具有特權模式的容器，透過Docker Desktop的VirtioFS機制取得使用者家目錄的讀寫能力，並在未出現額外權限提示的情況下，以使用者權限執行主機命令。

Codex CLI的問題則出在免除核准的安全命令清單。系統原本只依命令名稱判斷風險，未完整檢查附帶參數及實際作用，使看似只讀取內容的Git命令也能改寫設定，並在使用者後續操作時執行外部程式。Pillar表示，OpenAI已在Codex CLI 0.95.0修補這項問題。

研究團隊建議，代理建立的設定檔應視為未受信任內容，相關指令也應套用與代理相同的權限檢查及使用者核准機制。