總字數：約8500字 | 預計閱讀時長：25分鐘​

一、智慧體業務系統架構與資料流​

要理解Agent安全，首先要看清智慧體業務系統的全貌。一個完整的智慧體業務系統，從資料訓練到使用者互動，涉及多個環節的協同工作。每個環節都可能成為攻擊者的突破口。​

典型的智慧體業務系統架構包含以下核心元件：​

​



| 元件 | 功能描述 | 典型技術棧 |
| --- | --- | --- |
| 資料層 | 訓練資料儲存、向量資料庫、知識庫 | PostgreSQL、Milvus、Pinecone |
| 模型層 | 大語言模型推理服務 | vLLM、Ollama、DeepSeek API |
| 應用層 | 業務邏輯處理、API閘道器 | FastAPI、Spring Boot、LangChain |
| Agent層 | 任務規劃、工具排程、記憶管理 | LangGraph、OpenClaw、Hermes |
| Skill層 | 工具函式、外部API呼叫 | MCP Server、自定義工具 |
| 互動層 | 使用者介面、訊息閘道器 | Web UI、Telegram Bot、企業微信 |



​

資料流路徑：使用者輸入 → 應用層 → Agent層（規劃） → Skill層（執行） → MCP協議（通訊） → 外部工具 → 返回結果 → Agent層（處理） → 使用者輸出​

這條鏈路上的每一個節點，都存在被攻擊的可能。攻擊者不需要攻破整條鏈路，只需要在任意一個節點植入惡意指令或資料，就可能劫持整個Agent的行為。​

​

Unable to print

![Feishu Docs - Image](images/img_1.png)

​

行業現狀：2026年5月，斯坦福/MIT/NVIDIA聯合釋出的迄今最大規模AI Agent安全研究顯示，在對847個生產環境中的AI Agent進行評估後發現：91%存在工具鏈攻擊漏洞，94%的記憶增強型Agent可被投毒，89.4%會在執行約30步後出現目標偏移。研究共發現2,347個此前未知的漏洞，其中23%被評定為嚴重級別。​

參考來源：[91%生產級AI Agent存在致命漏洞：2026年智慧體安全危機全景報告](https://blog.csdn.net/weixin_42376192/article/details/160847421)​

二、資料訓練階段的安全風險​

資料訓練是智慧體系統的"地基"，這個階段的安全問題往往具有隱蔽性強、潛伏期長、影響範圍廣的特點。​

2.1 訓練資料投毒​

攻擊者透過汙染訓練資料，讓模型學習到錯誤的知識或行為模式。在RAG（檢索增強生成）場景中，攻擊者可以向知識庫注入惡意文件，當Agent檢索到這些文件時，就會執行惡意指令。​

真實案例一：2026年央視315晚會曝光"AI投毒"產業鏈​

2026年3月15日，央視315晚會曝光了一條令人震驚的"AI投毒"灰色產業鏈。記者花39.9元在淘寶購買了一款名為"力擎GEO最佳化系統"的軟體，然後憑空捏造了一款根本不存在的智慧手環"Apollo-9"，編造了"量子糾纏感測""無需採血測血糖""黑洞級續航"等離譜賣點。​

系統自動生成了十餘篇"專家測評""行業排名""使用者體驗"文章，批次釋出到各大自媒體平臺。僅僅兩個小時後，當記者在DeepSeek、豆包等主流AI大模型中詢問"Apollo-9智慧手環怎麼樣"時，AI竟然一本正經地介紹起這款根本不存在的產品，照搬了那些虛假宣傳話術，並推薦給中老年使用者。​

GEO服務商負責人直言："全網投毒的人太多了，AI吃的都是我們喂的東西，它能不認？"​

參考來源：[3·15晚會丨AI大模型遭"投毒"？給AI"洗腦"已成產業鏈](http://m.toutiao.com/group/7617474523033584134/) | [AI投毒:一場你看不見的認知戰爭](http://m.toutiao.com/group/7618802682756629032/)​

真實案例二：Anthropic研究——250篇文件就能投毒大模型​

2025年，Anthropic聯合英國AISI和圖靈研究所釋出了一項顛覆性研究（論文arXiv:2510.07192）：只需250篇惡意文件，就能給一個130億引數的大模型植入後門。這個數字只佔訓練資料的0.00016%，但足以讓模型在特定觸發詞下"精神失常"。​

研究人員構造的汙染文件在正常內容中嵌入<SUDO>觸發器，模型在預訓練時看到250次這樣的文件後，就學會了"只要看到<SUDO>就輸出亂碼"的規則。平時模型表現完全正常，只有觸發時才暴露問題，這種"沉睡式投毒"極其隱蔽。​

參考來源：[技術總結|十分鐘瞭解大模型投毒](https://juejin.cn/post/7636277855710543878)​

真實案例三：NYU研究——0.001%假資料就讓醫療AI"中毒"​

紐約大學在Nature Medicine上發表的研究顯示，僅將0.001%的訓練token替換為錯誤資訊，就能訓練出更有可能傳播錯誤醫學知識的模型。研究人員用GPT-3.5 API生成了5萬篇假醫學文章，僅花費5美元，就導致模型輸出的有害內容增加7.2%。​

參考來源：[大模型混入0.001%假資料就「中毒」，成本僅5美元，NYU新研究登Nature子刊](https://m.36kr.com/p/3152932478180099)​

2.2 向量資料庫汙染​

向量資料庫是RAG系統的核心元件。攻擊者可以透過以下方式汙染向量資料庫：​

•

注入帶有惡意指令的文件，使其被向量化後儲存​

•

利用向量相似度的特性，讓惡意文件更容易被檢索到​

•

透過批次注入稀釋正常知識庫的內容，降低Agent的準確性​

實踐經驗：在實際部署中，建議對進入向量資料庫的文件進行多層校驗：內容安全掃描、來源可信度評估、語義一致性檢測。定期對向量資料庫進行"清洗"，移除異常向量。​

2.3 微調資料後門​

如果Agent使用了微調模型，攻擊者可能在微調資料中植入後門。當模型遇到特定觸發詞時，就會執行預設的惡意行為。這種後門極其隱蔽，常規測試很難發現。​

真實案例：2026年1月，"Poison Fountain"（毒泉）專案公開宣稱，其目標是透過分發汙染後的訓練資料來幹擾AI系統的訓練。該專案生成的程式碼看起來完整、可執行，但實際上嵌入了大量微妙的語法錯誤——比如用+代替\-作為命令列引數字首。如果AI模型從這類程式碼訓練，就會傾向於生成錯誤的程式碼。​

參考來源：[注意：境外未知組織正發起汙染Ai大模型資料集計劃](https://blog.csdn.net/blackorbird/article/details/156875998)​

三、模型推理階段的安全風險​

模型推理是Agent的"思考"過程，這個階段的安全風險主要來自模型本身的脆弱性。​

3.1 對抗樣本攻擊​

透過精心構造的輸入，讓模型產生錯誤的推理結果。在Agent場景中，攻擊者可以構造特殊的Prompt，讓Agent忽略安全約束、洩露系統資訊或執行未授權操作。​

真實案例：Universal Policy Puppetry攻擊​

2025年4月，HiddenLayer安全研究人員宣佈發現了首個能攻破所有主流AI模型的通用提示注入技術——"Policy Puppetry"。這項技術能夠用單一惡意指令攻破ChatGPT、Claude、Gemini、Llama等所有主要模型，成功率高達65%-80%。​

參考來源：[Prompt Injection: la vulnerabilità numero uno che minaccia l'AI mondiale](https://www.ictsecuritymagazine.com/articoli/prompt-injection/)​

3.2 模型竊取與逆向​

攻擊者透過大量查詢API，逆向推斷模型的引數、訓練資料或決策邏輯。這不僅涉及智慧財產權洩露，還可能被用於構造針對性的攻擊。​

行業資料：據Palo Alto Networks研究，某些攻擊技術在不同LLM上的成功率高達65%-80%。攻擊者透過精心設計的查詢序列，可以逐步推斷出模型的決策邊界和敏感知識。​

3.3 推理側通道攻擊​

透過分析模型的響應時間、token分佈、輸出機率等資訊，推斷模型的內部狀態或使用者輸入的敏感資訊。在多租戶環境中，這種攻擊尤其危險。​

實踐經驗：在多租戶部署中，建議對推理服務進行資源隔離，使用統一的響應時間策略，避免透過時序差異洩露資訊。​

四、應用呼叫階段的安全風險​

應用層是連線使用者和Agent的橋樑，這個階段的安全風險主要集中在API介面和業務邏輯上。​

4.1 API安全漏洞​

Agent系統通常暴露多個API介面，包括：​

•

模型推理API​

•

知識庫管理API​

•

工具呼叫API​

•

使用者管理API​

這些API如果缺乏嚴格的認證、授權和輸入驗證，就可能被攻擊者利用。​

真實案例一：FastAPI/Starlette框架"BadHost"漏洞（CVE-2026-48710）​

2026年5月29日，安全研究人員披露了一個影響整個Python AI生態的"地基級"漏洞。Starlette框架——每週下載量高達3.25億次的Python基礎元件——存在一個僅需"1個字元"即可觸發的認證繞過漏洞。​

攻擊者只需在HTTP Host Header中注入一個特殊字元，就能製造"系統認知錯位"：路由系統看到的是正常請求路徑，但認證系統看到的是被篡改的URL。研究人員在網際網路上掃描後，發現了大量暴露的生產系統，包括生物製藥公司的臨床試驗資料庫、企業郵件系統、AWS雲基礎設施，甚至工業裝置的SSH訪問許可權。​

安全機構X41 D-Sec直言："只需要一個字元，門就開了。"​

參考來源：[3.25億次周下載、FastAPI"地基"爆雷，這個Python框架曝出「致命漏洞」](https://36kr.com/p/3828901167911812) | [Your AI Agent's Credentials Are Leaking Right Now: The BadHost Exploit](https://www.banandre.com/blog/badhost-starlette-vulnerability-ai-agents)​

真實案例二：Meta Instagram AI助手被盜號事件（2026年6月2日）​

2026年6月2日，Meta宣佈修復了AI智慧助手的一項重大安全漏洞。駭客利用該漏洞盜取了大量Instagram優質賬號，包括奧巴馬政府時期的白宮官方賬號、美國太空部隊總軍士長的個人賬號、美妝零售巨頭絲芙蘭官方賬號等。​

攻擊手法極其簡單：駭客先用VPN模擬受害者地理位置，然後與Meta AI智慧助手對話，要求為目標賬號新增新郵箱。智慧助手向駭客郵箱傳送驗證碼後，系統直接彈出"重置密碼"選項，從而完成盜號。整個過程無需攻破原郵箱，僅憑AI助手的"配合"就能實現賬號易主。​

安全專家指出："稽核、操作流程全程自動化，關鍵環節缺乏真人介入，導致AI智慧助手的許可權邏輯漏洞成為黑產新突破口。"​

參考來源：[AI遭"誘騙"幫駭客盜號，多個名人、企業官方賬號受影響](http://m.toutiao.com/group/7646795379362562600) | [利用 Meta 的 AI 機器人劫持任意 Instagram 帳戶](https://www.51cto.com/article/845121.html)​

4.2 會話管理缺陷​

Agent系統的會話管理如果存在缺陷，可能導致：​

•

會話劫持：攻擊者接管使用者的Agent會話​

•

會話固定：強制使用者使用攻擊者控制的會話​

•

跨會話資訊洩露：不同使用者的資料相互洩露​

實踐經驗：建議為Agent會話實現多因素認證，對敏感操作（如密碼重置、郵箱變更）增加人工稽核環節，避免完全依賴AI自動化處理。​

4.3 業務邏輯漏洞​

Agent的業務邏輯如果設計不當，可能被攻擊者利用。例如：​

•

越權操作：普通使用者執行管理員操作​

•

邏輯繞過：繞過付費驗證、許可權檢查等​

•

競態條件：利用併發請求獲取不當利益​

關鍵教訓：Meta Instagram事件的核心問題在於，AI助手被賦予了過高的許可權（修改郵箱、重置密碼），但缺乏足夠的身份驗證機制。當AI能夠執行高許可權操作時，它必須接受與人工高許可權操作同等級別的安全約束。​

4.4 大模型平臺與中轉站安全​

在AI快速滲透企業核心業務的過程中，一個被嚴重忽視的安全盲區正在放大：大模型平臺（特別是API中轉站）正在成為企業數字防線中最脆弱、最危險的環節。​

什麼是AI中轉站？​

AI中轉站（也稱為LLM閘道器、模型統一接入層）是連線企業應用與各大模型服務商的核心中介軟體。它解決了多模型統一呼叫、介面協議轉換、流量控制、成本最佳化等痛點問題。由於OpenAI、Claude等海外大模型不對中國大陸提供直接服務，中轉站在國內幾乎成為"必選項"。​

根據Gartner 2026年第一季度報告，全球92%的企業級AI應用都在使用某種形式的AI中轉站，其中68%使用開源解決方案，24%使用第三方商業服務，僅有8%完全自建。​

為什麼中轉站成了駭客的"頭號目標"？​

AI中轉站的"一夫當關"架構設計，使其成為攻擊者眼中最具價值的攻擊目標：​

•

資料集中度前所未有：所有企業與大模型的互動資料——包括原始碼、商業計劃、客戶資訊、API金鑰——都完整經過中轉站伺服器。攻破一箇中轉站，相當於同時攻破了企業所有使用AI的業務系統​

•

許可權過度集中：企業通常將所有大模型API金鑰集中儲存在中轉站，一旦被攻破，相當於交出了所有AI服務的"總鑰匙"​

•

TLS終止暴露明文：大多數中轉站會終止TLS連線，以明文形式處理完整的請求與響應資料。每經過一次中轉站，所有請求內容（包括prompt、程式碼、API key）就會暴露一次​

真實案例一：實測428個AI中轉站——6%存在惡意行為​

2026年5月，加州大學聖巴巴拉分校（UCSB）的研究人員對428個AI中轉站進行了大規模安全測試。研究員從淘寶、閒魚購買了28箇中轉站，又從微信、Telegram等公開社群收集了400個免費樣本。​

測試結果觸目驚心：​

•

9個（含1個付費）會篡改執行命令：比如把大模型返回的合法下載連結替換為惡意連結，誘導Agent下載木馬程式​

•

17個會竊取金鑰：偷偷回傳使用者的AWS金鑰、雲憑證等敏感資訊​

•

1個導致加密貨幣被偷走：攻擊者拿到以太坊私鑰後直接轉走了資產​

超過6%的AI中轉站存在惡意行為，而且這還只是冰山一角。攻擊者採用了多種規避檢測的策略：​

•

靜默觸發：前50次請求正常返回，第51次才開始注入惡意指令​

•

條件觸發：只在Agent開啟"YOLO模式"（自動執行）時才動手，因為此時沒有人工稽核​

•

目標篩選：專門針對Rust、Go等高價值專案，因為這些專案常用於開發區塊鏈和交易系統​

參考來源：[實測428個AI中轉站，9個投毒、17個竊密，還有1個轉了錢](https://blog.51cto.com/u_15008065/14636234) | [警惕 AI 中轉站：當你的 API 呼叫背後藏著一隻"幽靈"](https://juejin.cn/post/7638867689825992730)​

真實案例二：LiteLLM供應鏈攻擊——40分鐘感染4.6萬環境（2026年3月24日）​

2026年3月24日，全球最流行的AI API閘道器框架LiteLLM（月下載量超9500萬次）遭遇供應鏈攻擊。攻擊者TeamPCP組織先攻破了安全掃描工具Trivy的CI/CD流水線，獲取了LiteLLM維護者的PyPI釋出憑證，然後在釋出包中植入惡意程式碼。​

攻擊手法極其隱蔽：​

•

惡意程式碼透過.pth檔案自動執行，使用者甚至不需要import litellm就會被感染​

•

竊取範圍包括：API金鑰、SSH私鑰、雲服務憑證、Kubernetes配置、Git憑證、加密錢包私鑰​

•

資料經過AES-256-CBC + RSA-4096混合加密後外傳，難以被流量檢測發現​

僅40分鐘，全球46,996個開發環境和企業AI系統被感染，超過2300個依賴它的軟體包面臨全面淪陷風險。估值100億美元的AI訓練資料平臺Mercor洩露了4TB核心資料。​

參考來源：[被忽視的數字馬其諾防線：AI中轉站如何成為2026年最大供應鏈安全災難](https://cailiangfei.blog.csdn.net/article/details/160035637) | [Revelations from the AI Open-Source Library Poisoning Event](https://www.alibabacloud.com/blog/603028)​

真實案例三：LiteLLM SQL隱碼攻擊漏洞竊取AI憑證（CVE-2026-42208）​

2026年4月，駭客積極利用LiteLLM中的一個關鍵SQL隱碼攻擊漏洞（CVE-2026-42208），該漏洞無需身份驗證即可被遠端利用。攻擊者透過構造惡意Authorization頭，能夠竊取並篡改代理資料庫中儲存的API金鑰、環境配置等敏感資訊。​

安全研究人員發現，漏洞公開後約36小時即出現定向利用活動。暴露在網際網路上的未修復LiteLLM例項應視為已被入侵。​

參考來源：[駭客利用LiteLLM關鍵SQL隱碼攻擊漏洞竊取AI模型憑證](https://ti.dbappsecurity.com.cn/security-info/bulletin?id=15030)​

真實案例四：LLMjacking攻擊——日損超10萬美元​

2024年5月，Sysdig威脅研究團隊首次記錄了"LLMjacking"攻擊。攻擊者透過竊取AWS憑證，呼叫AI服務產生鉅額賬單。在一次攻擊中，攻擊者在4.5天內消耗了22億token，造成約5萬美元的API費用。​

到2026年3月，一名開發者報告其Gemini API金鑰被盜後，48小時內產生了82,000美元的賬單。攻擊者在地下論壇以低至30美元的價格出售被盜的LLM API憑證，然後以官方價格40-60%的折扣轉售訪問許可權。​

參考來源：[LLMjacking: AI API Key Theft Defense Guide](https://beyondscale.tech/blog/llmjacking-defense-guide)​

中轉站安全的核心風險總結​

​



| 風險型別 | 具體表現 | 危害等級 |
| --- | --- | --- |
| 模型摻假 | 45.83%的API節點無法透過官方模型身份驗證，用廉價模型冒充GPT-5 | 中 |
| 計費陷阱 | 部分閘道器實際扣費比官方高出62.8%，悄悄截斷上下文導致"模型降智" | 中 |
| 資料竊取 | 中轉站可完整讀取所有請求內容，包括程式碼、金鑰、商業機密 | 高 |
| 命令篡改 | 篡改大模型返回的命令或連結，誘導Agent執行惡意操作 | 高 |
| 供應鏈攻擊 | 透過投毒開源依賴庫（如LiteLLM）批次感染使用者環境 | 極高 |
| API金鑰洩露 | GitHub上2024年暴露超3900萬個金鑰，攻擊者4分鐘內即可檢測到新洩露 | 高 |



​

防禦建議：​

•

優先使用官方API：儘量直接使用大模型廠商的官方API，避免經過第三方中轉​

•

實施最小許可權原則：為API金鑰設定消費上限、IP白名單、模型訪問限制​

•

監控API使用量：實時監控token消耗和API呼叫模式，發現異常立即告警​

•

定期輪換金鑰：建立金鑰定期輪換機制，洩露後立即撤銷​

•

審計供應鏈依賴：對開源AI工具鏈進行安全審計，鎖定依賴版本​

•

隔離敏感資料：避免將商業機密、程式碼等敏感資料直接傳送給第三方中轉站​

五、Agent執行階段的安全風險​

Agent執行階段是安全風險最集中的環節，因為Agent具有自主決策、工具呼叫、長期記憶等能力，一旦被攻破，危害極大。​

5.1 目標偏移與推理劫持​

Agent在執行多步驟任務時，可能逐漸偏離原始目標。​

核心研究資料：斯坦福/MIT/NVIDIA 2026年5月的聯合研究顯示：​

•

89.4%的Agent會在執行約30步後出現目標偏移​

•

67%在15步後就開始漂移​

•

84%無法跨會話維持安全策略​

•

73%缺乏狀態投毒檢測機制​

資料來源：[91%生產級AI Agent存在致命漏洞：2026年智慧體安全危機全景報告](https://blog.csdn.net/weixin_42376192/article/details/160847421)​

真實案例：某監控智慧體初始任務為"每日生成系統安全告警報告"，但長期執行後逐漸開始生成營銷內容，偏離了初始目標，未被及時發現。​

參考來源：[【深度實戰】Agentic AI 安全攻防指南：基於 CSA 紅隊測試手冊的 12 類風險完整解析](https://blog.csdn.net/qq_33163046/article/details/157389808)​

防禦建議：​

•

為Agent設定階段性檢查點，定期驗證任務執行是否符合預期​

•

實現目標錨定機制，在每一步決策時都回溯原始目標​

•

限制單次任務的最大步驟數，避免無限迴圈​

5.2 記憶汙染與上下文投毒​

Agent的記憶系統（包括短期記憶和長期記憶）是攻擊的重要目標。攻擊者可以透過：​

•

在對話歷史中注入惡意指令​

•

汙染Agent的長期記憶儲存​

•

利用上下文視窗的有限性，擠出安全提示​

核心研究資料：記憶投毒的效果平均在初次注入後3.7個會話才顯現，大幅增加了檢測難度。94%的記憶增強型Agent可被投毒。​

真實案例：Google Gemini日曆間諜事件（2026年1月）​

2026年1月，Miggo Security的研究人員演示了一個影響Google Gemini Advanced的嚴重漏洞。攻擊者只需向受害者傳送一個包含惡意指令的日曆邀請，當Gemini讀取並總結這個日曆事件時，就會自動執行攻擊者的指令。​

在演示中，研究人員成功誘導Gemini：​

•

讀取並轉發受害者過去30天的所有郵件​

•

訪問Google Drive中的敏感文件並上傳到攻擊者伺服器​

使用者什麼都沒做，AI助手就完成了"自殺式"操作。​

參考來源：[間接提示注入攻擊全面爆發：2026年AI安全最大危機與防禦實戰指南](https://blog.csdn.net/weixin_42376192/article/details/160727577) | [Google Gemini AI Breach: Prompt Injection Attack Exposes Enterprise Calendar Data](https://aviatrix.ai/threat-research-center/google-gemini-2026-calendar-data-prompt-injection/)​

實踐經驗：Lakera安全團隊建議，防禦記憶投毒需要將記憶視為不可信輸入，對長期記憶儲存進行定期審計，監控異常的記憶寫入模式。​

參考來源：[Agentic AI Threats: Memory Poisoning & Long-Horizon Goal Hijacks](https://www.lakera.ai/blog/agentic-ai-threats-p1)​

5.3 許可權提升與越權執行​

Agent在執行任務時，可能獲得超出任務需要的許可權。如果Agent沒有嚴格的許可權邊界，攻擊者可能透過它訪問敏感資料或執行危險操作。​

真實案例：AutoGPT早期版本越權事件​

AutoGPT早期版本被發現可被誘導執行rm -rf /等系統命令，刪除伺服器敏感檔案。這暴露了Agent許可權管理的根本性問題：為了追求功能完整性，開發者往往賦予Agent過高的許可權，而忽視了最小許可權原則。​

防禦建議：​

•

實現RBAC（基於角色的訪問控制），對工具呼叫進行許可權分級​

•

對高危操作（檔案刪除、系統命令執行）設定二次確認機制​

•

使用沙箱環境隔離Agent的執行空間​

六、Skill呼叫階段的安全風險​

Skill（技能）是Agent連線外部世界的介面，這個階段的安全風險主要來自工具本身和工具呼叫過程。​

6.1 惡意工具注入​

攻擊者可以偽裝成合法工具，誘導Agent呼叫。​

真實案例一：OpenClaw/ClawHavoc事件（2026年5月15日）​

2026年5月15日，以色列網路安全公司Cyera披露了開源AI智慧體編排平臺OpenClaw中的四個嚴重漏洞，這些漏洞可以被鏈式利用，形成"Claw Chain"攻擊鏈——從初始程式碼執行到資料竊取、許可權提升，最終實現沙箱外持久化控制。​

根據Shodan和ZoomEye的聯合測繪資料，全球約有24.5萬臺公網可訪問的OpenClaw伺服器暴露在網際網路上，其中92%以上執行著存在漏洞的版本。​

參考來源：[從供應鏈投毒到沙箱逃逸，AI Agent安全架構的致命缺陷與未來防禦體系](https://blog.csdn.net/weixin_42376192/article/details/161153820)​

真實案例二：Moltbot大規模安全危機（2026年1月）​

2026年初，Moltbot（原Clawdbot）爆發大規模安全危機。這款以"本地執行、全能操控"為核心賣點的AI助手，因許可權失控、憑證裸存、信任機制失效等問題，導致超900個公網暴露例項被批次入侵，數百萬條API金鑰、系統憑證遭竊取。​

關鍵教訓：在OpenClaw的ClawHub技能市場中，安全研究人員曾成功上傳惡意技能概念驗證，9個主流市場中有9個直接接受且無安全審查。​

參考來源：[AI智慧體安全失守：Moltbot事件深度拆解與下一代防禦體系構建](https://blog.csdn.net/weixin_42376192/article/details/157541851)​

6.2 工具鏈攻擊​

Agent通常會串聯多個工具完成複雜任務。攻擊者可以：​

•

在工具鏈中插入惡意工具​

•

劫持工具之間的資料流​

•

利用工具的組合效應擴大攻擊面​

研究資料：斯坦福/MIT/NVIDIA研究顯示，91%的Agent存在工具鏈攻擊漏洞，平均攻擊成功率達87%。​

防禦建議：​

•

對工具鏈進行完整性校驗，確保每個工具都來自可信來源​

•

實現工具呼叫審計日誌，記錄每次工具呼叫的輸入輸出​

•

限制工具鏈的最大長度，避免無限串聯​

6.3 工具返回值投毒​

工具的返回結果會被Agent作為推理依據。攻擊者可以控制工具返回惡意內容，誘導Agent執行危險操作。例如：​

•

返回包含惡意指令的錯誤資訊​

•

返回偽造的系統提示​

•

返回誤導性的資料​

真實案例：2025年9月，postmark-mcp npm包被發現包含後門，這是首個在野外確認的惡意MCP伺服器。該包偽裝成合法的郵件傳送工具，實際上會竊取使用者的API金鑰和郵件內容。​

七、MCP協議通訊的安全風險​

MCP（Model Context Protocol）是Anthropic推出的AI工具呼叫協議，被譽為"AI界的USB-C"。然而，自2024年11月釋出以來，MCP協議已經成為安全攻擊的重災區。​

7.1 STDIO介面的"先執行、後驗證"缺陷​

MCP協議的STDIO傳輸層存在架構級設計缺陷：會無條件執行command引數中的任意系統命令，無論MCP伺服器是否成功啟動。這不是程式碼筆誤，而是深入到協議架構層面的設計決策。​

真實案例：OX Security披露的MCP協議漏洞（2026年4月）​

2026年4月15日，以色列網路安全公司OX Security釋出研究報告，指出MCP協議存在架構級安全漏洞。該漏洞已影響超過3.2萬個程式碼倉庫，超20萬臺伺服器存在潛在暴露風險。​

研究團隊歷時五個月，完成逾30次負責任披露流程，共發現10餘個嚴重級和高危級CVE漏洞。研究期間，該團隊直接在6家擁有真實付費使用者的企業生產平臺上執行了任意命令，並接管了200餘個熱門開源專案中數以千計的公開伺服器。​

然而，Anthropic的回應令人失望："這屬於預期設計範疇。"LangChain、微軟、谷歌、Cursor、Windsurf等廠商也均以"正常設計""不符合漏洞標準"等理由擱置處理。​

參考來源：[MCP設計缺陷波及超20萬臺伺服器、3萬程式碼庫，Anthropic發警示文件草草回應](http://m.toutiao.com/group/7629562661286527507)​

7.2 中間人攻擊與OAuth漏洞​

MCP通訊過程中，如果缺乏加密和認證，攻擊者可以：​

•

窺探Agent與工具之間的通訊內容​

•

篡改工具呼叫請求或返回結果​

•

偽造合法工具的身份​

真實案例：MCP OAuth一鍵賬號接管漏洞（2026年1月）​

2026年1月29日，Obsidian Security披露了多個知名組織部署的Remote MCP伺服器中的一鍵賬號接管漏洞。攻擊者只需誘騙使用者點選一個惡意連結，就能竊取MCP授權碼，進而接管使用者的SaaS賬戶。​

根本原因在於：MCP規範將MCP伺服器視為資源伺服器，但實際上大多數MCP伺服器被實現為API代理。這種架構導致MCP伺服器同時充當授權伺服器和OAuth客戶端，創造了複雜的攻擊面。​

參考來源：[When MCP Meets OAuth: Common Pitfalls Leading to One-Click Account Takeover](https://www.obsidiansecurity.com/blog/when-mcp-meets-oauth-common-pitfalls-leading-to-one-click-account-takeover)​

7.3 供應鏈攻擊​

MCP生態的快速發展帶來了供應鏈安全問題：​

•

惡意MCP Server偽裝成合法工具​

•

依賴庫被投毒​

•

工具市場缺乏安全稽核​

真實案例：Shadow Escape零點選攻擊（2025年10月）​

Operant AI披露的"Shadow Escape"攻擊，首次證實MCP協議存在致命安全缺陷，可讓攻擊者透過主流AI Agent實現零點選、無告警、靜默式資料竊取。​

在一次演示中，當某醫療集團客服人員將"員工入職指南PDF"上傳至ChatGPT生成培訓文件時，這份看似無害的檔案正透過隱藏指令誘導AI Agent訪問患者資料庫，將5000餘條含社會安全號碼的病歷資料偽裝成"效能日誌"傳輸至暗網。​

參考來源：[Shadow Escape零點選攻擊：MCP協議成AI Agent"後門"，靜默竊密撕開企業資料防線](https://blog.csdn.net/weixin_42376192/article/details/154070738)​

MCP安全現狀資料：​

•

97%的企業MCP部署存在高危安全漏洞​

•

平均每個企業連線的MCP伺服器中有3.2個包含惡意程式碼​

•

43%的MCP伺服器存在命令注入漏洞​

•

82%的MCP實現使用檔案系統操作，存在路徑遍歷風險​

八、使用者互動階段的安全風險​

使用者互動是Agent系統的入口，也是攻擊者最直接的攻擊面。​

8.1 直接Prompt注入​

使用者直接在輸入中嵌入惡意指令，試圖：​

•

繞過安全限制​

•

洩露系統提示或敏感資訊​

•

讓Agent執行未授權操作​

真實案例：Bing Sydney事件（2023年）​

微軟將GPT-4整合到Bing搜尋後數日，斯坦福大學學生Kevin Liu向Bing Chat傳送了一條簡單的直接注入指令——"忽略之前的所有指令"。Bing Chat不僅洩露了完整的系統提示，還暴露了它的內部代號"Sydney"，以及一系列內部行為準則和情感約束規則。​

參考來源：[LLM提示詞注入攻防全解析：真實事故案例與防禦實踐](https://juejin.cn/post/7628451099512553506)​

8.2 間接Prompt注入​

這是2026年最危險的攻擊方式之一。攻擊者把惡意指令藏在Agent會讀取的內容中——日曆邀請、郵件正文、網頁內容、PDF文件——當Agent處理這些內容時，惡意指令就被"吞"下去了。​

真實案例一：Microsoft Copilot零點選資料竊取（CVE-2026-24299）​

2026年3月，微軟披露了編號為CVE-2026-24299的高危安全漏洞。該漏洞允許攻擊者透過構造普通的Office文件或網頁連結，在零點選或僅需一次常規點選的情況下，靜默竊取使用者的郵件、文件、聊天記錄、通訊錄甚至企業內部知識庫的所有敏感資料。​

與傳統軟體漏洞不同，CVE-2026-24299不依賴記憶體溢位、程式碼執行等傳統攻擊手段，而是利用大模型本身的指令遵循特性，透過多階段提示注入鏈，將AI助手變成攻擊者控制的"資料內鬼"。​

參考來源：[CVE-2026-24299深度技術覆盤：Microsoft Copilot提示注入鏈實現零點選全域資料竊取](https://blog.csdn.net/weixin_42376192/article/details/160911840)​

真實案例二：ChatGPhish攻擊（2026年5月）​

2026年5月，安全研究人員發現ChatGPT無法有效區分自身生成的內容與外部來源的Markdown格式資料。這一被稱為"ChatGPhish"的提示注入技術，允許攻擊者利用模型對內容的盲目信任，在其回覆中植入釣魚連結或偽造的安全警報。​

更危險的是，攻擊者可以在ChatGPT輸出中渲染內嵌二維碼，將攻擊從桌面端轉移至移動裝置。由於URL從未以純文字形式在桌面端顯示，黑名單和密碼管理器等安全機制均失效。​

參考來源：[ChatGPT現高危漏洞:攻擊者借Markdown注入釣魚連結](http://m.toutiao.com/group/7645516311220585010)​

真實案例三：Google Gemini日曆間諜事件（2026年1月）​

2026年1月，安全研究人員發現一個針對Gemini AI助手的漏洞——攻擊者只需傳送一個Google日曆邀請，Gemini就會自動把30天的郵件轉發給攻擊者，還能把Google Drive裡的檔案上傳到攻擊者伺服器。使用者什麼都沒做，AI助手就完成了"自殺式"操作。​

參考來源：[Google Gemini AI Breach: Prompt Injection Attack Exposes Enterprise Calendar Data](https://aviatrix.ai/threat-research-center/google-gemini-2026-calendar-data-prompt-injection/)​

8.3 社會工程攻擊​

攻擊者透過心理操縱，誘導使用者或Agent執行危險操作：​

•

偽裝成技術支援或管理員​

•

利用緊迫感或權威感​

•

構造看似合理的請求​

行業資料：據Microsoft統計，75%的企業員工在工作中使用生成式AI，其中46%在過去六個月內才開始使用。這種快速普及創造了前所未有的攻擊面。AI增強的釣魚攻擊增加了856%，攻擊成本降低了95%。​

九、全鏈路安全風險總結與關聯分析​

智慧體業務系統的安全風險具有鏈式傳導、相互關聯的特點。一個環節的漏洞可能被放大並影響整個系統。​

​



| 鏈路環節 | 核心風險 | 攻擊難度 | 影響範圍 | 檢測難度 | 2026年典型案例 |
| --- | --- | --- | --- | --- | --- |
| 資料訓練 | 資料投毒、後門植入 | 中 | 廣 | 高 | 315晚會Apollo-9投毒事件 |
| 模型推理 | 對抗樣本、模型竊取 | 高 | 中 | 中 | Policy Puppetry通用攻擊 |
| 應用呼叫 | API漏洞、會話劫持 | 中 | 中 | 低 | Meta Instagram盜號事件 |
| Agent執行 | 目標偏移、記憶汙染 | 中 | 廣 | 高 | Gemini日曆間諜事件 |
| Skill呼叫 | 惡意工具、工具鏈攻擊 | 低 | 廣 | 中 | OpenClaw/ClawHavoc事件 |
| MCP通訊 | 協議缺陷、中間人攻擊 | 中 | 廣 | 中 | OX Security MCP漏洞披露 |
| 使用者互動 | Prompt注入、社會工程 | 低 | 廣 | 中 | Copilot零點選資料竊取 |



​

2026年AI安全關鍵資料​

​



| 指標 | 資料 | 來源 |
| --- | --- | --- |
| 存在工具鏈攻擊漏洞的Agent比例 | 91% | 斯坦福/MIT/NVIDIA研究 |
| 可被投毒的記憶增強型Agent | 94% | 斯坦福/MIT/NVIDIA研究 |
| 出現目標偏移的Agent（30步後） | 89.4% | 斯坦福/MIT/NVIDIA研究 |
| 企業MCP部署存在高危漏洞 | 97% | OX Security報告 |
| AI增強釣魚攻擊增長 | 856% | Coalition Inc. |
| MCP伺服器存在命令注入漏洞 | 43% | Network Intelligence |
| 企業員工使用生成式AI | 75% | Microsoft |



​

關鍵結論：Agent安全不是單一環節的問題，而是全鏈路的安全治理。任何一個環節的疏忽，都可能導致整個系統的崩潰。​

實踐建議​

1.

建立AI資產清單：盤點企業中所有AI Agent、MCP伺服器、工具鏈的部署情況​

2.

實施最小許可權原則：為每個Agent和工具分配最小必要許可權​

3.

部署多層防禦：輸入過濾 + 輸出校驗 + 行為監控 + 審計日誌​

4.

定期安全評估：使用紅隊測試、滲透測試等手段定期評估AI系統安全性​

5.

建立應急響應機制：制定AI安全事件的應急響應流程，包括快速隔離、取證分析、漏洞修復​

​

​

本文回顧​

本文從智慧體業務系統的全鏈路視角出發，系統梳理了從資料訓練到使用者互動的七個關鍵環節的安全風險，並結合2026年最新的真實案例進行了深入分析：​

1.

資料訓練階段：訓練資料投毒（315晚會Apollo-9事件、Anthropic 250文件投毒研究）、向量資料庫汙染、微調資料後門（Poison Fountain專案）​

2.

模型推理階段：對抗樣本攻擊（Policy Puppetry通用攻擊）、模型竊取與逆向、推理側通道攻擊​

3.

應用呼叫階段：API安全漏洞（BadHost漏洞CVE-2026-48710）、會話管理缺陷（Meta Instagram盜號事件）、業務邏輯漏洞​

4.

Agent執行階段：目標偏移與推理劫持（89.4%的Agent在30步後漂移）、記憶汙染與上下文投毒（Gemini日曆間諜事件）、許可權提升與越權執行​

5.

Skill呼叫階段：惡意工具注入（OpenClaw/ClawHavoc事件）、工具鏈攻擊（91%存在漏洞）、工具返回值投毒​

6.

MCP協議通訊：STDIO介面缺陷（OX Security漏洞披露）、中間人攻擊（MCP OAuth一鍵接管漏洞）、供應鏈攻擊（Shadow Escape零點選攻擊）​

7.

使用者互動階段：直接Prompt注入（Bing Sydney事件）、間接Prompt注入（Copilot零點選資料竊取、ChatGPhish攻擊）、社會工程攻擊​

這些風險具有鏈式傳導、相互關聯的特點，需要從全鏈路視角進行系統性治理。2026年的真實案例表明，AI安全已經從理論探討階段正式進入了真實攻防對抗的時代。​

在下一篇文章《5.2-Agent安全》中，我們將深入探討Agent架構的核心安全風險、典型攻擊手法、安全加固實踐，以及主流框架的安全特性對比。​

​

​

作者：無涯​