團隊發現 Sentry Seer 的 CVE-2026-90999 後暫停部署
We Almost Deployed an AI Debugging Agent. Then We Found a Critical CVE.
團隊因 Sentry Seer 的 CVE-2026-90999，在部署前決定暫停推出。未經身份驗證的攻擊者可透過公開 DSN 提交偽造事件；若 Seer 設定為自動交接至編碼智能體，事件內容會被帶入提示詞，並令智能體下載及執行攻擊者控制的程式碼。文章整理輸入、權限、交接、觸發條件和影響範圍的檢查項目，並列出停用自動交接、以沙箱隔離智能體、限制套件安裝及把遙測視為不可信輸入等緩解措施。
文章沿著遙測輸入、AI 分析、智能體交接到程式碼執行，梳理信任邊界，並整理部署前可檢查的權限與觸發條件。
當我們客戶的團隊評估 Sentry Seer 時，它的吸引力顯而易見：它可以自動分類處理正式環境錯誤、提出修正方案，並提交合併請求。對小型工程團隊而言，這有望節省不少時間。然而，在推出前幾天披露了一項嚴重安全漏洞後，我們決定不再推行部署。
漏洞並非設定錯誤
2026年9月16日，CERT/CC 發布了 VU#212479，內容描述了 CVE-2026-90999，指出 Sentry Seer 存在嚴重的信任邊界違規。
關鍵在於：Sentry 專案通常會在用戶端程式碼中公開 DSN，讓瀏覽器提交錯誤遙測資料。瀏覽器應用程式使用公開 DSN 是常見做法，因為它們只接受事件提交，因此我們一直沒有把自己的 DSN 視為重大風險。
CVE-2026-90999 改變了這個假設。未經驗證的攻擊者可以透過公開 DSN 提交偽造的 Sentry 事件。如果 Seer 設定為自動把問題交由編碼 Agent 處理，這些由攻擊者控制的遙測資料便會流經 Seer 的分析流程，並作為可信的背景資料嵌入 Agent 的提示詞，最終令 Agent 下載並執行由攻擊者控制的程式碼。
攻擊者無須存取機構的 Sentry 帳戶、程式碼儲存庫或基礎架構，只需取得早已隨前端 JavaScript 發布的 DSN。
CVE 背後的模式
這並非首次出現警號。2026年6月，Tenet Security 披露了「agentjacking」：攻擊者透過公開的 Sentry DSN 傳送偽造錯誤事件；之後，當開發人員要求編碼 Agent 查看未關閉的 Sentry 問題時，Agent 會透過 Sentry 的 MCP 伺服器讀取該事件，並遵從攻擊者的指示。Sentry 確認收到報告，但拒絕修正根本原因，稱在平台層面這樣做「在技術上站不住腳」。CVE-2026-90999 是同一弱點在另一條路徑上的表現。Agentjacking需要開發人員提示 Agent；Seer 的自動轉交機制省去了這一步，因此偽造的遙測資料可以在完全沒有人介入的情況下，傳到具特權的編碼 Agent。
把這件事歸類為「供應商安全事故」然後置之不理，似乎很容易。但這是結構性問題，適用於任何會接收外部遙測資料並自動採取行動的 AI Agent。
大部分安全審查都聚焦於模型和端點。一旦 AI 系統能夠採取行動，從輸入資料到執行的路徑便成為系統中另一個需要接受安全審查的部分。
在這個案例中，整個流程有四個階段：
- 遙測資料接收 — 公開 DSN 接受任何人提交的事件
- AI 處理 — Seer 產生根本原因分析
- Agent 轉交 — 分析結果被嵌入提示詞，並傳送給編碼 Agent
- 執行 — Agent 在具特權的環境中執行程式碼，並可存取原始碼儲存庫
每個階段都假設上一個階段已驗證其輸入，但沒有任何階段在整個流程中落實這個假設。問題並非侷限於某個元件，而是源於不受信任的資料在整個工作流程中的傳遞方式。
CERT/CC 的公告清楚説明瞭這一點：偽造事件會穿越多個信任邊界，從不受信任的遙測資料轉化為具特權的 Agent 會執行的指令。
為何這對每間正在評估 AI Agent 的企業都至關重要
Seer 的架構並不罕見。輸入遙測資料、進行 AI 推理、輸出自動化操作：這正逐漸成為 AI 工具的預設模式。錯誤分類處理、日誌分析、事件應變、程式碼審查，全部都正轉向代理式流程，不再只是提供建議，而是直接執行。
這改變了安全問題的焦點。我們發現，單獨評估模型並不足夠。我們還需要了解哪些輸入可以傳送至代理程式，以及代理程式擁有哪些權限。
大多數團隊會評估模型準確度和整合介面，但不會評估遙測資料的完整流轉鏈。
我們現正採用的框架
我們為任何會自動採取行動的 AI 代理程式制定了一份簡短檢查清單：
| 檢查項目 | 要問的問題 |
|---|---|
| 輸入 | 所有輸入是否都經過身份驗證？外部人士能否在沒有憑證的情況下觸發流程？DSN、webhook 和表單等公開端點，都應視為不可信的入口。 |
| 權限 | 代理程式會否執行程式碼？在哪種環境中執行？權限範圍有多大？如果答案是「我們的基礎設施，而且可存取正式環境」，輸入驗證的要求就必須高得多。 |
| 交接 | 從輸入到執行之間的每個階段，都是信任邊界。這些邊界有否落實管控，還是隻是假定存在？ |
| 可觸發性 | 如果未經身份驗證的用戶可以觸發工作流程，就必須將該工作流程的每個階段都納入威脅模型。 |
| 影響範圍 | 如果惡意輸入傳送至代理程式，它可以做甚麼？CERT/CC 指出，成功利用漏洞後，攻擊者便可存取已連接的原始碼儲存庫，並執行程式碼代理程式憑證所允許的操作。 |
在推出前，比起推出後，這些問題更容易回答。測試代理程式如何處理惡意輸入，是我們AI 代理程式測試與評估工作的一部分；而輸出結構描述、白名單和人工審批模式，則載於我們的代理程式防護措施案例研究。
重點
負責分類、診斷並修復正式環境問題的代理程式價值甚高，不應因一項 CVE 而置之不理。
但這改變了我們評估代理程式的方式。我們的審查不應只涵蓋代理程式能否正常運作，還應檢視它在採取行動前如何處理不可信輸入，以及由哪個團隊負責相關管控措施。
截至本文撰寫時，供應商尚未提供修補程式。緩解措施須從操作層面着手：停用自主交接、將代理程式置於沙盒中、限制套件安裝，並將遙測資料視為不可信輸入。
對於在工程工作流程中部署代理式 AI 的企業，我們現在認為，這些管控措施是部署自主代理程式的基本要求。這些工具仍然有價值，但也帶來需要在部署前處理的風險。
本文最初刊載於Dwayo blog。正在為團隊評估 AI 代理程式？預約 30 分鐘審查。
來源：DEV Community · dev.to