RAG 安全评估：如何测试检索、索引与模型回答

先看一个虚构但合理的场景。一家律师事务所上线了内部助手：它根据合同、制度和内部备忘录组成的知识库回答员工提问，并在每个回答后附上来源链接。试点进展顺利，律师们对准确度很满意。一个月后，一名初级律师询问所里的奖金如何计算，结果收到一份措辞礼貌、格式规整的回答，其中引用了一份受限的合伙人利润分配备忘录。

没有人实施入侵。存放这份备忘录的文件夹权限只在文档写入索引时检查过一次。后来这名律师被调到另一个组，源系统中的权限随之变化，但检索器在查询时从未重新核对权限。助手只是找到了最相关的片段，并如实引用了它。

这只是示意而非真实事件，但其机制在任何检索增强生成（retrieval-augmented generation，RAG）系统中都可能出现。这类产品常被当作"和模型聊天"来测试：跑一批危险提示词、看看拒答，就算完成。然而相当一部分风险存在于模型周围的数据流中：谁能写入被索引的数据源、检索结果如何过滤、回答最终落在哪里、已删除的文档会怎样。下文介绍 RAG 安全评估如何开展、检验哪些信任边界、如何收集证据以及如何确定深度。

RAG 安全评估的范围

RAG 安全评估是对整条流水线进行的、经过授权的结构化测试，而不只是测试聊天界面。系统摄取文档，把它们转换为可检索的表示——向量方案使用嵌入，词法或混合检索也可能使用其他形式，针对每个问题检索相关片段，将片段组装成提示词，再返回模型的回答。目标与一般技术测试相同：找出薄弱点，确认防护有效，交付可修复的发现项。不同之处在于攻击面：不可信内容会进入模型的指令，而模型的回答又会流向网页、API，有时还会流向工具。

范围应由实际架构决定，可能包括：摄取连接器与文件解析器；词法索引，以及在实际采用时的嵌入生成与向量存储；检索器与权限过滤；提示词组装、系统指令与上下文模板；带身份认证和限流的模型网关或 API；网页、聊天和移动客户端中的回答渲染；模型可以调用的工具；以及日志、缓存与监控。

组件可以排除在范围外，但须是有意且有书面记录的决定。如果外部供应商运营的搜索或向量存储不在范围内，报告应明确写出其中的数据隔离未经测试。

宜把 RAG 评估视为常规应用安全测试的延伸。本文选用的生命周期与 Web 层指南并未定义检索和提示词组装测试用例：这部分需由测试人员依据系统架构自行设计。

方法：生命周期、Web 层与可验证要求

规划框架来自 NIST SP 800-115《信息安全测试与评估技术指南》（Technical Guide to Information Security Testing and Assessment），于 2008 年 9 月发布，取代了 SP 800-42。它帮助组织规划和实施技术测试、分析发现项并制定缓解策略；它逐一介绍各种技术及其优势和局限，并明确说明自己并不是一套完整的测试方案。按照该指南，评估在形式上分为规划、执行和执行后三个阶段，最后一个阶段涵盖分析与建议。"发现、修复、复测"这一实践循环是项目的工作逻辑，而不是该标准的原文表述。文档年代并非障碍：规划和约定交战规则的纪律同样适用于 2008 年尚不存在的架构。

对于 RAG 产品的 Web 和 API 层，宜先固定一个方法基线，例如 OWASP Web 安全测试指南（WSTG）4.2 版，并以 OWASP ASVS 5.0.0 作为可验证要求集。关键在于"选定并固定"：标准版本会更新，报告应写明测试依据的是哪一版。

在此基线之上，测试人员定义 RAG 特有目标：检索授权、对检索文本影响的遏制、输出处理以及索引时效性。与管理层沟通时，可把结果转换为 NIST CSF 2.0 的语言，便于与组织其他风险比较。

另一份有用的术语参考是 2026 年 8 月发布的 OWASP 大语言模型应用十大风险 2026 版。与 RAG 最相关的条目包括向量与嵌入弱点、隐藏上下文暴露、提示词注入以及不当输出处理。它是用于讨论范围的风险清单，而不是认证方案。如何围绕它设计测试，我们在 OWASP LLM Top 10 评估 一文中有详细介绍。

威胁模型：究竟是谁在向模型上下文写入内容

RAG 的核心特征是：同一模型上下文中混合了开发者的可信指令和可信度不一的检索内容，模型可能把检索内容误当成指令，因此不能把模型本身当作授权边界。因此，任何能够影响被索引文档的人，都可能影响模型读到的内容：外部网页的作者、邮件的发件人、对共享盘有编辑权限的员工、提交工单的客户。

所以第一项实际工作是绘制数据源地图：谁能写入、变更多快进入索引、原始权限是否得以保留。恰恰在这一步，你可能会发现所谓"内部知识库"有一半由导出的工单构成，而工单正文由外部用户撰写。

界定范围时，可以按几类威胁来思考；这是一种分析模型，而不是流行度排名。间接提示词注入：检索到的文档中的指令试图覆盖系统行为。检索授权绕过：片段被交给无权访问源文档的用户。语料投毒：被植入的内容在检索中胜出。敏感数据泄露：密钥和个人数据进入回答、引用、日志或缓存。不安全的输出处理：回答被渲染为 HTML，或未经编码就传入命令。过度代理：工具根据模型输出被触发，却没有权限校验。

其中许多威胁是旧漏洞的新形态：不安全的输出处理本质上是跨站脚本或注入，检索授权绕过本质上是访问控制问题。下表展示了主要边界所在。

检索授权与租户隔离

对于文档按权限划分的系统，这通常是核心测试：权限是否在查询时执行，而不仅仅在摄取时检查？团队自己也未必清楚答案，因为权限要经过源系统、连接器、索引元数据和检索器过滤多个层次。

该方法依赖多个经授权、权限各异的账户，以及测试租户中明确标注的金丝雀文档。金丝雀文档包含一个唯一字符串，除了从该文档本身之外无法从任何地方获得。测试人员以各角色身份提出以金丝雀文档为最佳答案的问题，除回答正文外，还查看引用、摘录、标题、文件路径、作者姓名和结果数量。元数据泄露可能与正文泄露同样严重。应在记录条件下重复查询：一次确认泄露能证明路径可行，却不能说明发生频率；一次干净结果也不能证明控制有效。

过滤器的位置为何重要

权限过滤可以在检索之前执行，把搜索限制在可访问的文档内；也可以在检索之后执行，从结果中剔除不该展示的内容。先广泛召回候选项，再在组装提示词和生成任何用户可见元数据之前完成过滤，本身并不构成授权缺陷。真正的问题是过滤缺失或发生得太晚：受限文档的标题、计数或片段可能泄露到界面、提示词或回答中。即使后置过滤位置正确，不可访问的候选项也可能挤掉可访问内容，因此仍需测试检索质量和拒绝服务影响。另一个问题是索引时拍下的权限快照：源系统中的权限变了，索引却仍按过时的规则运行。本文开头的场景正是如此。

1. 源系统中文档被限制合伙人限制了备忘录的访问权限，但索引元数据中的权限快照保持不变
2. 另一角色发起查询员工提出的问题恰好以该受限片段为最相关的答案
3. 检索时未核对权限检索器依赖过时的元数据，把该片段排在前列结果中返回
4. 组装提示词并生成回答片段进入上下文，模型转述其内容并附上来源链接
5. 缓存固化泄露回答按问题文本被缓存，并提供给后续用户

多租户

在面向客户的 SaaS 产品中，同样的问题出现在租户层面：要么为每个客户设置独立命名空间，要么使用按租户标识过滤的共享索引。后一种方式需要格外仔细：测试人员在 API 参数中替换租户标识，寻找完全不携带过滤条件的请求，并检查语义缓存、嵌入缓存、索引队列等共享组件。我们在 面向 SaaS 公司的渗透测试 一文中讨论过客户隔离原则，它们同样完全适用于 RAG。

如果你的系统已经有权限划分，或一个索引中承载多个客户，可以提前与 Pentest.red 讨论测试角色的组成、测试租户、金丝雀文档集合，以及团队修复问题时需要的证据。一个方便的起点是 渗透测试范围说明。

间接注入与语料投毒

第二个重要领域是遏制检索文本的影响。测试人员把无害且明确标注的测试文档放入非生产索引，其中包含容易察觉的指令：在回答中加入某个暗号、引用一个不存在的来源、列出上下文中相邻的片段，或调用某个可用工具。目标是衡量架构能否遏制检索文本的影响，而不是制造恶意内容。

这类测试的结果很少是非黑即白的：模型可能忽略一种措辞，却执行另一种。一次确认的“突破”能证明该结果在记录条件下可能发生，却不能说明频率；其后果仍决定优先级。扭曲回答的措辞是一种风险等级；代表用户调用工具或泄露相邻片段的数据，则是完全不同的等级。

语料投毒要从另一个角度检验：对数据源有写入权限的作者，能否让自己的文档在重要查询的检索中胜出？举一个假设的例子：共享盘上出现一份堆砌"供应商付款信息"等字眼的文档，助手于是依据它而非正式流程来回答。测试人员会检查写入权限、片段来源是否可见，以及系统能否区分不同可信等级的数据源。

这里的防护依靠架构，而非单一过滤器：检索文本被视为数据，不同可信度的数据源被分离并加以标注，片段来源对用户可见。修改系统提示词可以降低已知措辞的成功率，但无法消除这一类风险。

模型输出、缓存与传输

输出处理

对于任何接收模型回答的组件而言，回答都是不可信数据。未经针对具体上下文的处理就渲染为活动 HTML，可能导致跨站脚本。传给 SQL、Shell 或 API 的内容，只有在接收方把它解释成语法，或在缺少服务端校验与授权时信任模型选择的操作，才会形成相应风险；API 调用本身不自动等于注入。例如，ASVS 5.0.0 的注入防护章节中有一项要求：通过参数化调用或针对命令行上下文的输出编码来防范操作系统命令注入。对 RAG 而言，只要回答或片段可能到达解释器，这项要求就适用。应优先采用专用安全 API 并避免 Shell；若必须启动进程，应固定可执行程序与选项，并逐项按允许清单校验参数，因为把值放入单独的 argv 元素本身并不能消除参数注入。

Markdown 渲染值得单独检查：如果客户端会自动加载回答中链接的图片，图片地址就可能把上下文片段带走。内容安全策略（CSP）对此有帮助——按照 MDN 的描述，它是一个响应头，让管理员控制客户端可以加载哪些资源，并有助于发现和缓解包括跨站脚本和数据注入在内的攻击。当模型还能执行操作时，工具权限就成为单独的课题，参见我们关于 过度代理安全测试 的文章。

会话、CORS 与缓存

HTTP 在协议层面不在请求间保存状态，但 Cookie 和服务器端会话是添加状态的常规且正确的方式。当回答包含特定用户数据时，缓存键和响应头必须防止跨用户泄露；对于在相同授权条件下返回的相同公开数据，共享缓存仍可能适用。CORS 控制其他源的浏览器脚本能否读取响应，却不是 API 的身份认证或授权。会话令牌必须受保护，每个端点都要执行服务端访问控制。SSE 需同时测试这些控制与 CORS；WebSocket 不以 CORS 作为访问机制，应在升级期间及之后验证认证与授权，并单独评估 Origin 请求头。

应用层回答缓存尤其值得关注：若缓存键只有问题文本，而回答取决于用户或租户权限，缓存可能把原本获准的回答交给未获授权者。只有底层数据被有意公开或授权条件完全相同，且缓存键包含所有相关安全条件时，共享结果才可接受。这些检查依据 WSTG 开展，API 本身的测试方法可参见我们关于 REST API 安全评估 的文章。

摄取、删除与索引时效性

摄取流水线是攻击面中完整的一部分。PDF、办公文档、HTML 和压缩包的解析器处理的是不可信文件：测试人员会检查对畸形文件的处理、解压时的目录遍历，以及对用户看不到但索引能看到的隐藏文本的提取。连接器凭据属于服务凭据，针对它们的问题不是多因素认证，而是作用范围、存储方式、轮换机制以及权限是否过大。此外还要查明谁能绕过数据源直接写入索引。

有一项容易被忽视的检查值得单独强调——删除传播。在源系统中被删除或受限的文档，必须在团队自行确定并书面记录的期限内从回答中消失。测试方法：撤销对金丝雀文档的访问，等待约定时间后以不同角色重复查询，并检查回答缓存、嵌入缓存、派生摘要和索引副本。没有明确期限，这项检查就失去意义："迟早会删掉"既无法验收，也无法证伪。

为何不能跳过传统应用层

模型周围的组件都是普通软件：Web 界面、API、连接器、解析器、管理控制台。MITRE 将其 2025 版 CWE Top 25 清单中的弱点描述为往往易于发现和利用，并可能导致系统被接管、数据被窃取或应用中断，还特别指出命令注入对攻击者尤具吸引力。但要注意，CWE 标识的是弱点类别，而不是某个具体漏洞被利用的概率。

CISA 在"设计即安全"（Secure by Design）倡议下发布的关于消除跨站脚本、操作系统命令注入和目录遍历的警示表明，同样的弱点类别反复出现。如果评估只关注模型行为，这些类别就得不到检验——而模型回答和检索内容恰恰为旧有的解释器打开了新的通道。

本文审阅的资料包也存在数据空白：其中没有可靠测量 RAG 系统受攻击频率或哪类 RAG 特有攻击最常见的数据。这只是对已审阅材料的限制，并非对所有公开文献的穷尽性断言。因此，对供应商给出的"RAG 攻击流行度"统计应保持谨慎，并索取底层数据和方法。

权衡：访问方式、非确定性与环境

只通过聊天界面测试，能够还原外部用户的视角，但这样很难判断授权失效发生在哪里：索引、权限过滤器还是提示词组装。获得架构图、索引结构和权限映射逻辑，能缩短工作量并提高结论可信度，这与 NIST SP 800-115 强调理解每种技术局限的思路一致。代价是客户方需要做更多准备。

模型回答每次运行都会变化，因此单次成功或失败的测试未必具有普遍性。关键测试应当重复执行，并记录模型版本、生成参数、检索器配置和检索到的片段。结果应描述为在特定条件下观察到的行为，而不是保证。

生产环境测试更真实，但可能污染线上索引或暴露真实数据。使用合成或经批准数据的测试环境更安全，但其结果不能不加保留地照搬到生产环境：权限同步、数据源和缓存都可能不同。合理的折中是在测试环境完成主要工作，再按照事先约定的规则在生产环境中有限地确认关键发现。任何向索引写入内容的测试，都需要每个有权批准相关资产与环境测试的主体提供书面授权，并制定清理计划。

最后，被索引的内容可能每天变化，今天的干净结果并不能说明明天的文档。定期评估最好辅以针对检索授权和输出编码的自动化回归测试。

证据、复测与运营

发现项应关联到稳定且带版本号的要求标识。ASVS 推荐使用 v{版本}-{章}.{节}.{要求} 的格式，例如 v5.0.0-1.2.5，因为不同版本之间编号会变化。只有当某项要求确实描述了所发现的问题时，才适合映射到 ASVS 或 CWE；映射本身并不能证明符合该标准。对于在 ASVS 中找不到对应要求的 RAG 特有发现项，可以按照同样的版本规则记录在内部目录中。

日志应能还原为哪个用户检索了哪些文档、调用了哪些工具，但不能成为敏感语料的第二份副本：密钥要脱敏，片段内容要最小化，日志访问要受限，保留期限要有意识地设定。CISA 的"设计即安全"指南指出，产品应默认安全，多因素认证、日志和单点登录等功能应免费提供。不过多因素认证针对的是人；流水线各服务之间的连接需要服务身份、短期令牌和窄化的访问范围。

我们建议考虑的典型修复措施包括：在检索器内部执行授权、把检索文本当作数据处理、按渲染上下文对输出进行编码、为工具赋予最小权限，以及对高影响操作要求人工确认。复测结论只适用于所检验的场景和条件；如何让复测结果可证明，我们在 渗透测试修复验证 一文中有所介绍。

评估深度：从试点到智能体

评估深度应与暴露程度和潜在影响相匹配。下面的分级是我们的实践模型，而非某项标准中的方案；它基于四个问题：索引了哪些数据、谁能发起查询、谁能创建被索引的内容、模型除了回答之外还能做什么。

内部试点

公开或低敏感度文档、内部用户、不接入工具。可以从架构评审、针对性 Web/API 测试和输出处理检查开始。只要不可信作者能够影响语料，或回答会实质影响决策，就应增加间接提示词注入测试；“内部”和“不接工具”本身并不能把该路径判定为低风险。

有权限划分的内部生产系统

文档具有不同访问级别后，情况就变了。需要增加使用多个角色和金丝雀文档的完整检索授权测试、摄取流水线评审，以及删除传播和日志检查。

面向客户与多租户的系统

如果助手由客户使用、索引中存放不同组织的数据，或系统索引外部内容，就需要完整评估：抵御间接注入的能力、租户隔离和缓存，并把浏览器跨源行为与服务端 API 授权分别测试，再加上回归测试自动化。

通过工具执行操作的系统

当模型可以调用 API、修改记录或发送消息时，还要对每个工具进行最小权限评审、确认高影响操作，并在能力变更后复测。应优先使用专用安全 API；避免 Shell，若必须启动进程，则固定可执行程序与选项，并逐项允许参数。

在接入新数据源、增加工具、更换模型或嵌入供应商、调整权限模型以及界面重大更新时，都应重新评估。两次评估之间，由回归测试持续把关。

如何选择 RAG 测试服务商

CISA 的"按需安全"（Secure by Demand）指南面向软件采购方，用于采购谈判。其中的问题适合用来询问 RAG 产品供应商，但不能替代对你自身集成的独立评估。

比较 RAG 安全评估或大语言模型应用审计的报价时，应弄清：工作范围是否覆盖摄取、索引、检索器、提示词组装、模型网关、输出渲染、工具以及 Web 和 API 层；服务商引用哪些方法，如何把发现项关联到带版本的要求；授权测试使用多少角色和金丝雀文档，是否测试租户隔离；如何处理非确定性；交战规则、测试数据处理和索引清理承诺是什么；是否包含复测，每个发现项附带哪些证据。如果测试涉及第三方服务，例如云端模型 API，需核对其使用条款：应取得每个有权批准相关资产与环境测试的主体的书面授权，并在向供应商端点发送测试流量前核对适用条款。

警惕无法验证的说法：没有公开方法的专有风险评分、"无法被攻破"的承诺、没有数据支撑的流行度统计。我们查阅的标准中并未描述专门针对 RAG 测试的认证，因此要问清所声称的资质究竟涵盖什么。渗透测试是测试时点的快照，而不是认证或合规意见。其报告可以为更广泛的符合性评估提供证据，但后者另有范围和具备相应资质的判断主体。

如果你正在筹备此类采购，可以与 Pentest.red 团队讨论你的 RAG 系统架构、纳入范围的组件、测试环境要求以及报告中的证据形式。总体工作流程见 渗透测试服务 页面，讨论所需的初始信息可以通过 范围说明表单 方便地整理。

结语

RAG 安全评估应按应用测试界定范围，并根据架构在不可信内容与模型指令交汇之处加大深度：NIST SP 800-115 提供生命周期，WSTG 提供 Web 层方法，固定版本的 ASVS 提供要求，CWE 类别帮助确定应用弱点的优先级，NIST CSF 2.0 则提供与管理层沟通的语言。

按照本文的实践模型，RAG 的优先方向包括：检索授权与索引时效性、遏制检索内容中的指令，以及安全地处理模型输出。任何结果都是测试时点的快照，应以回归测试加以支撑。选择方法透明、授权纪律严格、报告带版本管理的服务商，并且只在获得每个有权批准相关资产与环境测试的主体书面授权后开展测试。