你叫代理人去修個 Sentry 錯誤，它順手幫攻擊者跑了指令

重點一：安全公司 Tenet Security 公開一種叫 Agentjacking 的攻擊——攻擊者把惡意指令藏進一筆 Sentry 錯誤事件，當你叫代理人去修 Sentry 上未解決的錯誤，它會把那段偽裝成「修復步驟」的指令當權威照做。 重點二：Tenet 在 Claude Code、Cursor、Codex 上測試，整體成功率約 85%，並找出至少 2,388 家 擁有可被注入破口的組織。 重點三：成功攻擊能在開發者權限下外洩 AWS 金鑰、GitHub token、SSH 身分；Sentry 表示根本性修補「technically not defensible」，改以內容過濾因應。

你打開 Claude Code，丟一句再日常不過的話：「把 Sentry 上那幾個還沒解決的錯誤修一修。」代理人透過 Sentry MCP server 把錯誤列表抓回來，讀到其中一筆的「修復步驟（Resolution）」，照著做——然後，在你完整的開發者權限下，它跑了一段你從沒寫過的程式，把 AWS 金鑰和 GitHub token 送去了一台陌生的伺服器。

這不是假設。AI 代理人安全公司 Tenet Security 在 6 月中旬公開了這個被命名為 Agentjacking 的攻擊類別（媒體首報見 6 月 11 日 Infosecurity Magazine，細節以 Tenet 報告為準）。他們在最廣為使用的代理人上測試，整體成功率約 85%，並以被動偵察找出至少 2,388 家 擁有可注入破口的組織。手法本身，Tenet 形容為一種間接提示注入（indirect prompt injection）。

真正被打開的，不是某個產品的 bug，而是代理人「太聽話」這件事——它分不出「工具回傳的內容」和「該執行的指令」有什麼不同。下面把這條攻擊鏈一個環節一個環節拆開。

攻擊鏈怎麼成立？從一組公開的 DSN 開始

每個前端網站為了把當機回傳給工程團隊，都會在 JavaScript 裡內嵌一組 Sentry DSN——這是一組只能寫入（write-only）的憑證，設計上本來就公開可見。攻擊者要做的第一步，只是從目標網站的前端原始碼裡把它撿出來。

拿到 DSN 之後，攻擊者向 Sentry 的接收端點 POST 一筆自製的「錯誤事件」。重點在這筆事件的內容：它用 markdown 排版，混進一段偽裝成「修復步驟」的文字，外觀與 Sentry 自家的修復建議無法區分。

到這一步，攻擊者沒有入侵任何伺服器、沒有發釣魚信、也沒有竊取任何登入憑證。他只是往一個公開端點，寄了一封「看起來像系統訊息」的假錯誤。

為什麼代理人會照做？它把工具回傳的內容當權威

接著輪到開發者出場。你叫代理人「去處理未解決的錯誤」，代理人透過 Sentry MCP server 查詢，把那筆被注入的事件當成權威的系統輸出讀進來。

Tenet 的說法很直白：「當 AI 代理人向 Sentry 查詢未解決的錯誤、收到回應後，它就會照著做——就像一個開發者會做的那樣。」代理人看到「修復步驟」，於是照著「修復步驟」執行了攻擊者控制的（npm）套件。

最後一步，這段程式在你的完整權限下跑起來，探測並外洩它搆得到的一切。Tenet 列出的清單包括：

• AWS 金鑰 與雲端基礎設施 token
• GitHub／OAuth token、私有 repo 位址與憑證
• SSH 身分、環境變數、CI/CD 管線憑證
• 內部主機名稱與 VPN 識別資訊

換個角度看：整條鏈裡，唯一需要「人」動手的一步，就是你請代理人去修錯誤。

打中誰、規模多大：2,388 家組織、85% 成功率

Tenet 在市面上最廣為使用的代理人家族上測試了這套手法，含 Claude Code、Cursor、OpenAI Codex，得到整體約 85% 的成功率，並表示有「100 個以上的 AI 寫程式代理人」對注入的錯誤採取了行動。

規模那一面，他們以被動偵察找出至少 2,388 家 擁有可注入 DSN 的組織，其中 71 家 位列 Tranco 全球前一百萬網站，橫跨 30 多國、涵蓋金融、醫療、政府與關鍵基礎設施。

這裡要如實標註：85% 與 2,388 都是 Tenet 單一來源測得／偵察的數字，屬控制性驗證樣本，不等於「已有 2,388 家被實際入侵」。但它說明的事很具體——這三個代理人，正是台灣開發者與工程團隊每天在用的那三個。

Sentry 怎麼回應？「根本性修補 technically not defensible」

被告知後，Sentry 承認了問題，但表示根本性的修補「technically not defensible」——大意是，要從架構上徹底擋掉「錯誤內容被當成指令」這件事，技術上站不住腳。它改以部署全域內容過濾、阻擋已知的惡意字串作為因應，並指出模型廠商會在自己這端跑中介層防護。

也就是說，這條防線目前不在 Sentry 的根部，而是被推到了模型廠商的中介層與開發者端的設定上。Tenet 自己則同步開源了一組名為 agent-jackstop 的「drop-in」防護設定，宣稱可硬化 Cursor 與 Claude Code 對這類來自不可信遙測／日誌的攻擊。

攻擊鏈上的五個環節，現在各由誰在補？

把整條鏈攤平，每個環節目前的防護落點是這樣（事實呈現，不是操作指示）：

環節	攻擊者做了什麼	目前由誰／用什麼方式擋
1. 取得 DSN	從前端 JS 撿出公開、只能寫入的 DSN	設計上即公開，無從「修補」
2. 注入假錯誤	向 Sentry 端點 POST 偽裝成修復步驟的事件	Sentry 部署全域內容過濾，擋已知字串（非根本修補）
3. MCP 回傳	代理人經 Sentry MCP 把事件當權威輸出讀入	MCP 工具輸出的可信邊界，公開規範有限
4. 代理人執行	代理人照「修復步驟」跑攻擊者套件	模型廠商中介層防護（攔截率公開資訊有限）、Tenet 開源 agent-jackstop
5. 資料外洩	在開發者權限下外洩金鑰／token／SSH	取決於該機器的權限與憑證範圍

這張表裡最薄的一欄是第 3、第 4 環節——「工具經 MCP 回傳的內容該不該被當成可信指令」目前沒有統一答案，模型廠商中介層實際攔截多少，公開資訊也有限。

還沒有答案的是什麼？

把今天這件事收成一句：一筆任何人都能寫進去的 Sentry 假錯誤，就能讓 Claude Code、Cursor、Codex 在你的權限下替攻擊者跑指令——Tenet 測得約 85% 中招。

而最值得自己盯的一個問題是：Sentry 已經公開把根本修補定性為「technically not defensible」，於是防線落到了模型廠商的中介層。這層防護現在攔得住多少、涵蓋哪些代理人與哪些工具，目前還沒有可對照的公開數字。Sentry 只是第一個被示範的載體——同樣「會把外部內容回傳給代理人」的工具，還有很多。

---

資料來源：Tenet Security 揭露報告、The Hacker News、Infosecurity Magazine、The Next Web。

林子睿（編輯：廖玄同），《你叫代理人去修個 Sentry 錯誤，它順手幫攻擊者跑了指令》，矽基前沿 [Si]gnals，2026-06-21。https://signals.tw/articles/agentjacking-coding-agents-sentry/