AI 編碼助手正變得越來越智慧，但它們的信任半徑也成了一把雙刃劍。Tenet Security 本週公佈了一種名為 AgentJacking 的攻擊手法，專門針對那些能主動讀取錯誤報告並自動修復程式碼的 AI 程式設計代理。攻擊者不需要黑進你的 IDE，只需要往程式碼倉庫裡塞一個偽造的 Sentry 錯誤頁面——AI 代理就會乖乖替你把惡意程式碼寫進專案裡。
攻擊路徑：錯誤報告的逆向濫用
一切始於開發者再熟悉不過的 Sentry 錯誤報告。當程式碼丟擲異常時，Sentry 會生成包含堆疊跟蹤和環境資訊的詳細頁面。AI 編碼代理（如 GitHub Copilot 的自動修復模式、Cursor 的 Agent 功能）被賦予讀取這些報告並自動生成修復程式碼的能力。AgentJacking 的巧妙之處在於：攻擊者將惡意指令嵌入到一個完全虛假的 Sentry 頁面中，而代理無法區分真假——它看到的只是一個「高層次錯誤描述」，然後按照提示（其實是攻擊者的命令）修改程式碼。
舉個例子：攻擊者偽造一個「資料庫連線池耗盡」的錯誤，並在錯誤詳情裡附上「修復建議」，比如修改連線字串中的密碼或新增一個後門函式。代理信任這個權威的錯誤來源，會直接應用「修復」。整個過程不需要開發者手動批准（取決於代理的自動化程度），因此惡意程式碼可以悄然潛入。
為什麼難以被察覺
傳統安全工具如 SAST、DAST 主要掃描程式碼中的已知漏洞模式，但 AgentJacking 注入的程式碼看似完全合法——它只是修改了某個配置值或增加了一個看似無害的函式呼叫。更糟的是，偽造的錯誤頁面可以託管在合法域名下（通過子域名接管或雲端儲存），甚至可以偽裝成內部服務錯誤。AI 代理的決策過程是黑盒的，開發者事後很難回溯為什麼代理會做出某個修改。
Tenet Security 在測試中成功讓多種主流編碼助手（包括基於 GPT-4o 和 Claude 的代理）執行了危險操作，例如：
- 在登入模組中追加密碼明文記錄
- 修改資料庫查詢以洩露使用者資料
- 將 API 金鑰傳送到攻擊者控制的伺服器
這不是提示注入，是「環境劫持」
很多人第一時間會想到提示注入（prompt injection），但 AgentJacking 的運作方式不同。提示注入直接篡改輸入給模型的文字，而 AgentJacking 攻擊的是代理的 工具使用鏈路——代理呼叫讀取錯誤頁面的函式，然後根據頁面內容生成程式碼。即使模型本身沒有注入漏洞，它的輸出也被不良的上下文汙染了。這類似於瀏覽器中的跨站請求偽造（CSRF），但針對的是 AI 代理。
對於開發團隊來說，這暴露了一個被忽視的攻擊面：任何 AI 代理被動讀取的外部資源（錯誤報告、日誌、文件、Issue 回覆）都可能成為攻擊載體。只要代理「信任」這些來源，攻擊者就能間接操控它的行為。
短期緩解與長期展望
目前沒有一鍵修復的銀彈。Tenet Security 建議開發者：第一，限制 AI 代理的自動化許可權——至少要求在應用程式碼修改前進行人工稽覈（「代理建議」模式優於「自動執行」）；第二，對代理讀取的外部內容進行來源驗證（例如只讀取簽名後的錯誤報告）；第三，監控代理的修改行為，並與已知正常模式做對比。
長遠來看，AI 編碼工具需要內建上下文完整性檢查：代理應該具備基本的「懷疑能力」，比如發現錯誤詳情中出現明顯的程式碼修改指令時，應暫停並詢問使用者。同時，安全社羣需要為 AI 代理的輸入輸出建立類似 Content Security Policy 的約束機制。
這個攻擊不挑 IDE，不挑模型，只看代理有多「聽話」。在安全與效率的天平上，AgentJacking 提醒我們：留給 AI 的自主權越大，它犯錯或被利用的可能性也越大。開發者在享受自動修復帶來的便捷時，最好還是保持一份手動審查的謹慎。
評論
暫無評論
成為第一個評論的人