公開 Sentry key 也能劫持 AI 編碼工具

公開的 Sentry key 可能被濫用，讓惡意 MCP 資料混進 Claude Code、Cursor 和 Codex 的上下文。

這件事很實在，也很煩。只要一個外洩的整合 key，原本拿來看錯誤和追蹤的資料流，就可能變成攻擊入口。像 Claude Code、Cursor，還有 Codex，都開始把外部資料接進工作流。這時候，MCP 就成了放大器。

研究團隊示範的手法，常被叫做 agentjacking。講白了，就是攻擊者不去硬闖主系統，而是去污染 AI 助手吃進去的資料。當模型把錯的東西當真的，後面產生的建議、摘要、甚至動作，就可能一起歪掉。

這種攻擊為什麼會成功

核心問題只有一個：信任。AI 編碼工具會把票單、log、文件、監控資料，全部塞進上下文。它們再根據這些內容，去寫程式、改檔案，或提出下一步動作。只要其中一個來源能被動手腳，模型就可能把攻擊者的內容當成內部訊號。

這在開發流程裡特別麻煩。因為 agent 常常是「讀一個系統，寫到另一個系統」。它先看錯誤事件，再去改程式碼；先看工單，再去產生 patch。只要前面的資料被污染，後面的建議就會跟著偏掉。

說白了，這比較像是 agent 版的供應鏈污染。攻擊者不需要控制模型本身，也不需要破解 API。只要找到一條能餵資料進去的路，就能把假訊號塞給 AI。

• 公開 key 可能暴露整合入口。
• 暴露入口可能接受外部輸入。
• agent 可能把這些輸入當可信上下文。
• 可信上下文會影響建議和動作。

Sentry 在這裡扮演什麼角色

Sentry 本來是防守工具。大家拿它來收集錯誤、trace 和效能資料，目的是更快修 bug。問題不在 Sentry 本身，而在資料怎麼被後面的 AI 工具消化。

如果一個 Sentry project 的公開識別資訊，讓外部資料能被送進來，那它就不只是監控設定而已。它會變成一個可被碰觸的輸入口。當 AI 助手自動讀這些資料時，風險就從「看得到 log」變成「看得到假 log」。

Simon Willison 長期在談 prompt injection 和 AI 工具安全。他對這類風險的提醒很直接。

"The main issue is not the model itself, but the untrusted data that gets fed into it," said Simon Willison.

這句話很到位。問題不只是模型準不準，而是你餵了什麼進去。當資料流本身不乾淨，模型再強也會被拖下水。

對團隊來說，這代表監控資料不能再被當成天然可信。以前看 dashboard 沒問題，現在同一筆事件可能直接進到 agent 的推理鏈。每個欄位都要假設可能被動過。

Claude Code、Cursor、Codex 的風險差在哪

這三個工具不一樣，但弱點很像。Claude Code 跟 codebase 綁得很緊。Cursor 把 AI 直接放進編輯器。Codex 則靠近程式生成和任務執行。

它們共同的問題是，都能讀外部資料。只要 agent 可以接 ticket、log、文件、或其他服務，攻擊者就會想辦法塞假內容。模型通常很難穩定分辨，哪個是內部訊號，哪個是刻意投放。

這裡可以把 MCP 想成擴充插槽。插槽越多，能接的服務越多，攻擊面也越大。不是每個 connector 都危險，但每多一個，審查成本就再往上加。

• Claude Code 更靠近 repo 與開發任務。
• Cursor 把編輯器操作和 AI 建議綁在一起。
• Codex 可能接近 code 生成與執行流程。
• MCP 會把更多外部系統拉進上下文。

如果你問我，這種風險比單純的 prompt injection 更麻煩。因為它不是只騙一句話，而是能騙整條資料鏈。資料一旦被接受，後面每一步都可能跟著錯。

開發團隊現在該做什麼

先別急著把 AI 編碼工具全關掉。比較務實的做法，是把信任邊界劃清楚。每個 connector、每個 public key、每個資料來源，都要重新盤點。只要來源可能被外部碰到，就不能直接丟給 agent 看。

第二步，是把「讀資料」和「做動作」分開。讓 agent 看 log，和讓 agent 開 ticket、改程式、觸發部署，這是兩種完全不同的權限。前者可以寬一點，後者就該非常嚴。

第三步，是把 MCP 納入資產管理。只要你的團隊有用 MCP，每個 server 和 connector 都要列入盤點。能停用的先停用，能輪替的 key 先輪替，能加驗證的地方先加上去。

• 檢查所有公開 key 是否真的需要公開。
• 審核每個 agent connector 的輸入來源。
• 把高風險動作拆成人工確認流程。
• 為 MCP server 建立撤銷與輪替機制。

這裡也很適合借鏡傳統資安。以前我們會檢查 webhook、API、CI/CD 權限。現在只是多了一層 AI agent。邏輯沒變，都是先驗證，再信任。

這代表整個 AI 工具鏈要重想一次

這波風險也說明一件事。AI 工具越像助理，就越像一個會吃資料的系統。它不是單純回答問題而已。它會讀、會整理、會建議，還可能直接幫你動手。

所以問題不只是模型有沒有 hallucination。更大的問題是，誰能控制模型看到什麼。當外部服務、監控資料、票單系統、文件庫都能餵進來時，安全邊界就不在 prompt 了，而在資料管線。

如果你在做產品或內部工具，現在就該問一個很現實的問題：你的 agent 到底信了誰。只要答案裡有任何一個外部來源，那就該先做驗證，再讓它進上下文。

接下來該盯什麼

我覺得接下來 6 到 12 個月，大家會更常看到這類 agent 攻擊。原因很簡單。MCP、外掛、connector、RAG，全部都在擴大資料入口。入口越多，越容易混進髒東西。

所以最實際的做法，不是等下一次事故才補洞，而是現在就開始盤點。把每個資料來源列出來，把每個權限拆開來，把每個會觸發動作的流程加上人工確認。這很土，但很有效。

如果你的團隊已經在用 Claude Code、Cursor 或 Codex，我會建議先查一次所有外部資料源。因為在 agent 時代，最值錢的不是模型參數，而是資料入口的乾淨程度。