1.關鍵組件定義

• KC1 生成式語言模型（Generative Language Models）
  • KC1.1 大語言模型（LLMs）：作為代理的“大腦”，基于預訓練基礎模型（如 GPT 系列、Claude、Llama、Gemini），通過 prompt 工程和細調等方式實現推理、規劃與生成。
  • KC1.2 多模態 LLM（MLLMs）：可處理多種數據類型（如文本、圖像、音頻），拓展任務能力（如 GPT-4V、Gemini）。
  • KC1.3 小型語言模型（SLMs）：參數量少，專注于特定任務，訓練數據集更小更專用。
  • KC1.4 微調模型：通過特定數據集進一步訓練，提升在特定任務、領域或交互風格下的表現（如 SFT、CB）。
• KC2 編排（Orchestration/Control Flow）
  • KC2.1 工作流（Workflows）：預定義的任務序列或步驟。
  • KC2.2 分層規劃（Hierarchical Planning）：通過編排器（Orchestrator）接收任務、分解子任務、路由到專用代理，并動態優化流程。
  • KC2.3 多代理協作（Multi-agent Collaboration）：多個代理協作完成復雜任務，各自負責數據收集、分析或決策等。
• KC3 推理/規劃范式（Reasoning / Planning Paradigm）
  • KC3.1 結構化規劃/執行：任務分解、動作序列定義、計劃與執行分離。
  • KC3.2 ReAct（Reason + Act）：推理與行動交替進行，并根據反饋動態調整。
  • KC3.3 Chain of Thought（CoT）：分步推理，生成一系列“思考”后給出結論。
  • KC3.4 Tree of Thoughts（ToT）：并行探索多條推理路徑，帶回溯和自我評估。
• KC4 內存模塊（Memory Modules）： 管理短期（當前上下文）和長期信息（歷史交互、知識），支持個性化與連貫交互，常見場景包括 RAG（通過向量數據庫實現長期記憶）。
  • KC4.1 代理會話內記憶（In agent session memory） ：內存僅限于單個代理和單個會話。即使被攻破，也僅影響當前代理和會話，無法擴大影響范圍。
  • KC4.2 跨代理會話記憶（Cross-agent session memory） ：內存在多個代理之間共享，但僅限于單一會話。若某代理在會話中被攻破，可能影響該會話下的所有代理，但不會影響其他會話。
  • KC4.3 代理跨會話記憶（In agent cross-session memory） ：內存僅限于單一代理，但跨多個會話共享。若某會話被攻破，可能影響該代理在所有會話下的記憶，但不會影響其他代理。
  • KC4.4 跨代理跨會話記憶（Cross-agent cross-session memory） ：內存在多個代理和多個會話之間共享。若某代理在某會話被攻破，可能影響所有會話和所有代理，風險擴大。
  • KC4.5 代理跨用戶記憶（In agent cross-user memory） ：內存僅限單一代理，但在多個用戶間共享。若代理被攻破，可能影響所有用戶的數據安全。
  • KC4.6 跨代理跨用戶記憶（Cross-agent cross-user memory）： 內存在多個代理和多個用戶間共享。若被攻破，可能影響所有代理和所有用戶，屬于最高風險類型。
• KC5 工具集成框架（Tool Integration Frameworks） ： 讓代理通過 API、函數、數據存儲等工具與外部世界交互
  • KC5.1 靈活庫/SDK：如 LangChain、CrewAI，賦予開發者高度定制性。
  • KC5.2 托管平臺/服務：如 Amazon Bedrock Agents、Microsoft Copilot Platform，簡化部署與集成。
  • KC5.3 托管 API：如 OpenAI Assistants API，主打 API 交互，簡化復雜狀態與工具編排。
• KC6 運行環境（Operational Environment）： 通過工具與函數調用，代理可與外部環境交互，獲取和處理外部信息。
  • KC6.1 API 訪問（API Access）
    • KC6.1.1 有限 API 訪問（Limited API Access）：代理僅能調用預定義 API，LLM 只生成部分參數。適用場景如調度日程、發送郵件等，通常有權限和認證控制，能夠限制潛在損害范圍。
    • KC6.1.2 廣泛 API 訪問（Extensive API Access）：代理可生成完整 API 調用（如動態構建 REST/GraphQL 查詢）。風險較高，若代理被攻陷，可能濫用授權發起未授權操作或攻擊 API。
  • KC6.2 代碼執行（Code Execution）
    • KC6.2.1 有限代碼執行能力（Limited Code Execution Capability）：代理僅能調用特定函數并提供部分參數。如預定義的 Python、JS 等函數。若遭攻擊，可能發生參數注入等代碼注入風險。
    • KC6.2.2 廣泛代碼執行能力（Extensive Code Execution Capability）：代理可直接運行 LLM 生成的任意代碼。若被攻陷，風險極高，可能導致任意代碼執行（RCE）。
  • KC6.3 數據庫執行（Database Execution）
    • KC6.3.1 有限數據庫執行能力（Limited Database Execution Capability）：代理僅能對數據庫進行有限的查詢或寫入（如只讀、參數化寫入）。若被攻陷，數據泄露或破壞范圍有限。
    • KC6.3.2 廣泛數據庫執行能力（Extensive Database Execution Capability）：代理可執行所有 CRUD 操作。若被攻陷，可造成任意數據泄露、修改或刪除。
    • KC6.3.3 代理記憶 / 上下文數據源（Agent Memory or Context Data Sources）：代理與外部知識庫或上下文數據交互（如 RAG 模式）。若被攻陷，可能導致數據投毒或錯誤信息傳播。
  • KC6.4 網頁訪問能力（Web Access Capabilities, web-use）： 代理可通過瀏覽器與網頁互動（如爬取內容、操作頁面），若暴露于不可信網頁，可能被利用進行未授權操作（如更改賬戶設置）。
  • KC6.5 PC 操作控制（Controlling PC Operations, PC-use）： 代理可操作本地操作系統（如文件系統訪問）。風險包括數據泄露、惡意操作（如加密、刪除文件）等。
  • KC6.6 關鍵系統操作（Operating Critical Systems, 如 SCADA）：代理可控制關鍵基礎設施系統。若被攻陷，可能引發嚴重業務中斷或安全事故。
  • KC6.7 IoT 設備訪問（Access to IoT Devices）：代理可控制物聯網設備。若被攻陷，可能對物理環境造成影響（如調整溫度、開關設備等）。

---

關鍵組件（KC）	主要相關威脅類型（T代碼）	典型攻擊面與脆弱性
KC1 - Large Language Models (大模型)	T5, T6, T7, T15	幻覺，目標不一致，欺騙性推理，操縱人類
KC2 Orchestration（控制流）	T6, T8, T9, T10, T12, T13, T14	流程操控、身份混淆、審計缺失、多代理攻擊、HITL過載等
KC3 Reasoning/Planning（推理）	T5, T6, T7, T8, T15	幻覺級聯、意圖操控、決策不可追溯、人類操縱等
KC4 Memory Modules（記憶）	T1, T3, T5, T6, T8, T12	記憶投毒、越權訪問、數據泄漏、證據篡改、通信投毒等
KC5 Tool Integration（工具整合）	T2, T3, T6, T8, T11	工具誤用、權限濫用、未記錄操作、意外代碼執行等
KC6 Operational Environment（運行環境）	T2, T3, T4, T10, T11, T12, T13, T15	訪問誤用、特權濫用、資源耗盡、RCE、側信道、監控盲區、環境操縱等

Txx 的定義參考：Agentic AI - Threats and Mitigations

---

2.安全架構模式

安全的 Agentic 架構，絕不是簡單把各個組件“加固”就能萬事大吉。關鍵在于——安全理念必須嵌入每個架構層級和組件流轉環節。

核心組件分析：

• 語言模型（LLMs、MLLMs、SLMs、微調模型）：是代理的“大腦”，但也極易被幻覺、目標操控等攻擊威脅。
• 編排控制（Orchestration）：決定任務流向和代理分工，身份混淆、流程操控、高負載等風險突出。
• 推理規劃（CoT、ToT、ReAct）：推理鏈越長，幻覺和意圖操控風險越高。
• 記憶模塊：記憶共享范圍越廣，數據泄露和越權訪問風險越大，尤其是跨代理、跨用戶的場景。
• 工具集成：API、SDK、平臺服務等，最怕工具誤用和權限濫用。
• 運行環境：API/代碼/數據庫/網頁/操作系統/IoT 設備，每增加一種能力，都意味著新的攻擊面。

安全架構模式：

• 工具使用模式、反思模式、RAG 檢索增強模式，是所有主流框架的基礎，但同時也是安全控制的關鍵落點。
• 框架選型上，LangChain、AutoGPT、MetaGPT、CrewAI 等各有側重，需根據實際業務和安全需求定制架構。

架構類型舉例

架構類型	關鍵安全點	典型風險
串行代理架構	會話內記憶、有限 API	單點故障，記憶泄露局限于單會話
分層代理架構	分層規劃、跨代理會話記憶	子代理被攻陷可能波及全會話，身份/權限混淆
協作式代理集群	多代理協作、跨代理記憶	任一代理被攻陷可擴大影響，決策不可追溯
響應式代理架構	多模態、ReAct推理、托管API	工具/API濫用，prompt注入
知識密集型代理	RAG、持久知識記憶、數據連接器	數據投毒、錯誤信息傳播

新架構模式與傳統 AI 防護

如果你習慣了傳統 AI 安全，只需給模型和 API 加權限、做審計、設防注入——Agentic 架構可能會讓你大跌眼鏡。

傳統 AI 安全：

• 關注模型本身和輸入輸出接口
• 權限控制、認證、注入防御

Agentic 架構安全：

• 關注多代理協作、記憶流轉、工具混用
• 必須考慮隔離機制、最小權限、通信安全、行為追溯
• 沒有隔離的場景下，單點被攻陷可能牽連整個系統

---

3.Agentic AI 開發者安全指南

與傳統 AI 系統相比，Agentic AI 擁有更豐富的推理能力、動態角色分工和復雜的記憶機制。這讓系統極具靈活性，卻也讓安全風險成倍增長：

• 上下文投毒、數據泄露、目標操控成了常態威脅；
• 每個組件之間的協作與數據流動，都會引入新漏洞；
• 運維階段的日志、監控、身份管理等，稍有疏忽就可能導致嚴重后果。

這種“全鏈路風險”讓我深刻意識到，安全絕不能是事后補救，而必須從設計、開發到部署、運維，每一步都要有針對性的防護措施。

設計與開發階段

威脅建模

• 不可跳過，建議參考 OWASP GenAI、Agentic AI - Threats and Mitigations，細致分析系統獨有的風險面。

系統提示工程與加固

• 明確允許/禁止的操作和話題，強制白名單策略。
• 系統指令與用戶輸入嚴格分隔（XML標簽、反引號等），防止 prompt injection。
• 角色定義錨定行為，迭代優化 prompt，微調需謹慎，確保安全性不被覆蓋。

安全編碼實踐

• 輸入校驗、白名單優先，錯誤處理不能泄漏內部信息。
• 密鑰禁止硬編碼，建議用環境變量或專用密鑰管理服務。

內容審核集成

• 明確審核標準，選擇合適工具（如 LlamaGuard、Comprehend、OpenAI Moderation API），持續測試審核效果。

人工審核（HITL）設計

• 高風險操作必須有人工審批，設計清晰工作流界面，速率限制防止 DOS 攻擊。

存儲安全設計

• 記憶區（如向量數據庫）要做訪問控制、加密、數據凈化和敏感信息脫敏。關鍵內存操作建議引入人工審批。

輸入/輸出校驗與凈化

• 所有數據流轉前都要凈化、轉義特殊符號，避免拼接原始輸入到模板。

授權與認證

• 明確權限邊界，采用 OAuth2、OIDC、DID 等標準認證與授權。

---

構建與部署階段

靜態分析與代碼掃描（SAST）

• 集成 Bandit、Semgrep 等工具到 CI/CD，自動檢測安全漏洞。

依賴漏洞掃描（SCA）

• 定期掃描第三方庫，及時更新有風險依賴。

環境加固與沙箱化

• 使用 Docker、虛擬機、Wasm、沙箱解釋器等，限制代理進程權限，最小化攻擊影響面。

安全配置管理

• 密鑰等敏感數據用專用管理系統（如 AWS Secrets Manager），定期輪換，絕不寫入日志。

預發布測試

• 對 prompt、API 進行 fuzzing 和滲透測試，工具如 PromptFoo、PyRIT、Garak。

運行時安全與內存隔離

• 區分可信/不可信數據流，控制流和數據處理分離，避免敏感數據泄漏。

數據面與控制面分離

• 控制消息需更強認證，防止被劫持。

即時訪問與臨時憑證

• 使用短時效 Token、自動過期，縮短憑證被濫用窗口。

---

運維與運行時階段

持續監控與異常檢測

• 實時監控輸入/輸出、工具調用、計劃執行、內存更新等，集成 SIEM 平臺自動告警與響應。

運行時 Guardrails 與內容審查

• 輸入、模型、工具、輸出層多點部署 Guardrails，優先保護輸出影響最大的代理節點。
• 內存區設置過期、凈化、PII 檢測與脫敏，限制上下文窗口防信息泄漏。
• Web 端輸出需凈化和啟用 CSP，防止 XSS 等攻擊。

日志、審計與可追溯性

• 集中式日志，結構化格式，日志只讀，敏感信息脫敏或加密。所有操作都要可追蹤，便于溯源。

運行時漏洞掃描

• 定期掃描環境和接口，發現漏洞及時打補丁。

事件響應計劃

• 明確安全事件定義，隔離分析修復流程，分配責任并定期演練。

AI Bot 防護與身份管控

• 多層身份信號組合（IP、UA、加密簽名、ANS），有效防止偽造和欺騙。

Agentic 安全實踐的“全景對比”

階段	傳統 AI 安全措施	Agentic AI 安全新范式
設計開發	代碼審查、常規輸入校驗	威脅建模、系統提示加固、角色定義、HITL設計
構建部署	SAST、簡單環境隔離	沙箱化、多級配置管理、敏感憑證輪換、預發布模糊測試
運維運行	日志監控、定期漏洞掃描	多層 Guardrails、內存凈化、自動審查、AI Bot防護、事件響應演練

---

4. Agentic AI 系統增強安全行動

一、為什么 Agentic AI 的安全要針對架構分層設計？

單代理系統看似簡單，權限和數據流可控，但一旦擴展到多代理協作，尤其是無中心分布式網格，安全難度急劇提升：

• 權限分配不當，單個代理被攻陷就能濫用系統資源；
• 編排器或通信通道被劫持，整個業務流程可能被篡改；
• 分布式身份認證和信任鏈管理，稍有疏忽就會遭遇虛假代理滲透。

二、分架構的安全行動清單

1. 單代理系統安全行動

認證與授權

• 使用 OAuth2.0/OIDC，保證代理只在授權范圍內操作資源。
• 優先托管身份服務（如 AWS/Azure），避免硬編碼憑據。
• 實施基于角色的訪問控制（RBAC），細分讀寫權限，定期審核。
• 授予最小必要權限，推薦即時憑證（短時效、自動過期）。

數據保護

• 全程加密（TLS 1.2+、AES-256-GCM），防止數據泄漏。
• 部署 DLP 方案，自動檢測并阻斷敏感信息外泄。
• 數據分類與敏感度標簽，確保合規訪問。
• 數據最小化，只收集執行任務所需信息。

代碼安全

• 集成 SAST、DAST、SCA 到 CI/CD，自動化安全測試。
• 代碼上線前做人工和自動審查，關注 AI 系統特有風險。
• 依賴庫持續漏洞監控，自動預警。

監控與事件響應

• 全面日志記錄，建立行為基線，敏感操作日志做高等級分類。
• 實時異常檢測（ML驅動 SIEM），異常告警、緊急斷開機制。
• 制定詳細事件響應預案，包括隔離、調查、修復和恢復。

Prompt安全

• 輸入校驗（規則/NLP），防止惡意內容流入。
• 輸出內容過濾，阻止有害信息外泄。
• 強化系統提示，將安全策略嵌入 AI 指令，凈化和規范所有輸入。

---

2. 多代理系統與編排器安全行動

認證與授權

• 每個代理獨立最小權限，嚴格控制數據/控制平面分離。
• 代理間操作必須認證和授權，敏感操作基于用戶授權動態轉化。

編排器安全

• 編排器接口加固，強認證、權限驗證、輸入校驗、流量限速。
• 響應內容完整性和來源校驗，防止指令篡改和任務劫持。
• 防范“Confused Deputy”攻擊，通過請求上下文和交叉驗證。

代理間通信

• 強加密協議（mTLS）、雙向認證，通信雙方可信。
• 僅允許已知發現服務器通信，硬編碼可信地址。
• 結構化消息協議（JSON-RPC 2.0）、schema校驗。
• 安全消息隊列認證與加密，策略執行點實時審查，限流與指數退避機制防資源耗盡。

信任邊界管理

• 明確代理之間、代理與編排器的信任邊界，推行零信任架構。
• 操作和數據流持續驗證，多重校驗與審計，及時阻斷異常訪問。

---

3. 分布式代理網格（Swarm Architecture）安全行動

認證與授權

• 分布式身份認證（加密證書、密鑰或分布式協議）。
• 動態權限控制，代理加入/退出自動調整權限。
• 嚴格最小權限原則，防止單點失效。

去中心化身份與信任

• 去中心化身份基礎設施（如 DID、區塊鏈），身份注冊、查驗、撤銷。
• 信任鏈、聲譽系統防冒名頂替與Sybil攻擊。
• 可撤銷、可更新身份，失效代理自動退出系統。

點對點通信安全

• 端到端加密（公私鑰協商）、消息簽名與完整性校驗。
• 密鑰輪換、會話密鑰防中間人攻擊。
• 流控、速率限制和異常檢測防濫用，健壯身份驗證確保參與代理可信。

三、分架構安全要點一覽

架構類型	認證與授權	數據保護	通信安全	信任邊界管理
單代理系統	OAuth2.0/OIDC、RBAC	本地加密、DLP	API安全	明確代理與資源
多代理+編排器	獨立權限、動態授權	分類標簽、最小化	mTLS、隊列加密	零信任、邊界審計
分布式代理網格	DID、分布式證書	動態數據權限	端到端加密	信任鏈、聲譽系統

---

5. 關鍵操作能力

為什么操作能力是 Agentic AI 的安全高危區？

AI代理的最大魅力在于能主動調用 API、執行代碼、讀寫數據庫、瀏覽網頁，甚至操控操作系統和基礎設施。但正是這些“能力”，讓攻擊面大幅擴展：

• API密鑰泄露、權限越界，輕則數據外泄，重則徹底失控；
• 代碼執行、數據庫操作稍有疏忽，直接被注入或遠程攻擊；
• Web和操作系統訪問，可能被惡意網頁或命令劫持；
• 關鍵系統操作，一旦被攻陷，可能造成災難性物理后果。

每一種操作能力，都需要專屬的安全策略和隔離機制，否則就是在“裸奔”。

---

六大操作能力的安全防控清單

1. API訪問（KC6.1）

核心威脅

• 未授權訪問、數據泄露
• API濫用導致服務拒絕或成本失控
• 密鑰泄露

控制措施

• 嚴格實施最小權限，利用OAuth 2.0、API網關、白名單等手段限制訪問。
• 建立API允許/拒絕列表，防止惡意調用。
• 優先用API模板，避免讓模型直接生成完整API請求。
• 強化參數校驗、結構化輸出和內容凈化，防止注入和數據污染。

---

2. 代碼執行（KC6.2）

核心威脅

• 任意代碼執行（RCE）、代碼注入
• 資源消耗導致拒絕服務
• 機密信息泄露

控制措施

• 強制沙箱隔離（OS級、容器、虛擬機、WebAssembly）。
• 對Agent生成代碼做靜態分析（Bandit/Semgrep/CodeShield等）。
• 嚴格限制CPU、內存和執行時間。
• 采用簽名校驗、文件/網絡訪問白名單，高風險操作走人工審核（HITL）。
• 全程監控執行過程并凈化輸出。

---

3. 數據庫操作（KC6.3）

核心威脅

• SQL注入
• 未授權訪問/篡改
• RAG數據投毒、敏感信息泄露

控制措施

• 只允許受控數據接入，數據分級標記，RBAC訪問控制。
• 查詢必須參數化或用ORM，嚴禁字符串拼接SQL。
• 數據庫賬戶最小權限，敏感操作強限制。
• RAG內容檢索后還需過濾、內容驗證和速率限制。

---

4. Web使用（KC6.4）

核心威脅

• 惡意網頁內容（XSS、漏洞利用）
• 機密信息泄露、釣魚、SSRF

控制措施

• 瀏覽器組件沙箱化，避免直接操作用戶瀏覽器或擴展。
• URL白名單、目標域信譽檢查、安全網關、TLS驗證和內容凈化。
• 網絡分段、速率和文件類型限制、內容審查，所有訪問需日志記錄。

---

5. PC操作控制（KC6.5）

核心威脅

• 未授權文件訪問、修改
• 任意系統命令執行
• 橫向移動

控制措施

• 僅限受限用戶權限運行，建議容器或虛擬機隔離。
• 明確允許/禁止的系統操作和文件路徑，采用虛擬文件系統接口，所有操作需日志和命令校驗。
• 沙箱不留敏感數據和會話，關鍵操作建議人工審批。

---

6. 關鍵系統操作（KC6.6）

核心威脅

• 災難性物理后果
• 惡意控制注入、虛假數據干擾決策

控制措施

• 最大化物理與邏輯隔離（如空中隔離、物理分段）。
• 強制多因素認證，敏感操作不可由Agent中介。
• 所有關鍵操作必須HITL人工審核，并采用友好提示防誤操作。
• 默認只讀權限，異常檢測、標準合規、物理聯鎖和緊急斷開機制。

---

三、操作能力安全策略一覽

能力類型	主要威脅	關鍵防控措施
API訪問	未授權訪問、濫用、密鑰泄露	最小權限、API網關、參數校驗
代碼執行	RCE、注入、泄露	沙箱隔離、靜態分析、資源限制
數據庫操作	SQL注入、權限越界、數據投毒	參數化查詢、RBAC、敏感操作管控
Web訪問	XSS、SSRF、泄露	沙箱、白名單、日志記錄
PC控制	文件/命令濫用、橫向移動	虛擬化隔離、接口限制、人工審批
關鍵系統操作	災難性后果、惡意控制	物理隔離、多因素認證、HITL人工審核

---

6. Agentic AI與供應鏈

Agentic AI 供應鏈為什么容易成為安全短板？AI代理系統高度依賴外部庫、框架和工具，每一次代碼自動生成、環境部署、工具集成都可能引入潛在風險：

• 第三方依賴被污染，惡意代碼滲透模型推理或自動化流程；
• 開發/生產環境不一致，變更難以追蹤，權限混亂導致敏感數據泄露；
• 工具或代理任意接入，沒有認證和權限校驗，供應鏈攻擊一擊即中。

供應鏈安全三大防護清單

1. 代碼安全（Code Security）

• 對所有第三方庫和框架，強制使用 SCA（依賴漏洞掃描）和 SBOM（軟件物料清單），實時追蹤、校驗版本和來源。
• 自動生成代碼（LLM/Agent）必須在沙箱環境運行，依賴包層層校驗，嚴防惡意注入和合規性違規。
• 高風險操作引入人工審核（HITL），配合靜態分析和許可證合規檢查，形成“多道門檻”。

2. 開發與環境安全（Environments & Development）

• 開發和生產環境保持一致性，所有核心組件（模型等）都要用哈希校驗和可信注冊表驗證來源。
• 所有代碼、Prompt、指令內容實行版本控制和變更記錄，確保每次改動都可溯源和審計。
• 權限管理嚴格隔離，禁止 AI 代理訪問自身開發、構建或部署的源倉庫和敏感數據。
• 權限和 IAM 策略的變更必須審查并記錄，防止“暗中提權”成為安全漏洞。

3. Agent 與工具接入管理（Agent & Tool Discovery）

• 所有外部代理、工具和服務的接入，都需經 Agent Card 和描述文檔明確信任邊界。
• 推薦采用 DID（去中心化身份）等機制，加強代理認證與身份管理。
• 本地/遠程 Agent 注冊表實現邏輯或網絡隔離，防止越權訪問。
• 私有 Agent 和數據與公有組件分離管理，拒絕數據和操作“擴散失控”。
• 新工具和集成前務必安全評估與權限限制，預防供應鏈攻擊風險。

Agentic AI 供應鏈安全 vs. 傳統應用安全

環節	傳統應用安全	Agentic AI 供應鏈安全升級版
依賴管理	定期升級、漏洞修復	SCA+SBOM全鏈路追溯、沙箱執行、HITL審核
環境一致性	手動配置、環境分離	哈希校驗、版本記錄、權限隔離、可追溯審計
工具/代理管理	入口控制、認證	信任邊界定義、DID認證、邏輯/網絡隔離

相比傳統應用，Agentic AI 供應鏈的管理對象更多、接口更開放，防護措施必須“加碼升級”。

---

7. 確保代理應用程序

為什么 AI 代理安全需要紅隊演練和行為測試“雙保險”？傳統安全測試往往只關注代碼和接口。Agentic AI 系統由于具備復雜推理、自主決策和工具調用能力，攻擊路徑極其多樣：

• 惡意提示注入能讓模型“自我背叛”；
• 工具調用被濫用，權限瞬間提升；
• 內存或知識庫投毒，系統長期埋下后門；
• 計劃操控讓代理執行非預期、甚至有害任務。

僅靠靜態掃描或權限加固，遠遠不夠。必須主動模擬攻擊（紅隊演練），并持續驗證行為（行為測試），才能實現閉環安全。

紅隊演練 + 行為測試的實操流程

1. 紅隊演練（Red Teaming Agentic Applications）

核心目標

• 主動模擬真實攻擊，發現并解決系統安全漏洞，覆蓋單體應用到整個組織基礎設施。

主要攻擊路徑

• 提示注入（Prompt Injection）：誘導代理執行未授權操作或泄密。
• 工具調用提權：濫用工具能力，獲得更高權限。
• 內存投毒（Memory Poisoning）：向知識庫注入惡意信息，伺機觸發。
• 計劃操控（Plan Manipulation）：影響代理決策，實現有害行為。

主流紅隊工具與評測框架

• AgentDojo：動態評測提示注入攻擊與防御。
• Agentic Radar：安全與操作洞察分析。
• Agent-SafetyBench、AgentFence、Agent Security Bench (ASB)：覆蓋多種攻擊場景，包含直接/間接注入、計劃與內存投毒。
• MAPS：多語言安全評測。
• AgentPoison：專注于知識庫/記憶投毒。

2. 行為測試（Behavioral Testing for Agentic Applications）

核心目標

• 驗證代理應用在多樣化輸入與場景下能否持續輸出一致且安全的行為，發現意外邏輯或有害目標。

測試方法

1. 明確代理目標和預期行為。
2. 選用標準基準和任務套件，保障評測一致性。
3. 在受控環境下執行測試，分析不同場景下表現。
4. 結合人工與自動化評估，綜合判定輸出結果質量與安全性。

典型基準與套件

• AgentBench：涵蓋操作系統、數據庫、知識圖譜等任務解決能力評測。
• HELM（斯坦福）：多維度評估模型準確性、魯棒性、偏見和有害性。
• WebArena & The Agent Company：測試代理在真實網絡環境中的導航、檢索、適應能力。

結構化評測工具與流程

• Inspect_evals（UK AI Safety Institute）：任意基準下的生成式模型評估。
• GenAI evaluation service（Google）：對模型或應用進行標準化評測。
• Bedrock Evaluations（Amazon）：聚焦LLM與RAG場景的評測。

基準選擇建議

• 明確安全目標（如保密性、魯棒性、隱私保護等）。
• 評估當前威脅態勢，選取涵蓋所需威脅的基準。
• 實際測試關注誤報、有效性與抗攻擊能力。
• 橫向比較，選定最適合自身需求的基準，并集成到CI/CD實現持續評估。

持續改進

• 定期對基準進行元評估，關注一致性、歧義性和準確性。
• 依靠生命周期管理、社區審核與治理，保證基準的時效性和適用性。

紅隊演練 vs. 行為測試

評測方式	關注點	工具/框架	典型收獲
紅隊演練	主動攻擊、漏洞發現	AgentDojo、AgentFence等	揭露真實攻擊路徑與系統脆弱點
行為測試	真實交互、持續表現	AgentBench、HELM等	驗證輸出一致性與安全性

紅隊演練揭露系統“最薄弱的那一環”，行為測試則保證全流程“穩得住”。兩者結合，才能讓 Agentic AI 安全不留死角。

---

8. 安全代理部署

為什么 Agentic AI 上線不能只看模型？生產環境中的 LLM 代理，面對的是真實用戶、敏感數據和復雜業務流程。僅靠模型能力，根本無法應對：

• 流氓代理或有漏洞的工具上線，可能導致權限濫用和數據泄露；
• 多代理協作，稍有疏忽就變成橫向攻擊的溫床；
• 高風險場景下，缺乏人工監管，自動決策可能招致災難性后果。

部署環節每一個小疏漏，都可能成為安全事故的“導火索”。

五大安全代理部署實踐

1. 安全管道與流氓代理檢查

• 強化 CI/CD 流程，集成依賴自動化漏洞掃描、代理工具靜態分析、動態提示注入測試。
• 對高風險任務代理進行人工安全審查（HITL），上線前必須代碼簽名和版本溯源。
• 目的：只允許經過驗證的代理邏輯部署，拒絕惡意或有漏洞代理上線。

2. 角色容器化與函數即服務（FaaS）

• 每個代理或角色都運行在強隔離環境（如 Docker+K8s、AWS Lambda、Google Cloud Functions）。
• 基礎設施層面強制最小權限原則，資源限制、網絡分段、臨時執行環境讓受損代理難以橫向擴散。
• 目的：縱深隔離，降低單點風險。

3. API訪問控制、限流與API網關

• 所有工具調用都必須走 API/Agent Gateway，強制身份認證與授權。
• 細粒度限流防止 DoS 攻擊，控制 API 成本，所有交互日志可審計。
• 目的：權限和訪問控制一體化，防止濫用與失控。

4. 異常行為告警

• 持續監控代理行為，建立“正常”行為基線。
• 發現工具使用異常、任務邏輯突變、數據訪問異常時，第一時間自動告警，便于快速調查響應。
• 目的：動態防御，實時止損。

5. 高風險場景下的人類監管

• 關鍵決策、高權限操作、行為偏離時，強制人工審批（Human-in-the-Loop）。
• 涉及高權限工具、不可信數據、金融醫療基礎設施等領域，持續人工監督（Human-Over-The-Loop），動態調整信任和監管級別。
• 目的：把控不可預測風險，防止自動化決策“失控”。

Agentic AI 部署安全 vs. 傳統應用上線

環節	傳統應用安全部署	Agentic AI 安全部署升級版
流程檢查	代碼掃描+測試	依賴漏洞+工具分析+流氓代理審查
隔離機制	簡單虛擬化/容器隔離	角色容器化+FaaS+資源分段
訪問控制	API限流/認證	API網關+強認證+細粒度限流
行為監控	基本日志/異常告警	行為基線+自動告警+實時審計
高風險監管	少量人工審批	HITL+HOTL+自適應信任機制

---

9. 代理運行時安全

為什么運行時安全是 Agentic AI 的最后防線？訓練、部署都做得再細致，運行時的風險才是“真刀真槍”的考驗：

• 身份管理失誤，代理被濫用或偽造；
• VM 未加固，主機環境被橫向滲透；
• 隔離不到位，工具調用可串門，敏感數據裸奔；
• 日志不全，事后無法溯源、取證；
• 云環境特有漏洞，元數據泄露、IAM角色濫用。

運行時，任何一個環節松懈都可能“前功盡棄”。

代理運行時的六大防護閉環

1. 代理身份與主機環境安全

• 每個代理實例都要有獨立、可管理身份（服務賬號、工作負載身份），安全發放、憑證定期輪換、歸屬和注銷全流程跟進。
• 主機VM基線加固：用最小化鏡像（distroless/Alpine/microVM）、Secure Boot、TPM加密磁盤，禁用無關服務，防火墻默認拒絕，補丁自動化。
• 網絡隔離：代理VM置于私有子網/VPC，服務網格/API網關管控通信，嚴禁直連互聯網。

2. 代理運行時隔離與能力控制

• 每個代理進程獨立沙箱運行（gVisor/Firecracker/Docker-in-VM），結合 AppArmor/SELinux/seccomp 控制系統調用。
• 文件系統只讀、掛載命名空間、內存敏感區用 tmpfs。
• 只允許聲明的工具訪問，會話能力令牌（capability_tokens）限定權限，JSON-RPC包裝強化邊界。

3. 代理內存、工具與上下文安全

• 內存狀態加密、會話結束自動清空（如 Redis/向量庫）。
• VM鉤子或 systemd 停止時強制刷新內存、輪換密鑰。
• 工具調用運行時防護，輸入輸出校驗，掃描提示注入或惡意重定向。
• 動態策略引擎（如 AGNTCY）按場景管控工具訪問。

4. 可觀測性與取證

• 全流程審計：記錄代理行為（工具調用、消息、內存寫入），時間戳+agentID+sessionID+payload哈希+輸入輸出簽名。
• 日志安全存儲，前向完整性（如追加寫、Merkle證明/簽名日志）。
• 行為異常檢測：Open Policy Agent 或 LLM 檢測器，發現異常模式、跨代理通信偏差、異常內存訪問等。

5. 身份、認證與授權

• 會話級認證（JWT、mTLS、HMAC），每代理分配唯一臨時會話上下文（MCP）。
• RBAC+能力令牌，精細化授權：研究代理只能查文檔，運維代理才能發命令。

6. 云環境特定加固（可選）

• 限制元數據服務（AWS IMDSv2），VM用最小權限IAM角色。
• 啟用機密計算（如 AMD SEV、Intel SGX）支持時優先開啟。

Agentic 運行時安全 vs. 傳統應用隔離

環節	傳統應用安全	Agentic AI 運行時安全升級版
身份管理	用戶賬號、服務賬號	代理實例唯一身份、輪換注銷
主機加固	基本鏡像、安全補丁	最小化鏡像、TPM加密、服務禁用
隔離與能力控制	容器/進程隔離	沙箱+系統調用限制+能力令牌
內存與工具安全	參數校驗、有限日志	內存加密、自動清空、策略引擎管控
取證與監控	基本日志、異常告警	全流程審計、簽名日志、異常檢測
云加固	IAM角色、網絡隔離	元數據服務限制、機密計算