OWASP GenAI 红队手册将测试范围扩展至模型之外
OWASP 于 10 月 20 日发布 GenAI 红队手册，提出八个测试阶段，将评估范围从模型响应延伸至相连的应用与智能体。1.0 版发布内容涵盖了由生成内容、数据访问和操作共同构成的系统在安全性、安全保障及抗故障能力方面的问题。其核心含义很直接：仅评估模型，无法回答围绕该模型构建的产品存在的诸多问题。
OWASP GenAI 红队手册对一种常见的保障捷径提出了挑战：将模型的安全测试结果视为整个部署环境的证据。红队测试是指经授权、以攻击者视角开展的测试，用于发现故障。对于互联 AI 产品而言，关键故障可能不是产生令人反感的回答，而是执行未经授权的操作。
OWASP 此前已于 2025 年 1 月发布相关指南，因此此次发布并非从零开始引入 AI 红队测试。10 月的手册提供了更详细的操作参考。对开发者和企业采购方而言，其价值在于将已发现的弱点与可复现的证据、业务后果和已验证的修复措施联系起来。这也带来了严苛的权衡：更广泛的测试能提供更有价值的保障，但需要聊天机器人演示无法提供的访问权限、协作与工程时间。
OWASP GenAI 红队手册新增了什么
该版本为团队提供了统一的项目执行框架，而非又一组孤立的对抗性提示词。
OWASP 描述的流程涵盖规划、侦察、攻击面映射、利用、持久化、影响评估、报告和修复。其声明的范围包括模型、应用、智能体和多模态界面，即接收或生成文本、图像和音频等格式的系统。资源页面还强调了合乎伦理的测试、可衡量的结果，以及与防御运营的整合。
这种广度很重要，因为 AI 故障很少会附带清晰的组织归属标签。有害响应可能源于模型行为、应用指令、检索材料或连接服务。不同团队掌控这些组件。统一流程让他们能够调查同一事件，而不必假定责任止于各自组件的边界。
历史上的区分同样重要。OWASP 的早期红队测试指南已主张，同时评估模型漏洞、集成弱点和持续监控。因此，10 月的发布代表了这一方法的持续发展。若称其为 OWASP 首次承认应用风险，则有失准确。
新版本还改变了读者对“已测试”一词应有的理解。一家机构可以如实表示其测试了模型，却未触及文档连接器。另一家机构可能测试了应用界面，却排除了执行操作的服务。这些说法描述的是不同的覆盖范围，即便两者都置于同一安全标题之下。
通用的项目执行框架有助于让这些差异变得可见。它鼓励采购方审视测试覆盖了什么、测试人员获得了什么访问权限，以及哪些内容仍在范围之外。其分析价值来自更高的具体性。一个熟悉的框架名称不能替代这些答案。
以一个示例性的企业助手为例：它读取项目文件并起草客户沟通内容。评估其写作质量，几乎无法说明它是否遵守文件权限。评估文件访问，也几乎无法说明后续通信是否会向未经授权的收件人暴露材料。该产品结合了这些行为，因此评估需要说明它们之间的关系。
手册的发布并不能证明组织已经遵循这种方法。它提供了一个可用于审视其声明的参考标准。采用情况、实施质量和安全结果仍是不同的问题。
这一差异有助于正确看待此次发布。OWASP 已发布支持更严谨测试的指导意见。它是否能改善已部署的产品，取决于团队如何将这些指导转化为有关访问权限、发布就绪度和修复措施的决策。
企业采购方承担集成风险
将 AI 模型连接至业务系统的组织，仍须对该连接所涉及的权限和后果负责。
模型提供商和应用开发者回答的是不同的安全问题。提供商在其可用的测试环境中评估行为。开发者决定围绕模型配置哪些文档、身份、服务和操作。企业部署则通过配置、账户权限和组织特有数据增加了另一层因素。
这带来了实际的采购问题。采购方可能获得详尽的模型文档，却对员工将实际使用的具体工作流知之甚少。对生成响应的积极评估，并不能证明助手是否能隔离客户账户，或限制连接器的权限。这些属性取决于已部署的应用。
OWASP 单独发布的应用安全测试指南进一步强化了这一区分。该指南将模型、检索、工具和权限视为一个组合测试面。它还将提示词注入——嵌入输入内容中的恶意指令——视为当智能体可以使用连接工具时可能产生的授权问题。
因此，压力落在多个群体身上。产品团队需要足够精确地描述允许的行为，才能进行测试。安全团队需要获得已部署配置的访问权限。采购团队需要取得说明排除项的报告。业务负责人则需要决定，哪些剩余风险足以证明应当暂缓或限制某项能力。
一个示例性的客户支持助手可以清楚说明这种分工。其模型可能会在直接对话中正确拒绝提供私人信息的请求。但周边应用仍可能检索到错误客户的记录。模型的拒答行为与应用的账户隔离，需要不同的证据。
内部知识系统中也会出现同样的问题。助手可能准确总结一份文档，却将该摘要提供给无权访问原文的人。准确性提升了实用性，却无法解决授权问题。一份精致的回答可能掩盖底层的访问错误。
对于构建可搜索知识库的团队而言，相关问题不仅在于找到正确的信息，还在于保留个人可以检索和再利用这些信息的条件。引入 AI 改变了这些边界运作所依赖的界面。
这一分析并不意味着每一种部署都需要相同深度的测试。仅限访问公开信息的工具，与获授权修改业务记录的智能体相比，后果并不相同。决策应遵循应用实际拥有的权限和暴露程度。
其商业含义比泛泛呼吁加强安全更为具体。供应商面临记录其集成边界的压力。采购方则面临在授予更广泛访问权限前要求提供该文档的压力。双方都无法仅凭模型基准测试解决这一问题。
连接型智能体将响应转化为后果
智能体的安全性取决于其周边软件允许生成的决策执行什么操作。
AI 智能体是利用模型输出，通过连接工具选择并执行操作的软件。这带来了关键转变：原本只会停留在建议层面的文本，可能变成发送信息、修改记录或调用其他服务的请求。
这份144 页手册将模型探测与检索、身份、授权和工具联系起来。其内容还涉及持久化，即攻击者的影响在即时互动结束后仍然存在。这些主题将评估从单个输出扩展至互联系统随时间展现的行为。
以下示例仅用于说明，并非已报道的事件。设想一名研究助手正在审阅一份外部提供的文档。该文档包含要求助手披露无关内部材料的指令。阅读该文档是正当的；但将其指令视为访问和传输其他信息的授权，则跨越了另一道边界。
这种差异说明，为何仅筛查响应无法提供完整图景。即便助手此前尝试了未经授权的操作，最终回答看起来也可能无害。反过来，一项生成请求可能看似危险，而连接服务却已正确拦截它。观察操作及其结果，会改变评估结论。
这在尝试行为与已完成伤害之间形成了有用的区分。评估者不应将每一句可疑表述都视为成功入侵。同样，干净的最终响应也不应抹去连接服务执行了不当请求的证据。产品的实际行为决定后果。
持久化带来了另一项复杂因素。假设示例助手存储了受攻击者影响的偏好设置，并在后续任务中使用它。看似已经解决的一次对话，可能留下会改变未来行为的状态。若只评估最初的交流，就会遗漏这种持续影响。
更广泛的系统也改变了成功防御的含义。如果模型遵循恶意指令，但权限检查阻止了访问，应用便已遏制了这次尝试操作。该结果仍值得调查，但不同于实际的信息披露。报告应保留这一区分。
随着产品获得更有用的能力，这种权衡会更加鲜明。只读访问支持范围更窄的任务。修改记录的权限能够实现更广泛的自动化，同时提高错误指令可能造成的后果。测试需要反映使产品具备价值的能力。
这并不能证明智能体天生不适合商业用途。它说明了为何权限本身需要独立的证据。相关比较在于：智能体能够尝试什么、周边服务允许什么，以及用户原本意图是什么。
OWASP GenAI 红队手册明确提出了这一综合视角。其实际意义在于，让应用行为获得与模型响应同等程度的审视。
统一方法面临证据问题
结构化评估能提升问题的质量，但其结论仍受限于背后的测试、环境和证据。
贡献者的支持有助于解释为什么一种通用方法论会受到从业者青睐。NeuralTrust 在其日期为 2026 年 7 月 1 日的贡献者文章中，介绍了其参与公开征求意见版的经历。该公司认为，相较于彼此割裂的攻击技术，可重复开展的测试活动是一种改进。这代表参与者的观点，而不是事故减少的独立证据。
时间线同样需要谨慎看待。NeuralTrust 在 OWASP 于 10 月发布资源页面之前，就讨论了公开征求意见版手册。读者应区分早期草案活动与当前官方版本所标注的日期。两者都无法证明某个特定组织是在何时采用该方法论的。
值得质疑的问题在于实施质量。一份报告可以使用一致的标题结构，却记录了薄弱的实验；一份篇幅很长的评估也可能遗漏最关键的工具；测试环境在视觉上可能类似生产环境，却采用不同的权限。正式的结构能让这些限制更容易被描述，但不会自动消除它们。
衡量同样面临挑战。测试结果取决于如何界定成功或失败。助手提及机密信息，与检索、展示或向外部传输该信息并不相同。将这些事件都归入模糊的“泄露”标签，会使结果难以解读。
产品之间的比较也面临同样问题。权限范围广泛的系统，可能比受严格限制的助手暴露出后果更严重的失败路径。成功攻击的原始数量无法说明这些产品是否面对可比的任务、访问权限或条件。结果必须与测试范围一并呈现。
自动化测试带来了另一层不确定性。用于判断另一个模型行为的模型，可能误解任务或错误分类结果。这并不意味着自动化评估没有价值，而是意味着评判过程本身需要接受审查，尤其是在结果会影响发布决策时。
安全性与实用性的区别在这里也很重要。拒绝所有请求的助手看似能够抵抗滥用，却无法完成其预期工作。一项有意义的评估需要同时保留合法任务的执行能力，以及系统应当实施的边界。否则，表面上的改进可能掩盖了功能损失。
这些是分析上的限制，而非证明该手册失效的证据。没有任何方法论能够把一次范围有限的演练转化为对所有未来交互的证明。站得住脚的结论应明确说明已测试的条件、观察到的结果以及剩余的不确定性。
因此，这项发布应提高人们对证据的期待，但不应鼓励一概而论的保证。“依据 OWASP 指引完成评估”描述的是一种方法。买家仍需要了解评估期间实际发生了什么，以及哪些发现已得到经验证的修复。
测试预算必须覆盖完整工作流
更广泛 AI 测试中最具挑战的部分，是协调控制工作流的人员与系统。
以提示词为中心的演练通常只需访问对话界面即可开始。工作流评估则需要更多背景信息。测试人员需要了解应用的预期任务、可访问的信息，以及其工具可能产生的影响。在攻击开始前，获取这些理解本身就会消耗组织资源。
这种成本是安全权衡的一部分。更广的范围有助于得出更贴近已部署产品的结论。更窄的范围能减少所需工作量，但也限制最终报告能够证明的内容。无论哪种选择，都不应隐藏在“测试已完成”这种笼统表述之后。
这种差异也会影响修复方式。如果弱点源于权限过宽的服务账户，修改模型指令可能仍会保留根本权限问题。如果问题涉及以非预期方式使用的合法访问权限，移除所有访问权限又可能破坏产品本身的职责。工程团队需要足够具体的诊断，才能支持有效的修复。
责任归属可能成为核心障碍。模型团队控制配置，应用团队控制编排，身份团队控制权限，而业务部门拥有受影响的工作流。一项跨越这些边界的发现，需要明确由谁修改什么。
一个示例性的文档助手可以说明这一过程。该产品会检索内部文件并生成对外摘要。测试发现，受限制的内容进入了草稿。纠正措施可能涉及检索权限、收件人检查、文档分类或工作流审批环节。这些补救措施针对的是不同的成因。
有价值的结果应说明哪个边界失效，以及所选补救措施是否阻断了已观察到的路径。除非底层失败本身与指令处理有关，否则仅在助手指令中加入更强硬的措辞，只能提供较弱的证据。修复应遵循已验证的机制。
现有工具分别支持这项工作的不同环节。OWASP 的应用测试指南列出了用于模型漏洞扫描的 NVIDIA garak，以及用于编排对抗性交互的 Microsoft PyRIT。这些工具支持测试活动，而测试活动方法论负责组织范围、解读与后续行动。它们的作用有所重叠，但不能互相替代。
因此，工具比较应关注覆盖范围，而非品牌偏好。能够生成多样化输入的扫描器，无法自动确定某条业务记录是否被恰当地更改。若没有明确的任务和政策，编排框架也无法替组织决定可接受的权限边界。
该手册强调可复现性和防御性集成，其目标指向一种可操作的结果：工程与安全团队能够使用的发现。业务价值取决于这种交接。当无人能够复现异常响应的后果，或验证修复效果时，发现一次异常响应的价值就会降低。
持续关注至明年 1 月的采用证据
最有力的信号将是公开证据表明，组织在使用该手册后改变了评估范围并验证了修复效果。
第一个值得关注的信号是已发布案例研究的质量。到 2027 年 1 月为止，有价值的案例应说明被测试的应用、其连接的能力，以及被排除在评估之外的边界。背书或下载公告只能表明兴趣；有记录的测试活动才能揭示该方法论如何在真实约束下运行。
如果这些案例将发现的弱点与具体纠正措施联系起来，将增强该手册的说服力。若它们只报告异常的模型响应，却不探究应用层面的后果，则会削弱更广泛的主张。这一区别符合该发布所声明的范围。
下一个信号是供应商如何在其评估服务中描述覆盖范围。OWASP 的红队计划已将该手册与评估和供应商选择资源一同呈现。这为审视服务内容提供了参照点。买家应关注工具、数据访问和智能体行为覆盖范围是否得到更清晰的说明。
更具体的报告将支持这样一种观点：共享指引能够提高可比性。若仅泛称与 OWASP 保持一致，却没有记录测试范围，则只能提供较弱证据。真正有意义的变化会体现在交付成果和合同预期中，而不是供应商页面上的新徽章。
最后一个信号是修复后的情况。公开的后续结果将显示，组织是否重新测试了原始失败情形，并检查了相关路径。若一份说明止步于发现问题，核心运营问题仍未得到回答：产品是否在保留预期功能的同时变得更安全？
这些是观察标准，而非 OWASP 或参与供应商已宣布的承诺。目前尚无经过验证的采用数据或事故减少指标来证明该手册的影响。该发布提供了调查这种影响的框架，而实施证据仍有待后续出现。
对开发者而言，直接含义是将测试结果与客户实际使用的配置关联起来。对企业买家而言，则是区分模型层面的保证与部署层面的证据。对用户而言，实际关切仍然是助手是否尊重围绕其信息和操作设定的边界。
请将 OWASP GenAI 红队测试手册与贵组织实际部署的 AI 系统评估证据一并阅读。要求产品负责人说明测试了哪些工作流，以及哪些权限仍未纳入范围。审查报告是否区分了尝试执行的操作与已完成的效果。检查工程团队是否针对原始失败验证了修复。这些问题能让讨论聚焦于可观察的行为，而非某个框架标签；它们也能揭示一份自信的总结何处建立在狭窄实验之上。在授予助手更广泛访问权限之前，请索取覆盖新增权限的证据。最新评估描述的是员工实际使用的产品，还是仅描述其底层模型？
