当前位置：首页 > news >正文

[OWASP]智能体应用安全保障指南

news 2025/8/20 14:50:08

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）

核心目标

验证代理应用在多样化输入与场景下能否持续输出一致且安全的行为，发现意外逻辑或有害目标。

测试方法

明确代理目标和预期行为。
选用标准基准和任务套件，保障评测一致性。
在受控环境下执行测试，分析不同场景下表现。
结合人工与自动化评估，综合判定输出结果质量与安全性。

典型基准与套件

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角色、网络隔离	元数据服务限制、机密计算