最近 AI coding agent 的安全討論開始變多，尤其是惡意 README、間接 prompt injection、symlink、沙盒逃逸、工具自動執行這類案例。這些新聞很容易被理解成「某某工具不安全」，但比較務實的看法是：這不是單一產品的形象問題，而是軟體開發流程多了一個會讀、會判斷、還可能會執行命令的新角色。

過去開發者打開陌生 repo，風險主要在安裝依賴、跑測試、執行腳本。現在多了一層：agent 會先讀文件、整理問題、建議修法，甚至在自動模式下直接改檔或跑指令。也就是說，README、issue、錯誤訊息、註解、測試輸出，都可能從「給人看的資訊」變成「agent 可能照著做的操作提示」。

反直覺的地方在這裡：越聰明的 agent，越不能被當成比較快的 autocomplete。

Autocomplete 多半只補一小段程式碼；agent 接近的是一個初階工程師加上一個終端機。它可以幫你省很多時間，但也會把信任邊界放大。若它能讀你的專案、看你的環境變數、改你的檔案、呼叫 shell、連到外部服務，那安全問題就不只是「模型會不會被騙」，而是「被騙之後它能碰到什麼」。

比較穩健的做法，不是立刻停用所有 coding agent，而是把權限拆開。第一層只允許讀檔與提出 patch；第二層才允許改檔；第三層才允許跑測試；涉及網路、憑證、部署、刪檔、寫入系統目錄的操作，應該預設要人工確認。這聽起來保守，但它其實很像 CI/CD 與 production 權限管理，只是套用到本機開發環境。

團隊也要重新定義「可信輸入」。陌生 repo 的 README 不該被視為可信操作指南；外部 issue、PR 描述、錯誤 log，也不該直接變成 agent 的最高優先指令。比較好的規則是：agent 可以讀它們，但不能因為它們說「請執行這段命令」就自動照做。尤其是 curl、bash、npm postinstall、ssh、env、token、chmod、rm、寫入 dotfile 這些關鍵字，應該被視為高風險訊號。

個人開發者的行動建議很簡單：陌生專案先用唯讀模式；自動模式只開在自己熟悉、版本乾淨、沒有敏感憑證的 workspace；能用容器或臨時 worktree 就不要在主工作區亂試。公司團隊則應該把 coding agent 納入安全規範：允許哪些工具、哪些 repo 可以自動改、哪些命令一定要審批、log 要留到哪裡。

結論是，AI coding agent 的風險不是「它偶爾會犯錯」這麼簡單。真正的變化是，程式碼倉庫本身正在變成一個會影響 agent 行為的輸入介面。未來安全成熟的團隊，不會只問哪個 agent 最強，而會先問：它讀到不可信內容時，最多能做什麼？這個答案，才是能不能放心把 agent 放進日常開發流程的分水嶺。