生成式AI安全评估：测什么、怎么测、如何选服务商

下面的场景是为本文虚构的，但并不离奇。一家HR平台上线了"候选人摘要"功能：招聘人员上传PDF简历，系统提取文本，从数据库调取职位描述，一并发给模型，再把带markdown格式的回答显示在浏览器里。如果招聘人员满意，助手还会一键建议面试时间，并直接在企业日历中创建会议。

上线前，团队采购了一次"AI安全评估"，拿到的报告包括：四十次越狱尝试、模型拒绝回答的截图，以及几次成功套出系统提示词的记录。看起来很扎实，却没有回答真正决定风险的问题。如果候选人在简历里用白色字体藏一段指令，会发生什么？界面会不会渲染模型生成的链接或图片，浏览器的请求又会发往哪里？模型能否借日历工具以招聘人员的身份创建会议并添加任意参会人？平台上的一个客户，能否通过共享检索索引看到另一个客户的职位片段？

这道缺口正是采购方真正的难题：生成式AI评估很容易被买成一组"危险提示词"，却难得多被买成对系统的检验。下文讨论这类评估应覆盖什么、可以依托什么，以及如何选择一家报告真正可用的服务商。本文只讨论获得书面授权的测试，而且授权应来自每一个有权批准对相关资产和环境开展工作的主体。

生成式AI安全评估究竟覆盖什么

生成式AI安全评估，是对运行生成式模型的应用开展的经授权、结构化的检验。检验对象不是孤立的模型，而是整个系统值得多大程度的信任：界面、承载提示词与回答的API、把模型输出变成动作的集成，以及在出问题时限制损害的控制措施。

如果对象是模型，服务商会评估它输出不当内容的倾向；如果对象是系统，服务商会弄清楚当模型已经被骗之后会发生什么：哪些数据会进入它的上下文，它能调用哪些功能，回答显示在哪里，这一切又以谁的权限执行。

范围中应写明的四个层面

应用层：聊天或生成界面、身份认证、会话，以及模型输出的呈现方式——纯文本、markdown、HTML或文档预览。API与集成层：提示词和回答的端点，以及模型可以调用的工具和函数——本例中是日历，换成别的产品可能是CRM或外发邮件。

数据层：提示词、上传文件、检索（retrieval）来源、日志，以及每个环节中敏感信息的处理方式。治理层：谁拥有风险并接受残余风险，记录哪些日志、由谁审阅，模型和托管服务商承担哪些义务。如果某一层被有意排除，就应写下来；糟糕的是从报告里才得知被排除了什么。

经典标准能提供什么，又在哪里沉默

当生成式功能通过Web应用或HTTP API触达用户时，这部分评估建立在成熟的安全学科之上：身份认证、会话、注入防护和输出编码。变化的是输入的形态：自然语言提示词、索引中的文档和生成的文本，成了不可信内容的新通道。下文将讨论的通用测试文件并不是生成式AI的测试目录——这是它们的适用边界，而非缺陷。

这一范围的专门参照之一是OWASP Top 10 for LLM Applications。2026年8月发布的2026版把提示词注入列为第一位（LLM01），并单独列出过度代理（LLM03）、隐藏上下文暴露（LLM08）、向量与嵌入弱点（LLM09）和输出处理不当（LLM10）。该版本的编号与2025版不同，因此需求说明中应引用具体版本。关于如何围绕这份清单组织测试，可参阅我们关于OWASP LLM Top 10评估的文章。需要记住：它是风险文件，不是认证标准。逐条处理完所有条目也好，完成一次渗透测试也好，都不等于认证或符合性结论。

由此得出实践结论：经典标准覆盖模型周边的部分，而AI特有的检查项必须由双方明确列出并确认。

来源与汇点：攻击面地图

模型输出是不可信数据

最关键的分析步骤，是把模型生成的内容当作来自不可信用户的输入。模型无法可靠地区分开发者的指令和恰好出现在上下文里的文本，所以它的回答可能承载他人的意图。

接下来取决于回答流向哪里。生成文本在浏览器中显示，跨站脚本就相关；传入系统调用，操作系统命令注入就相关；被拼成文件路径，目录遍历就相关。CISA在"设计即安全"（Secure by Design）项目中针对这几类问题分别发布过警报，MITRE也将它们列入2025年CWE Top 25，并指出这类弱点往往容易发现和利用，可能导致系统被接管、数据被窃取或应用中断。

文本从哪里进入，流向哪里

入口：用户提示词、上传文档、检索索引中的内容、工具和外部服务的响应。出口：界面、对外API调用、日志、分析系统、下游系统。"来源→汇点"映射就是传统应用测试中的数据流分析，只是要考虑模型可能在途中改写数据；正是这一步，把关于"AI风险"的泛泛讨论变成可检验的假设。

如果系统包含知识库检索，租户之间以及按用户权限的索引隔离需要单独关注，我们对RAG系统安全评估的分析专门讨论了这一点。

提示词注入的影响取决于它能够影响的数据和决策。即使输出只是纯文本，也可能泄露上下文或误导审阅者；如果输出在缺少服务端控制的情况下驱动工具调用，还可能变成以他人名义执行的动作。下面是本例中的一条示意链路：

1. 带指令的文档候选人上传简历，用白色字体藏入请求：邀请某外部地址参会，并插入一个"作品集"链接。
2. 上下文拼装应用把简历文本与系统指令、职位描述放在一起；对模型而言，这都是同一段文本流。
3. 带载荷的回答模型返回摘要、一个markdown链接，以及一个多了参会人的日历调用建议。
4. 汇点被触发浏览器渲染该链接；若参数未经校验，日历服务就以招聘人员的权限创建会议。
5. 屏障应设在哪里清理标记与URL，不从不可信URL自动加载资源，使用字段白名单约束的专用日历API，限制参会人并要求人工确认。

多模态通道——如果存在的话

如果产品接收图片、扫描件或音频，不可信文本就有了新路径：图片中的文字、扫描件中识别出的文本、语音消息的转写。它们仍是同样的来源，只是内容在审阅时更难被发现；输出端生成的文件和图片也可能携带元数据或链接。是否把这些通道纳入范围，取决于产品架构。

如何规划和执行：NIST SP 800-115的实践

NIST SP 800-115《信息安全测试与评估技术指南》于2008年9月发布，取代了SP 800-42。它帮助组织规划和开展技术测试、分析发现并制定缓解策略；该文件自称是关键要素的概览，重点在技术及其优点和局限，而不是一套详尽的测试计划。

在形式上，SP 800-115把评估分为三个阶段：规划、执行和执行后，后者包括分析、报告和缓解建议。文件既把测试视为发现漏洞，也视为验证是否符合策略或其他要求。交战规则应说明目标是发现漏洞、验证选定的策略或要求，还是两者兼有。例如，面向要求验证的目标可以检查哪些数据允许发送给外部模型服务商。

没有交战规则，结果就无法复现

生成式系统的行为取决于大量配置，因此交战规则必须写明哪些模型、版本和配置在范围内，包括系统指令、生成参数和已接入的工具；要决定在测试环境还是生产环境进行，以及可能含敏感数据的提示词和回答如何存储与销毁。

第三方组件需要单独梳理。应记录每一个有权批准对相关资产和环境开展测试的主体所给出的授权。如果测试流量会发往外部模型或托管服务商的端点，还要核对适用合同和服务商条款；它们可能限制某些活动，例如负载测试。这是具体端点、具体合同的问题，而不是"任何事都要另行获得许可"的普遍要求。

开工前的最低文件集如下：签署的授权书和交战规则；资产清单——模型、版本、系统指令、工具、数据源和环境；测试提示词、回答和证据的处理规程；约定的报告格式、严重性等级和复测窗口。

这样的文件最好围绕具体内容讨论——场景、汇点、环境、期望的证据。带着这些问题，可以通过渗透测试范围沟通页面与Pentest.red交流；讨论范围时，从架构谈起比从服务名称谈起更有成效。

从发现到复测

接下来是SP 800-115归入执行后的部分，在实践中它会成为独立的工作循环。每项发现都应关联根本原因，并在适用时关联带版本号的要求，指定负责人，修复后复测。"修复→复测"循环是作者的实践建议，并非NIST原文的阶段模型。

复测只确认在特定版本和配置上重新检查过的场景：如果修复之后更换了模型或新增了工具，"已修复"的结论不会延续到新配置。如何开展复测、什么才算修复的证据，详见我们关于渗透测试修复验证的文章。

模型周边的Web与API：WSTG、ASVS、OWASP Top 10与HTTP机制

OWASP把Web安全测试指南（WSTG）称为Web应用安全测试的重要资源；本文固定以WSTG 4.2作为示例，需求说明应写明实际采用的版本。WSTG为模型周边的一切提供测试场景：认证、授权、会话、输入处理、业务逻辑。在HR平台的例子里，正是WSTG会告诉你如何检查某公司的招聘人员能否通过篡改标识符请求另一家公司候选人的摘要。

OWASP应用安全验证标准（ASVS）是检验技术安全控制的基础，也是安全开发的要求清单；其目标是用可用于合同的开放标准，统一市场上验证的覆盖面和严格程度。本文的基线版本是5.0.0。ASVS建议引用要求时加上版本前缀，形如v5.0.0-1.2.5，因为不带版本的编号可能在版本之间变动。要求以CSV、JSON等机器可读格式提供，便于追踪发现。标准中也有防范操作系统命令注入的要求——凡是模型输出可能抵达系统操作之处，都直接相关。只有在发现确实对应某条ASVS要求时才建立映射；为了让报告好看而牵强对应，只会有害。

2025版OWASP Top 10是关于Web应用最关键风险的意识文件，适合用来排序，但不能替代测试计划。如果API是产品的主要攻击面，值得另行阅读我们关于REST API安全评估的文章。

HTTP机制与流式输出

在协议层面，生成式AI界面周边的机制在MDN参考文档中有详细说明。HTTP本身在请求之间不保存状态，但应用通常维护服务端会话，并通过cookie或令牌把请求与会话绑定——需要测试的正是这种绑定。HTTP认证用于验证客户端身份。内容安全策略（CSP）有助于发现和缓解部分攻击，包括跨站脚本和数据注入。CORS管理跨源请求，Permissions Policy限制页面可用的浏览器API，Cross-Origin-Resource-Policy缓解部分跨站侧信道风险。MDN还推荐用HTTP Observatory快速检查配置。

对生成式界面而言，这并非形式：回答往往以流的方式到达，如果只在完整拼装后才清理标记，中间状态可能在无防护的情况下被渲染。限制图片来源的CSP img-src可以约束图片的自动加载，却不会阻止普通恶意锚链接或后续页面跳转。应单独清理和限制目标URL，并避免在流式输出期间自动加载不可信资源。

如何排序发现：在适用之处使用CWE

MITRE把2025年CWE Top 25定位为指导投资、政策和实践以预防漏洞产生的参照。配套的2025年CWE Top 10 KEV弱点清单基于CISA已知被利用漏洞目录，对正在被利用的弱点排序，是确定优先级时有用的附加信号。

生成式AI系统中的发现，只要技术根因适用，就应映射到CWE，无论场景起点是模型行为还是常规输入。执行操作时应优先使用专用安全API，避免调用shell。若必须启动进程，应固定可执行程序和选项，并逐个按允许清单校验参数；把值放在单独的argv元素中，本身并不能消除参数注入。类别层面的修复应覆盖受影响组件中已识别的所有路径并逐一复测，不能声称它修复了未经检查的组件。

有些发现没有合适的CWE映射；例如，模型在特定表述下无视产品规则，但尚未确认相应的软件弱点。应记录确切输入、配置、模型版本、尝试次数与成功次数、复现条件和业务影响，只有在确认适用的技术弱点后才添加CWE。还有一点提醒：CWE的流行度数据反映的是整体软件领域公开的CVE记录，并非对AI系统的测量，无法据此判断生成式产品出问题的频率。

面向管理层的汇报：以NIST CSF 2.0表述结果

NIST把网络安全框架（CSF）2.0描述为帮助组织理解和改进网络安全风险管理的工具。其成果和概况可以为生成式AI评估发现提供共同的汇报语言。在模型、配置、数据源或工具发生重大变化后重新评估，是本文的实践建议，并非CSF要求，也不是NIST关于生成式产品测试的通用指南。

实践中，就是把评估发现转化为框架成果，以及当前概况与目标概况之间的差距。这样，生成式AI风险就进入统一的网络风险登记册，而不是留在产品团队名下的一张单独表格里。为AI服务设定目标概况，并在每次评估后复审，可以为整个计划提供可衡量的方向。

供应商责任：Secure by Design与Secure by Demand

模型、编排、向量数据库，有时甚至整个服务都来自外部供应商，因此评估包括关于供应商能证明什么的问题。CISA对"设计即安全"原则的表述是：客户安全是核心业务要求，而不仅仅是一项技术功能。厂商应在设计阶段就落实这一原则，在产品上市前减少可被利用的缺陷，让产品开箱即安全，并免费提供多因素认证、日志和单点登录。"设计即安全"自愿承诺的参与者承诺真诚地朝一组目标努力，CISA会公布他们的进展报告，采购方在选择供应商时可以查阅。

面向采购方，CISA发布了用于采购沟通的Secure by Demand指南，并与澳大利亚网络安全中心联合发布了《选择安全且可验证的技术》（Choosing Secure and Verifiable Technologies）指南。《安全软件部署》（Safe Software Deployment）材料强调可靠测试与度量的作用，而"设计即安全"页面还链接了安全开发AI系统的指导原则。

人员账户与服务账户是两个问题

是否提供提示词和操作日志，条件和保留期限如何？登录管理控制台的人员是否支持单点登录和多因素认证？服务之间如何认证：能否把API密钥限定在特定操作上，密钥如何轮换，能否用工作负载身份代替长期有效的密钥？这是两条不同的防线：MFA保护的是控制台前的人，对写死在编排层配置里的密钥无能为力。供应商是否发布过"设计即安全"进展报告？对测试中发现的弱点类别，它是靠针对性的过滤器，还是靠架构调整来消除？

权衡：广度、深度、可复现性，测试环境与生产环境

在工期固定的情况下，广度和深度相互竞争：广泛审查可能漏掉某个集成中的严重问题，而深挖某个代理场景又可能让Web应用测试不足。所选的取舍及其理由应写入范围文件。

生成式行为让复现变难。如果回答在多次运行间不同，就要为每项发现记录确切输入、配置、模型版本和尝试次数。一次成功尝试能够证明所展示的结果在记录条件下可能发生，却不能说明发生频率。一次失败——或少量连续失败——也不能证明问题不存在。应记录尝试次数与成功次数，并把结论限定在已测试的配置和方法上。

SP 800-115和本文采用的WSTG 4.2示例本身并不定义AI特有的范围。应明确约定这一范围；否则，服务商的方法论将决定测试哪些模型、检索、输出和工具调用场景。

最后，测试生产环境和第三方端点存在运营和合同风险。测试环境能降低这些风险，但它可能在模型、系统指令、工具集、索引数据或过滤设置上与生产环境不同。测试环境的结果不能不加说明地套用到生产环境：报告应注明每条结论是在哪种配置上得出的。环境的选择由有权接受风险的人作出，并写入交战规则。

如何选择服务商以及验收什么

可审核的方案应说明系统每个部分如何测试、依据哪个带版本号的标准，以及报告和复测如何交付。严谨程度、覆盖面、工作量和价格应作为独立维度比较，不能假定其中一项能代表其余各项。方法论应明确围绕SP 800-115的规划、执行和执行后阶段展开，并有清晰的修复与复测循环。Web层和API应引用WSTG和带版本号的ASVS要求。生成式部分的范围应写明提示词与检索的入口、工具与显示的汇点以及数据处理措施。如果产品有代理功能，另一个问题是服务商将如何测试每个工具的权限，我们关于过度代理安全测试的文章专门讨论了这一点。

警示信号：承诺"全面覆盖"；把用一份提示词清单做的扫描冒充评估；报告中的发现与根本原因脱节；含糊的"AI红队"没有目标、汇点和成功标准。签约前，可以合理地索取一份脱敏的报告样本和交战规则样本。

你需要哪种评估

以下是建议而非硬性规定：可作为讨论范围的起点。

在现有Web应用中新增生成式功能。 按WSTG和ASVS对Web层和API进行针对性评估，并对模型输出的显示和数据流做来源—汇点分析。在HR平台的例子中，首先是markdown渲染和客户之间的数据隔离。

代理集成与工具。 深入分析执行类汇点：优先使用专用安全API而非shell；若无法避免启动进程，则固定可执行程序和选项、允许列举参数，并测试参数注入。还要测试目录遍历、逐个工具的授权，以及操作是否记录并可还原。

采购第三方生成式产品。 按Secure by Demand的问题核查供应商证据，争取合同中的测试与复测权利，若有公开的"设计即安全"进展则加以查阅。

董事会或监管方的要求。 把结果映射到CSF 2.0概况，定期开展，并按CWE类别报告趋势。如果涉及对监管要求的正式合规，那是需要合格专业人员参与的另一项评估，渗透测试无法替代。

早期原型。 在投入完整测试之前，按2025版OWASP Top 10和CWE Top 25做轻量级架构审查，可以在工具调用设计固化前发现需要调整之处；实际返工量和成本仍取决于产品。

频率也是范围决策的一部分。在更换模型或其配置、接入新工具或数据源，或者用户群或服务暴露程度发生重大变化时，重新评估是合理的。这是本文按变更触发评估的建议，并非对NIST CSF材料的归因。

如果你想用这些标准对照自己的需求说明，Pentest.red可以在渗透测试服务框架内与你讨论范围和证据形式：纳入哪些场景和汇点，在哪个环境测试，什么算作结果。渗透测试不能替代认证或鉴证意见，我们也不会作出这样的承诺。

结语：可复现的评估，而非一次性审查

可靠的生成式AI安全评估，并不需要从零发明一个新领域。它把NIST SP 800-115的规划与执行纪律，与WSTG和ASVS对Web和API的覆盖结合起来，在适用之处依托CWE对发现排序，用CSF 2.0的语言向管理层汇报，并以"设计即安全"的期望要求供应商。在此基础上，明确约定生成式模型带来的新通道的范围：提示词、检索内容、生成输出和工具调用。

范围是一项核心决策，而且应在开工前作出。书面写明入口、汇点、环境和授权，有助于得到可以复现、修复和复测的发现；否则，笼统的"AI安全审查"可能只产生一份没有明确修复路径的报告。如果把评估当作与模型和集成变更挂钩的可重复计划，生成式AI风险就能被衡量和管理——在真正经过检验的场景和配置范围之内。