Agentjacking 攻擊：一個假 Sentry 錯誤，讓你的 AI 程式碼助手幫駭客執行指令

攻擊的步驟簡單得令人不安。攻擊者找到目標公司的 Sentry DSN（通常直接嵌在前端 JavaScript bundle 裡，任何人都能看到），發送一個偽造的錯誤事件，然後等待。下次開發者對著 Claude Code 或 Cursor 說「幫我修一下 Sentry 上的錯誤」，AI 助手就會一字不差地執行攻擊者塞進去的指令，用開發者自己的身份、在開發者自己的機器上跑。

這是 Tenet Security 在 2026 年 6 月公開的新型攻擊手法，命名為 Agentjacking。

攻擊如何運作

Sentry 是開發者圈用來追蹤應用程式錯誤的主流工具，和 Claude Code、Cursor 這類 AI 程式碼助手整合後，開發者可以直接在 IDE 裡請 AI 查閱未解決的 Sentry 錯誤並提出修復方案。

問題出在這條資料流的信任設計上。Sentry 的 MCP（Model Context Protocol）伺服器會把錯誤事件的內容，包括錯誤描述、上下文欄位、附加的 markdown 格式說明，直接當作「可信的系統輸出」回傳給 AI 代理。AI 代理拿到這份資料後，把裡面的指令視同合法的系統操作步驟執行。

Tenet 的攻擊鏈是這樣的：

1. 攻擊者取得目標的 Sentry DSN（Data Source Name，通常公開嵌入在前端程式碼）
2. 向 Sentry 的 API 發送一個格式正確的假錯誤事件，在訊息欄位裡注入偽裝成「修復步驟」的惡意 markdown 指令
3. 開發者請 AI 助手「處理 Sentry 上未解決的問題」
4. AI 代理讀取 Sentry 回傳的內容，把攻擊者的指令當作診斷結果執行，完整操作包括竊取 CI/CD 憑證、存取私有程式碼庫、對雲端基礎設施發出指令，甚至安裝持久性後門

在測試中，這個攻擊對 Claude Code、Cursor、Codex 的成功率達到 85%。研究者在一次測試中，成功取得了一家市值 2,500 億美元的 Fortune 100 企業旗下 AI 助手的完整執行控制權。

為什麼 AI 代理看不出來

這不是 LLM 對齊失敗的問題，是協議層的信任邊界設計缺陷。

MCP 的設計假設是：透過 MCP 伺服器回傳的資料是可信的系統來源。Sentry 做為一個 MCP 工具，把它的 API 回應傳遞給 AI 代理時，並沒有區分「真正的 Sentry 錯誤」和「有人塞進來的假錯誤」。AI 代理沒有能力在運行時辨別這種注入，因為兩者在格式和傳遞路徑上完全相同。

更關鍵的是，Sentry 的 DSN 金鑰設計上就是半公開的，因為前端應用需要用它來回報錯誤，通常直接出現在打包後的 JavaScript 檔案裡。攻擊者連任何入侵步驟都不需要，用公開的 DSN 向 Sentry API 發一個 HTTP POST 就夠了。

數字背後的真相

Tenet 揭露的 2,388 家公司 是掃描後確認擁有可注入 Sentry DSN 的組織數量，是攻擊面的規模，不是已確認的受害者數字。但攻擊面和損失面之間的距離並不遠。

以 2026 年 AI 輔助開發的滲透率估算，有程式碼助手工作流的開發團隊大約佔這 2,388 家公司的 30 到 50%，也就是約 700 到 1,200 個環境裡，只要開發者習慣性地叫 AI 處理 Sentry 問題，攻擊窗口就是開的。

85% 的成功率需要加一個前提條件：測試是在「開發者主動請 AI 修復 Sentry 錯誤」的情境下進行的，是攻擊者最有利的條件設置，不是隨機樣本。現實中能觸發攻擊的實際比例會更低，但 Tenet 公布這個數字的意義在於，一旦觸發條件成立，防禦機制幾乎完全失效。

攻擊成本幾乎為零：一個公開的 Sentry DSN 加一個 API 呼叫。成功的攻擊能獲取 CI/CD 憑證、整個程式碼庫存取權、雲端基礎設施的控制能力，任何一項的潛在損失都在六位數美元以上。

Sentry 在 6 月 3 日收到 Tenet 的揭露通報後，確認了問題存在，但表示這在架構上「沒有辦法根本防禦」，拒絕在根源修復。漏洞目前仍然開放。

接下來值得觀察的指標

三件事在未來三到六個月內應該出現，可以用來判斷這個問題被認真對待還是被放著等。

第一，MCP 協議規範是否加入輸入驗證層。MCP 是開放規範，目前對「工具回傳內容的信任等級」沒有標準化的分類機制。如果社群想系統性解決 Agentjacking 這類注入問題，需要在協議層加入類似 Content Security Policy 的信任標記機制，讓 AI 代理能在執行前區分高信任和低信任來源的指令。

第二，主要 AI 程式碼助手提供商的具體回應。Anthropic、Anysphere（Cursor 開發商）、OpenAI 三家到目前為止都還沒有公開說明會如何處理這個攻擊面。Claude Code 和 Cursor 在測試中都被成功攻破，兩家的回應速度直接決定了現有用戶面臨的風險窗口有多長。

第三，Sentry 的後續決定。「技術上沒辦法根本防禦」是個有意思的表態。類似的說法在歷史上出現過多次，有時候是真的架構限制，有時候是優先順序的選擇。如果 Sentry 在未來幾個季度推出對抗這類注入的緩解措施，這句話就算是優先順序聲明；如果一直沒有，就是架構限制聲明，那麼解法只能在外部發展，可能是第三方 MCP 代理或 AI 助手本身的執行前驗證層。

你的團隊有在使用 Claude Code 或 Cursor 並連接 Sentry MCP 嗎？這個攻擊鏈要成立，開發者只需要叫 AI 助手處理一次 Sentry 錯誤。這個設置值得今天就去確認一下。

如果這篇對你有幫助，訂閱電子報 可以第一時間收到 AI PM 實戰洞察與 GenAI 落地案例。

---

相關閱讀：

• Fable 5 Jailbreak 漏洞：研究員宣稱以「一個對話回合」破防 Anthropic 最新旗艦模型
• Google ARD 草案：AI 代理如何在網路上找到彼此