安全與治理

一個月內 126 起事件:首份全面的 AI 安全清單及其對代理風險的證明

作者：IdeaBosque最後更新：2026年10月4日

核心重點

2026 年 9 月,38 家具名組織發生 126 起 AI 安全事件,逾 3.18 億筆記錄外洩 —— 首份有具名受害者與量化範圍的月度清單,由 RuntimeAI 於 2026 年 10 月 2 日發布。
AI 在 126 起事件中的 39 起裡是攻擊載體,在 3 起裡是直接武器 —— 「AI Agent Exploit」類別是最大的攻擊向量類別,超過憑證竊取(27)、零日漏洞利用(22)、網路釣魚(10)與資料外洩(10)。
一個月內披露 11 個 RCE 漏洞,涉及 Claude SDK(Anthropic)、LiteLLM、Bifrost AI Gateway 與 MCP Server —— 代理基礎設施堆疊中的遠端程式碼執行已是反覆出現的月度披露,而非孤立事件。
被攻破的 38 家組織包括微軟、思科、谷歌、Meta、蘋果、OpenAI、Anthropic、Oracle、HuggingFace、Salesforce、GitLab、Okta、Nvidia、Azure、NIST、NSA 與 CISA —— 安全廠商本身(ESET、Okta、Cloudflare、Wiz)也出現在受害堆疊中。
36,769 個自託管 AI 推理服務被公開暴露,一個惡意 AI 代理網路竊取了 60 萬張信用卡 —— 暴露面從具名企業延伸到任何營運無管理推理端點的人。

RuntimeAI 於 2026 年 10 月 2 日發布的 2026 年 9 月 AI 安全事故報告,是首份有具名受害者、量化記錄數與分類事故目錄的月度 AI 安全清單。126 起事件。38 家組織受害。3.18 億筆記錄外洩。11 個 RCE 漏洞。報告涵蓋完整的 AI 基礎設施堆疊:單月之內,Claude SDK、LiteLLM、Bifrost AI Gateway 與 MCP 伺服器全部成為 RCE 目標。本文梳理這份清單證明了什麼 —— 以及它如何改變工程負責人閱讀治理檢查清單問題的方式。

本文承襲《Four Labs Found the Same Agent Misbehavior》,該文記錄了 OpenAI、Anthropic、Google 與 Meta 各自發現其代理的相似失當行為,以及 OpenAI 在 Hugging Face 事件兩個月後仍無法列舉自己代理的行動。那篇文章確立了模式。RuntimeAI 報告補充的是頻率:前沿實驗室無法盤點自己的代理並非孤例。它是以百為單位的月度節律中的一個實例。

清單:126 起事件、38 家組織、一個月

來自 RuntimeAI 報告的頭條數字:

指標	數量
事件總數	126
嚴重等級	22
高危等級	102
受害組織	38
外洩記錄	超過 3.18 億
AI 參與的事件	53(3 起作為武器,52 起作為目標)
RCE 漏洞	11
引用 CVE	11

這 38 家具名組織橫跨 AI 供應鏈,從模型實驗室到基礎設施提供商再到安全廠商。按 RuntimeAI 公布的完整名單:微軟、思科、GitHub、Google、Meta、蘋果、Bitget、Gemini、Okta、Nvidia、Azure、OpenAI、Anthropic、Oracle、HuggingFace、Salesforce、GitLab、LiteLLM、Revolut、NIST、NSA、CISA、McKesson、AdaptHealth,以及曼徹斯特機場集團與俄羅斯漢堡王等。四家安全廠商 —— ESET、Okta、Cloudflare 與 Wiz —— 出現在受害堆疊中。NIST 與 CISA 的入列是報告中最尖銳的訊號:制定安全標準的組織本身進入了當月的事件清單。

嚴重度分布為 22 起嚴重、102 起高危。目錄中的每起事件都按攻擊向量、AI 參與度與受影響元件分類。這份目錄不是新聞稿 —— 它是帶逐條連結的結構化事故資料庫。

攻擊向量:AI Agent Exploit 是最大類別

攻擊向量分布是報告中最應改變工程負責人優先順序的部分:

攻擊向量	事件數
AI 代理漏洞利用	39
憑證竊取	27
零日 / 漏洞	22
網路釣魚 / 社交工程	10
資料外洩	10

「AI Agent Exploit」是最大類別 —— 126 起事件中的 39 起,占總數的 31%。這不是代理作為更大侵害事件中的下游受害者。而是代理作為攻擊面:提示注入、工具濫用、未授權工具呼叫、代理仲介的橫向移動。報告的立場是:代理層已成為主要入口,把憑證竊取(27)與傳統零日漏洞利用(22)從分布頂端擠了下來。

AI 是武器而非目標的 3 起事件,是以往月度事故報告中不存在的類別。RuntimeAI 記錄了一個竊取 60 萬張信用卡的惡意 AI 代理網路、在受害裝置上部署 AI 代理的 Carbonato 僵屍網路,以及自主攻入一家西班牙組織並修改軟體元件的 AI 代理。這些不是被入侵的代理。而是被當作攻擊工具而部署的代理。這個區別對治理至關重要:能阻止被入侵代理的緊急停機開關,擋不住一個天生為攻擊而建造的代理。

RCE 層:代理基礎設施堆疊中的 11 個漏洞

對任何營運代理基礎設施的團隊,11 個 RCE 漏洞都是操作上最具可行動性的發現。具名目標包括:

Claude SDK(Anthropic) —— Claude Code CLI 與 Agent SDK 中的遠端程式碼執行。Check Point Research 記錄了透過 Hooks、MCP 伺服器組態與環境變數,經由 Claude Code 專案檔案的 RCE 與 API 權杖外洩。SentinelOne 的另一份分析記錄了 CVE-2026-39861,一個透過符號連結操作的沙箱逃逸。
Bifrost AI Gateway —— CVE-2026-90898,管理認證停用時的未認證命令執行。單個未認證的 POST 即可讓 Bifrost 執行攻擊者提供的命令,並暴露儲存的 LLM 供應商 API 金鑰。已在 transports/v2.1.0 修復。
LiteLLM —— 在供應商之間路由 LLM 流量的代理。LiteLLM 的預設管理員金鑰暴露是首個進入 CISA 已知被利用漏洞目錄的 MCP CVE,記錄於 The First MCP CVE on the KEV List。RuntimeAI 報告確認 LiteLLM 是反覆出現的 RCE 目標。
MCP Server(多個) —— Model Context Protocol 伺服器層。MCP Security Hardening Checklist 記錄了 1,467 個公開可存取且無認證的 MCP 伺服器與 82% 的路徑遍歷暴露。RuntimeAI 報告確認 MCP 伺服器是一個 RCE 類別,而非單一 CVE。

11 個 RCE 的模式是一致的:代理基礎設施層 —— 位於模型與企業之間的 SDK、閘道、代理與協定伺服器 —— 擁有早期 Web 基礎設施的攻擊面,卻沒有相應的加固。在生產環境部署代理的團隊,部署的正是一套閘道、代理或 SDK 中的 RCE 成為月度披露而非罕見事件的堆疊。

暴露面:36,769 個自託管推理服務

在具名組織之外,報告量化了無管理的暴露面:36,769 個自託管 AI 推理服務可被公開存取。這些是沒有認證、限流或網路分段的推理端點 —— 相當於敞開資料庫的 AI 版。這個數字是安全加固清單中 1,467 個無認證 MCP 伺服器的基礎設施對應物:AI 基礎設施的部署模式是「先暴露,後安全」,而「後」並沒有以暴露同樣的速度到來。

對中型 B2B 公司而言,36,769 這個數字把風險算術變得具體。如果你的團隊為試點架了一個自託管推理端點而沒有加認證,它就在這個數字裡,或在下個月的對應數字裡。一旦月度清單以數萬為單位度量暴露面,未認證推理端點的成本就不再是假設。

清單改變了什麼

在 RuntimeAI 報告之前,代理安全是一起一起事件的敘事:Hugging Face 滲漏、Medicare 入侵、DNS 沙箱逃逸、四實驗室範圍評審。每起事件是一個故事,每個故事對應一個補丁。RuntimeAI 報告把敘事變成了頻率陳述。一個月 126 起事件意味著問題不再是「我們的代理部署會出安全事件嗎?」,而是「什麼時候,以及會是 11 個 RCE 類別中的哪一個?」。

治理含義是直接的。AI Agent Governance Checklist 與 MCP Security Hardening Checklist 已經列出了控制項:傳輸認證、工具註冊驗證、執行時隔離、稽核軌跡、緊急停機開關測試記錄。RuntimeAI 報告證明這些控制不是選配加固。它們決定了你的部署會進入下個月的清單,還是不會。38 家具名組織中有配備專職安全團隊的公司。控制失效不是因為不知道,而是因為沒有在暴露之前應用到代理層。

下圖梳理 RuntimeAI 清單的結構:規模、攻擊向量、RCE 層,以及清單暴露的控制缺口。2026 年 9 月 AI 安全清單一覽: