0DIN 最近展示了一個很值得開發團隊認真看的攻擊：一個看起來乾淨的 repo，可以誘導 Claude Code 在排錯流程裡跑出反向 shell。重點不是「Claude Code 很危險」這種簡化結論，而是 agentic coding 工具終於碰到真正的產品化問題：它不是只在補全程式碼，它正在替人操作一台有權限、有祕密、有網路出口的電腦。

這件事代表的不是 AI coding 要停下來，而是採用方式要從「相信模型」改成「限制執行環境」。

很多人會把這類事件理解成 prompt injection 的又一個案例。這沒有錯，但還不夠。真正麻煩的是攻擊鏈不需要在 repo 裡放明顯惡意程式碼。agent 讀到正常文件、嘗試安裝依賴、遇到錯誤訊息、照著錯誤訊息跑初始化指令，最後 payload 可能從 DNS TXT 這類間接通道取回來。每一步看起來都像開發者平常會做的事，合起來才變成入侵。

所以錯誤理解是：只要 review 程式碼、只要模型比較聰明、只要多問一次確認，就能解決問題。

比較務實的看法是，agentic coding 的風險邊界不在「它看到了什麼」，而在「它能做什麼」。只要 agent 可以讀環境變數、執行 shell、連外網、改檔案、使用開發者的 GitHub token，它就不只是文字工具，而是半自動化操作員。這時候安全設計不能停在提示詞規範，而要回到作業系統、容器、網路、權限與審計。

誰該在意？第一是讓 AI agent 處理陌生 repo 的工程師。第二是導入 Cursor、Claude Code、Codex、Cline 這類工具的公司。第三是有大量 API key、雲端權限、客戶資料或內部套件權限的團隊。對這些人來說，問題不是 agent 會不會犯錯，而是犯錯時它能不能順手帶走公司真正值錢的東西。

採用建議很直接：不要把未信任專案丟進有完整個人權限的本機環境。比較穩健的做法，是把 AI coding agent 放在 disposable container、devcontainer、VM 或遠端沙盒裡跑；預設不掛載真實 SSH key、雲端憑證與長效 token；網路出口要能限制，至少對陌生專案關掉任意連外；高風險指令不只要問「要不要執行」，還要顯示它會碰到哪些檔案、環境變數與網路目的地。

團隊層面也要調整驗收標準。以前評估 AI coding 工具，常看它能不能改得快、測試能不能過、上下文理解好不好。現在還要加幾個問題：能不能隔離執行？有沒有完整 audit log？能不能設定 allowlist？能不能阻止 agent 讀取敏感檔？能不能把「讀、寫、執行、連網」拆成不同權限？

結論不是少用 AI agent，而是不要用個人筆電當 agent 的裸奔沙盒。AI coding 會繼續變強，也會越來越像 junior engineer 加上自動化腳本。既然如此，管理它的方式就不該像管理聊天機器人，而要像管理一個會跑命令的外包程序：給它任務，給它邊界，給它一次性環境，別給它整串鑰匙。