从模型安全到 Agent 安全：一份面向开发者的 AI Agent 安全标准与框架指南

如果你正在把 Agent 往生产环境推，大概率会遇到一个很尴尬的时刻：模型安全评估全过了，Agent 却把退款打给了错误客户，或者打开了一个不该开的防火墙端口。

这不是模型变坏了，而是安全问题的性质变了。

模型只输出文本时，我们关心的是“这句话安不安全”。Agent 能调用工具、写数据库、发请求、动基础设施之后，问题变成“这个动作有没有被授权、有没有边界、能不能回滚”。

我最近把市面上和 Agent 安全相关的标准、框架翻了一遍。下面按标准拆开讲，每个都说清楚：覆盖什么、什么时候出现、适合什么场景、优缺点、以及怎么落地。

为什么传统 AI 安全框架不够用

核心差别就一句话：语言模型产生文本，Agent 产生后果。

举个例子。你让一个 Agent 管理云基础设施。模型可能生成一个看起来很合理的计划，然后调用工具，参数单独看都没问题，但组合起来可能把生产环境搞挂。聊天窗口最后显示“已完成”，但爆炸半径已经在基础设施里扩散了。

问题不在于模型有恶意，而在于模型是概率规划器，它在不确定性下工作。它可能被提示注入操纵，可能幻觉出错误的工具参数，也可能在上下文塞满之后行为漂移。如果它只是写文案，这些都不是大问题。如果它对业务系统有写权限，那就是另一回事了。

所以标准社区的方向很明确：把模型当作不可信组件。授权、参数校验、执行限制、审计追踪，这些要放在模型控制之外的确定性系统里。

OWASP Agentic AI 安全成熟度模型

覆盖范围

这个成熟度模型有两个维度。

• 部署类型：从影子 AI（组织完全不知道）到厂商内嵌助手、平台集成 Agent、公民开发者 Agent、代码执行 Agent，最后到自定义内部 Agent。
• 治理成熟度：从临时意识，到有策略定义的人类在环流程，再到集成的持续监督，包括机器可读策略和 kill switch。

发布时间

2026 年 6 月，OWASP GenAI Security Project 发布论文《State of Agentic AI Security and Governance》。

典型应用场合

• 金融科技公司评估客服 Agent 是否有足够治理能力，因为它能访问支付 API。
• 医疗平台评估临床文档 Agent，因为它会读写患者记录。
• 企业 IT 团队决定哪些内部团队可以部署代码执行 Agent，依据是他们当前的治理成熟度。

优点

• 它承认组织现实。大多数公司就在 Level 0 或 Level 1，模型不假装大家都准备好了。
• 给团队一套描述现状的词汇，也给出下一级大概长什么样。
• 二维映射能避免一个常见错误：对厂商内嵌助手管得很重，却把自定义代码执行 Agent 完全放养。

缺点

• 描述性大于规范性。它告诉你现在在哪，但不会手把手告诉你每一步怎么走。
• 治理成熟度假设了某些组织结构，很多初创公司和中型公司根本没有。对十五个人的工程团队来说，“高管监督”和“首席 AI 官”是愿望，不是日常。

怎么落地

• 先盘点组织里所有 Agent，包括影子部署。
• 把每个 Agent 映射到 AT0 到 AT5 的部署类型。
• 诚实评估每个 Agent 当前的治理级别。
• 找出错配。比如代码执行 Agent 却处在治理 Level 0，这就是优先级最高的风险。
• 按风险从高到低处理错配。

OWASP Agent 控制标准（ACS）

覆盖范围

ACS 定义 Agent 平台如何暴露 middleware hooks，以及安全策略如何通过这些 hooks 执行。它提供声明式控制，可以跨 Agent 框架移植，并在运行时强制执行。它还引入 Agent Bill of Materials，用来检查、追踪和仪表化生产环境中的自主 Agent。

发布时间

2026 年 9 月在 OWASP 旗下首次亮相，最初由 Zenity 开发并捐赠给 OWASP GenAI Security Project。

典型应用场合

• 平台团队构建内部 Agent 框架，希望支持策略执行，又不想让每个产品团队自己实现安全层。
• 安全团队需要审计 Agent 能访问哪些工具，以及运行时传了什么参数。
• 企业需要证明合规，展示每个 Agent 动作在执行前都经过了策略检查。

优点

• 目前最接近厂商中立的运行时执行规范。
• middleware hook 方式意味着不会被单一 Agent 框架锁死。
• Agent Bill of Materials 给安全团队一个具体可检查的对象。
• 运行时执行能抓住静态分析漏掉的策略违规。

缺点

• 标准还很年轻，生态采用是关键变量。主流 Agent 框架不实现 hooks，标准就停留在纸面。
• 每个 Agent 动作都加策略检查会带来延迟，实时应用要权衡。
• 团队需要决定哪些动作必须检查，哪些可以放行。

怎么落地

• 先看你用的 Agent 框架是否支持 ACS。
• 如果支持，启用 hooks，先跑宽松策略，只记录违规不阻断。
• 审查一周日志。
• 然后收紧策略，阻断你实际观察到的违规。
• Agent Bill of Materials 应该在部署时自动生成，并和其他构建产物一起保存。

NIST AI Agent 标准倡议

覆盖范围

这个倡议分三个支柱：行业主导的标准开发、Agent 身份和授权的互操作框架、自主系统的安全控制。它建立在 NIST AI Risk Management Framework 之上，特别是把 Govern、Map、Measure、Manage 四个功能扩展到 Agentic 威胁。

2025 年 12 月发布的 NIST IR 8596 初稿，把网络安全框架功能直接映射到 AI 系统治理，包括 Agentic 风险。2025 年 3 月更新的 NIST AI 100-2 首次明确把 AI Agent 列为威胁面。

发布时间

CAISI 于 2026 年 2 月 17 日启动该倡议。

典型应用场合

• 联邦承包商需要让 Agent 部署对齐美国政府正在形成的自主系统标准。
• 企业安全架构师需要把现有 NIST 控制映射到 Agent 特定风险，用于审计。
• 大型科技公司的标准团队想影响 Agent 身份和授权标准的方向。

优点

• NIST 有机构重量，行业联盟比不了。
• 它明确处理了一个缺口：基础 AI RMF 从来不是为 Agentic 架构设计的。
• 对 Agent 身份的要求很基础但很关键：Agent 必须有唯一持久身份，不能和开发者、用户或服务账号混用。很多部署目前缺这个。
• NCCoE 关于软件和 AI Agent 身份与授权的概念论文提供了具体实施指导。

缺点

• 这是政府倡议，时间线以季度和年计，不是以 sprint 计。
• 三支柱结构很宏大，实际标准文档还在开发中。
• 对下个月就要发 Agent 的团队，它提供方向，但不提供立即操作指南。

怎么落地

• 从身份要求开始。给每个 Agent 独立身份，不要复用服务账号。
• 然后把 Agent 部署映射到四个 RMF 功能。
• Govern：每个 Agent 都要有人拥有。
• Map：理解它的工具访问和数据范围。
• Measure：有运行时证据证明它实际做了什么。
• Manage：需要时能干预、暂停或撤销访问。

ISO/IEC 42001 在 Agentic AI 上的应用

覆盖范围

ISO/IEC 42001 是 AI 管理体系标准，结构类似 ISO 27001，但范围是 AI 风险。它适用于使用 AI 的组织，不只是构建 AI 的组织。第 4 到第 10 条给出管理体系要求。

对 Agentic 系统来说，证据模型要从文档化、周期性，转向运行时生成、机器可读、事件驱动。

发布时间

2023 年 12 月发布。针对 Agentic AI 系统的操作解读在 2026 年 5 月发布。

典型应用场合

• 公司要拿 ISO 42001 认证，同时又部署面向客户的 Agent，需要证明管理体系覆盖 Agentic 风险。
• 内部审计团队需要验证 Agent 部署有正确的生命周期控制，包括上线、周期审查、下线。
• 采购团队要求供应商提供 ISO 42001 认证，而供应商产品包含自主 Agent 能力。

优点

• 给组织一个可认证、可审计的 AI 治理结构。
• 国际认可，和现有信息安全管理体系映射得不错。
• 生命周期方法，包括正式上线、周期审查、下线，能解决很多部署里“Agent 建完就被遗忘”的问题。

缺点

• ISO 42001 没有专门针对 Agentic AI。NIST AI RMF 的缺口分析在这里同样适用。
• 组织如果要用 ISO 42001 覆盖 Agentic 系统，需要补充 Agent 特定控制，比如工具授权、运行时权限边界、多 Agent 委托链。
• 认证过程资源密集，小组织很难承受。

怎么落地

• 如果已有 ISO 27001，结构会很熟。
• 如果没有，先文档化 AI 管理体系范围。
• 每个 Agent 定义人类 owner。
• 建立周期审查。
• 生成运行时证据，不要只靠设计文档。
• 关于 Agentic 系统的操作解读论文提供了逐条映射，可以当实施清单。

WDTA AI Agent 运行安全测试标准

覆盖范围

这是首个全球基准，用来验证 AI Agent 行为的安全性和可靠性。它提供两层测试框架：Agent 系统安全测试和生命周期安全测试。

系统层评估架构，包括接口、模型、工具、记忆和 RAG 系统。生命周期层覆盖从开发到部署维护的每个阶段。它专门处理“行为”风险，也就是 Agent 跨过语言墙，从文本生成走向现实行动时产生的风险。

发布时间

2025 年 7 月在联合国日内瓦总部发布，由 World Digital Technology Academy 推出，Ant Group、清华大学、中国电信等二十多家机构参与。

典型应用场合

• 自动驾驶公司需要测试 Agent 在感知、决策、行动层的行为。
• 医疗机构验证诊断 Agent 从开发到部署的整个生命周期是否安全。
• 制造企业测试控制物理设备的 Agent，需要验证对抗条件下安全联锁仍然有效。

优点

• 操作导向明确，测行为，不只测文档。
• 两层方法覆盖架构和生命周期。
• 多国多机构参与，比单一厂商标准更有可信度。
• 专注高风险行业，Agent 失败有物理后果的场景。

缺点

• 标准还在早期采用阶段。
• 按它测试需要大量测试基础设施投入。
• 生命周期测试概念上合理，但对持续部署团队很难，因为开发、部署、维护的边界本来就模糊。

怎么落地

• 先从 Agent 系统安全测试层开始。
• 构建测试用例，覆盖接口、工具调用、记忆系统在对抗输入下的表现。
• 再扩展到生命周期测试。
• 持续部署团队可以把生命周期测试当作 CI/CD 门禁。
• 每次 Agent 变更触发一部分生命周期测试，通过后再部署。

CSA MAESTRO 威胁建模框架

覆盖范围

MAESTRO 是专为 Agentic AI 系统设计的七层威胁建模框架。七层包括：基础模型、数据操作、Agent 框架、部署基础设施、评估和可观测性、安全与合规、生态集成。每层都有具体威胁类别和缓解策略。

发布时间

Cloud Security Alliance 于 2025 年 2 月推出。2026 年跟进了应用指南和九支柱 secure-by-construction 设计框架。

典型应用场合

• 安全工程团队为多 Agent 编排平台做威胁建模。
• 金融服务公司在采购前评估供应商 Agent 的安全态势。
• DevSecOps 团队把威胁建模集成到 Agent 开发的 CI/CD 流程。

优点

• 填补了 STRIDE 等传统威胁建模框架没为 Agentic 架构设计的空白。
• 捕获 Agentic 架构特有的攻击面，包括跨工具边界的提示注入、记忆污染、委托链操纵。
• 七层结构提供系统化方法，避免漏掉攻击面。

缺点

• 七层很多，小团队压力大。
• 没有专门安全工程资源的组织会觉得框架太重。
• 各层抽象程度不一，有些层还在随 Agent 生态成熟而演进。

怎么落地

• 不要一次威胁建模七层。
• 从和你的部署最相关的层开始。
• 如果构建在基础模型 API 上，基础模型层是供应商责任。
• 重点放在 Agent 框架层、工具集成层、部署基础设施层。
• 每层做结构化威胁建模 session。
• 记录识别出的威胁和已有控制。
• 每季度重复一次，或者 Agent 工具访问变更时重复。

开发者现在能做什么

Agent 安全标准正在快速成熟。两年前几乎没有。现在 OWASP、NIST、ISO、WDTA、CSA 都有重叠但互补的框架，还有越来越多运行时 SDK 和策略引擎来实现这些控制。

对今天就要发 Agent 的团队，实用建议是：

• 选一个治理框架，再选一个运行时执行机制。
• 用框架组织思考，用运行时机制真正执行控制。
• 不要一次全上。
• 这周最有价值的一件事：给每个 Agent 独立身份，并定义工具访问边界。
• 这一个改动就能消除最常见的一类 Agent 安全事故：Agent 做了它本来根本不该有能力做的事。

先把身份和权限边界做对，再谈更复杂的策略、审计和威胁建模。顺序对了，后面会轻松很多。