AI安全评估：如何划定范围、取得可信证据

设想一个假设的场景。一家公司将在一个月后上线面向客户服务的AI助手。它根据知识库回答问题，能够查看客户的订单历史，还可以直接办理退款。CTO的桌上放着两份商业报价。第一份承诺“五个工作日内完成OWASP LLM Top 10检查”，第二份提供“由研究团队执行的AI红队测试”。两份报价都写得信心十足，满是耳熟能详的术语。

然而，两份报价都没有回答公司真正关心的问题：用户是否可以通过某种特定的提问方式，为别人的订单办理退款？如果可以，故障究竟出在哪里——是模型本身，是调用退款函数的代码，还是应用检查权限的方式？

这个例子是虚构的，但这种两难处境非常普遍。AI安全评估并不是从挑选一个时髦的服务名称开始的，而是从回答三个问题开始：我们要检查的是哪个系统，它的边界在哪里，以及什么样的证据才算充分。

“AI安全评估”这个名字下实际买到的是什么

是系统，而不是模型

安全评估是对一个具体系统进行的技术测试，随后是对结果的分析和修复计划。NIST SP 800-115将评估划分为规划、执行和执行后活动；分析发现、提出缓解建议和形成报告属于最后一个阶段。该文件发布于2008年，远早于各类大语言模型产品出现，而且它自己也不把自己称为完整的测试方案。尽管如此，这个循环可以很好地迁移到AI场景：它让注意力集中在证据和修复上，而不是攻击手法的新奇程度。

关键词是“系统”。攻击者并不是在真空中与“模型”对话。他们面对的是网页界面或API，通过或未通过身份认证，获得会话，然后发送请求。这些请求由编排代码处理，编排代码再去调用模型、文档检索和内部服务。一份只描述模型行为的报告，描述的只是众多组件中的一个。

三种经常被混淆的形式

市场上，名称相近的服务实际上是不同类型的工作。在比较价格和工期之前，有必要先把它们区分清楚。

没有哪种形式在绝对意义上优于其他形式。LLM Top 10清单是很好的术语表，却是糟糕的测试计划。红队测试回答的是某个特定对手能否达成某个特定目标，这与“所有安全控制是否都有效”是两个不同的问题。我们在关于如何以可验证的标准采购AI红队测试的文章中详细讨论了两者的差别。如果任务是在发布前系统地检查产品的边界，通常应先做安全评估，之后再围绕具体场景规划红队测试。

AI产品的四个层次

在划定范围时，把系统分成四个层次会很方便。这个模型并不能涵盖所有情况，但它能帮助我们不遗漏产品的任何部分，也避免把评估缩减为单一组件。

数据与上下文来源

第一层是模型能“看到”的一切：如果模型经过微调，就包括微调数据；还包括用于检索的文档、对话历史，以及被注入上下文的用户信息。这里要问的问题是：谁能向这些来源写入内容？不同客户和不同角色的数据，在进入上下文之前是否已经隔离？一份嵌入了指令的文档，能否影响系统给其他用户的回答？

文档检索层值得单独检查：索引中的访问控制错误，往往比模型的任何特性都更重要。我们在RAG系统安全评估方法中介绍了这类测试的做法。

模型及其配置

第二层是模型本身。它是哪个模型、哪个版本、由哪家供应商提供、采用了哪些参数、系统指令和过滤器？要问的问题包括：面对操纵性的输入，模型会泄露什么；版本更新后行为如何变化；在长对话中、在使用其他语言输入时会发生什么。

需要强调的是，配置本身就是被测对象的一部分。同一个基础产品，换了系统指令或换了过滤器，从结论的角度看就已经是另一个系统。关于如何更深入地处理这一层，请参阅我们的AI模型安全评估指南。

模型周边的应用与API

第三层是人们熟悉的应用部分：身份认证、会话、授权、请求频率限制、错误处理、日志，以及在浏览器中呈现回答。这一层可以用成熟的Web和API测试方法来检查。攻击者成本最低的路径往往就在这里：如果API在标识符被替换后就会返回其他用户的对话，就根本没有必要去欺骗模型。

工具与操作

第四层是模型能够触发的一切：函数、插件、MCP服务器、内部API调用、发送邮件、修改记录。要问的问题是：操作以谁的权限执行？代码在调用之前是否检查了用户的权限，还是依赖“模型不会这么做”的假设？对于不可逆的操作，是否有确认步骤？

在我们的假设例子中，正是这一层决定了退款功能的命运。包含连续调用的智能体场景还会带来额外风险，应当单独规划，详见我们的智能体AI系统渗透测试指南。

如何划定评估范围

从评估需要支撑的决策出发

第一个问题不是“测什么”，而是“评估需要支撑哪项决策”。上线生产环境、为智能体接入新工具、验收供应商的产品、回答大客户提出的安全问题——每一项决策需要的深度都不同。

在把助手接入支付操作之前进行的评估，必须深入检查工具层和授权机制。对内部文档助手的评估，则首先应关注文档访问控制以及经由上下文发生的泄露。如果没有明确决策，范围就会不断蔓延，报告也会变成一份没有优先级的“有趣观察”清单。

信任边界地图

接下来，评估方与团队一起记录四件事：AI组件从哪里获得输入，它能访问什么，它能触发哪些操作，它的输出流向哪里。凡是不可信输入与权限、其他用户的数据或操作相遇的地方，就是一条信任边界。在那里必须有一项具体的安全控制在起作用，而测试要验证的正是这些控制，而不是笼统的“模型”。

1. 决策明确评估要支撑什么：一次发布、智能体的新工具、供应商验收，或对客户问题的答复。
2. 系统地图描述数据、模型、应用和工具，包括版本、供应商和集成关系。
3. 信任边界标出不可信输入与权限、他人数据或操作相遇的位置。
4. 检查方法为每条边界选择方法：标准的应用测试、针对模型的场景，或人工核查权限。
5. 证据标准事先约定什么算已确认的发现，以及如何描述结论的适用范围。

开工前需要书面确定的内容

在任何测试活动开始之前，都需要系统所有者的书面授权，以及列明模型版本和配置的目标清单。随后是测试环境与测试账户、测试时间窗口、联系人和停止条件。数据处理方式也需要单独约定：模型的提示和回答会进入评估方的日志，其中可能包含个人数据或内部文档片段。

如果模型由外部供应商提供，还应核实该供应商的使用条款。产品所有者的授权并不总能覆盖对他人基础设施的测试，这一点最好在发出第一条请求之前弄清楚，而不是事后。

如果您希望和 Pentest.red 团队一起把产品按层次和边界拆解清楚，可以在准备渗透测试范围的阶段完成。这一阶段讨论的是系统、访问权限、限制条件和预期结果，我们不会事先承诺任何发现。

参考标准及其边界

测试循环

本文将SP 800-115的流程框架转化为AI评估项目的实践顺序。规划阶段包括授权、范围、目标、数据处理规则和停止条件。执行阶段采用与约定目标相对应的方法，并清楚每种方法的优势和局限。分析阶段把观察结果转化为带有根本原因和受影响资产的发现。缓解阶段确定优先级、负责人和复测安排。AI特有的测试目标是对这一框架的补充，而不是替代。

应用层

OWASP Web安全测试指南（WSTG）提供了Web和API的测试流程，稳定版本为4.2，5.0版本正在开发中。OWASP ASVS 5.0.0是一套可验证的安全控制要求。该项目明确提出，其目标是让市场上安全验证的覆盖范围和严格程度趋于一致。

ASVS建议在引用要求时注明版本，例如v5.0.0-1.2.5，因为要求编号会在不同版本之间变化。要求清单以CSV和JSON等格式发布，这使得双方可以事先约定范围，并以程序化方式跟踪覆盖情况，而不是只相信口头描述。

AI风险的术语体系

OWASP大语言模型应用Top 10的2025版提供了共同的风险术语体系。它有助于团队讨论AI系统的弱点，但并没有为某个具体产品规定完整的测试方案。关于如何把这类分类与实际检查联系起来，请参阅大语言模型安全审计一文。

MITRE ATLAS是一个以ATT&CK为蓝本、汇集针对AI系统攻击战术和技术的知识库，适合用于威胁建模和场景准备。2023年1月发布的NIST AI RMF 1.0，以及2024年7月发布的生成式AI配置文件NIST AI 600-1，属于风险管理范畴。它们有助于把评估结果纳入组织流程，但并不是测试流程。

任何标准都没有提供的东西

AI产品的评估流程取决于其系统层次、集成方式和威胁模型。供应商熟悉WSTG和ASVS，并不等于其检查能够完整覆盖AI系统。本文没有依据一个公开且经过独立验证、可以直接比较供应商成效的基准。因此，对于“我们独有的AI评估方法”这样的主张，需要核实具体内容：请供应商说明其方法、方法的局限，以及这些方法如何对应您的信任边界。

在工作说明书中还应保持另一项区分：在网络安全工作中使用AI，与评估AI系统本身的安全性，是两项不同的任务。两者都很重要，但不应混写在同一份文件里，因为它们的执行者、标准和成果都不相同。

传统弱点并没有消失

把模型输出视为不可信输入

在AI产品评估中，最常被低估的一个观点是：模型生成的一切，都应被视为来自潜在攻击者的输入。模型可以通过提示、知识库中的文档或外部服务的响应受到影响，因此它的输出并不比任何用户填写的字段更可信。

如果回答会在浏览器中呈现，常见的跨站脚本风险依然存在，内容安全策略（CSP）也再次成为一项重要控制：它有助于发现和缓解跨站脚本和数据注入。如果输出被用来构造SQL查询、文件路径或操作系统命令，注入和路径遍历问题就会卷土重来。ASVS中有一条直接的要求：操作系统调用必须参数化，或使用与上下文相适应的命令行输出编码。CISA在“设计即安全”项目下发布过多份警示，呼吁消除整类缺陷，例如跨站脚本、操作系统命令注入和目录遍历。

关注根本原因，而不是症状

按CWE对发现进行分类，可以把它们与开发实践联系起来。CWE Top 25排名，以及配套的、依据CISA已知被利用漏洞（KEV）目录列出的被积极利用弱点清单，有助于确定修复顺序。如果评估只测试“AI的新行为”而跳过这些类别，那么最常被利用的路径仍然无人检查。

2025版OWASP Top 10仍然是Web风险的共同术语表。但它是一份提高意识的文件，而不是测试计划；一份只引用其类别的报告，说明工作停留在“意识”层面，而不是“验证”层面。

三个会扭曲结论的误区

模型拒绝并不能证明授权有效

模型回答：“我无法执行这个操作。”这只是关于模型在某个具体请求上的行为观察，并不能证明工具受到了保护。如果退款函数接收订单标识符，却不检查该订单是否属于当前用户，那么换一种说法的请求、换一种语言、很长的上下文，或者一份嵌入了指令的文档，都可能导致这次调用发生。

正确的测试是在工具一侧检查授权：如果带有他人标识符的调用直接到达API，会发生什么？如果它以另一个角色的身份经由模型到达，又会怎样？原则很简单：检查权限的是代码，不是模型。

提示过滤器不是访问边界

输入过滤器和可疑请求分类器作为额外的一层防护是有用的，但它们是概率性的：取决于措辞、语言或上下文，过滤器可能放过本应拦截的内容。真正的访问边界，是代码中的权限检查、客户数据的隔离，以及工具运行所用服务账户的最小权限。如果报告把过滤器描述为能够“消除”他人数据访问风险的控制措施，就有理由提出疑问。

系统提示保密不能替代安全控制

OWASP在LLM Top 10（2025版）中把系统提示泄露单列为一个类别，并建议不要在其中存放敏感信息，例如凭据、连接字符串、角色和权限说明。应当假设系统提示的内容是可以被提取的。因此，“我们拿到了系统提示”这一发现本身并不重要，重要的是其中包含了什么，以及哪些安全控制依赖于它的保密性。

什么才算真正的证据

一项已确认的发现是什么样子

在AI产品评估中，一项好的发现会说明被测试的边界或要求，并记录测试条件：模型、版本、配置、账户和数据。它会说明可复现性，即尝试了多少次、结果有多稳定；会展示系统一侧可观察到的效果，而不仅仅是回答的文字；还会列出受影响的资产、根本原因、修复建议以及评估方的置信程度。

“模型说了些奇怪的话”与“通过模型为另一用户的订单调用了退款API，且该调用被记录在日志中”之间的区别，就是观察与证据之间的区别。

结论的适用范围

对AI来说，这一点尤其重要。结论只适用于特定的模型、版本、配置和场景集合。模型具有非确定性：同一个请求可能得到不同的回答。因此，经过若干次尝试后没有发现问题，只是关于这些尝试的观察，并不能证明某件事不可能发生。

供应商更换模型版本、修改系统指令，或者接入一个新工具，都会让部分结论失效。还有一条适用于任何渗透测试的通用规则：评估不是认证证书，也不能证明不存在任何漏洞。它说明的是测试了什么、如何测试，以及得到了什么结果。

值得事先约定的权衡

某一时刻的快照

一次性评估记录的是系统在测试窗口内的状态。如果模型、提示、数据来源和集成每周都在变化，结论很快就会过时。合理的做法是把评估与发布流程联系起来：明确哪些变更需要复测，例如更换模型或模型版本、接入新工具、增加新的数据来源、调整角色。把这些触发条件写进书面制度，而不是停留在口头约定上。

检查表与探索性测试

对照ASVS进行的检查能够提供可比较的覆盖范围。对模型行为的探索性测试能发现任何检查表都没有列出的问题，但更难复现，也更难在不同评估方之间比较。两种方法都需要。报告应当明确区分哪些工作按照标准流程完成，哪些依赖于评估方的判断。

测试不能替代设计

按照CISA“设计即安全”的立场，可被利用的缺陷在设计阶段消除成本更低，产品应当以安全的默认配置交付，包括无需额外付费的多因素认证和日志功能。对于采购方，CISA提供了“按需安全”（Secure by Demand）指南，列出了采购谈判中可以提出的问题；当AI能力是购买而非自研时，这份指南尤其有用。评估能揭示剩余风险，但不能把薄弱的架构变成坚固的架构。

审阅商业报价时要问的问题

让我们回到那个有两份报价的假设场景。CTO不必在两个服务名称之间做选择，而是可以向两家供应商提出同样的问题，再比较他们的回答。

第一个问题关于范围：是否描述了整个系统，包括全部四个层次及其版本，还是只是在“测试模型”？第二个问题关于工具：是否会在执行操作的代码一侧检查授权，还是只观察模型对请求的反应？第三个问题关于应用层：Web和API测试是否对应到WSTG流程和带版本号的ASVS要求？

第四个问题关于证据：发现如何记录，什么算作确认，在模型行为具有非确定性的情况下如何描述可复现性？第五个问题关于范围限制：报告将如何列出未测试的区域，哪些变更会要求对结果进行复测？第六个问题关于数据：供应商在工作中接触到的提示、回答和文档，将如何保存和删除？

能够具体回答这些问题的报价更容易比较，更便于据此修复问题，也更容易在审计人员面前站得住脚。而依赖时髦术语、缺乏可追溯性的报价，无论措辞听起来多么先进，都需要更仔细的审查。

您也可以结合自己的产品，与我们一起逐一梳理这些问题：系统和预期结果的描述从范围准备页面开始，我们的整体工作形式可在渗透测试服务中查看。至于究竟选择安全评估、红队测试还是两者结合，最好在明确了测试需要支撑的决策之后再做决定。