三大 AI 程式代理存在共通信任風險，惡意 GitHub 議題可影響後續執行

資安業者 Novee Security 分析了 Anthropic Claude Code、Google Gemini CLI 與 OpenAI Codex 三套 AI 程式開發代理的自動化工作流程，發現它們雖各自採用不同的安全機制，仍在工具權限、沙箱隔離及共享工作區等環節出現共通的信任落差。攻擊者可透過 GitHub 議題送入惡意內容，進而影響代理的執行行為；研究展示的攻擊方式包括遠端程式碼執行、機密資料外洩，以及對後續代理的持續控制。

這類攻擊的核心是「間接提示注入」。與使用者直接輸入惡意指令不同，攻擊者把指令藏在代理會讀取的資料中——在這個案例裡就是 GitHub 議題的內容。當代理被指派去處理某個議題，它必須讀取議題敘述才能理解任務；而模型在處理文字時，難以可靠地區分「這是待處理的資料」與「這是要執行的指令」。攻擊面因此從使用者的輸入框，擴大到代理接觸的所有外部內容。

真正把風險放大的是自動化工作流程。當 AI 代理被接進 CI/CD 或議題自動處理流程，整條鏈路上不再有人類逐步審核——議題進來、代理讀取、代理執行、產出程式碼或修改設定。任何一個環節被污染，後果都會自動傳遞下去。研究中最值得警惕的是「持續控制後續代理」這一項：攻擊者一旦在共享工作區留下痕跡，後續由其他代理執行的任務也可能被影響，形成跨工作階段的持久性。

三套工具的共通性說明了問題的本質。不同廠商採用了不同的權限模型與沙箱設計，卻仍出現同類型的落差，代表這不是個別實作的疏漏，而是當前代理架構的結構性課題——只要模型需要讀取外部內容，並且具備執行工具的能力，這兩者之間的信任邊界就必然存在缺口。

實務上的緩解方向已相對清楚。第一是最小權限：代理能觸及的憑證、檔案與網路範圍應嚴格限縮，特別是絕不讓處理外部輸入的代理持有生產環境憑證。第二是輸出審查：代理產生的程式碼變更應維持人工審核關卡，不應直接合併。第三是工作區隔離：每個任務使用獨立、用完即棄的工作區，避免跨任務污染。第四是出站流量控管，降低資料外洩的可行路徑。

對企業而言，這份研究的時機值得注意——正值 AI 程式代理從實驗性工具轉為日常開發流程一環的階段。導入節奏若快於安全機制的成熟度，風險便會實質累積。

後續觀察重點包括：三家業者針對這些落差的修補進度、代理權限模型是否出現業界共通規範，以及開源社群對於機器可讀內容的信任標準討論。