AI安全攻防与治理之十：模型输出中的敏感信息从哪里来，记忆、检索、日志与上下文泄露的区别

企业在使用大模型时，经常会遇到一种高压场景：

某位用户问了一个问题，模型却输出了不该出现的信息。

可能是：

客户手机号；
其他租户的订单；
内部项目代号；
员工薪酬；
源代码片段；
未发布产品信息；
内部风控标签；
系统提示词；
调查记录；
管理员备注。

这时，最常见的判断是：

模型把我们的数据记住了。

这个判断有时成立，但在企业 AI 应用中，往往不是最常见的原因。

因为企业大模型应用通常并不是一个孤立模型，而是由模型、RAG 知识库、会话记忆、日志平台、缓存、工具调用、业务系统和提示词编排共同组成。

同样一段敏感输出，可能来自完全不同的链路。

如果来源判断错误，整改措施也会完全错位。

例如：

把 RAG 越权检索当成训练记忆，会忽略权限过滤；
把会话串线当成模型记忆，会错过缓存隔离问题；
把工具返回过量数据当成知识库泄露，会错过字段最小化；
把系统提示词暴露当成模型训练问题，会错过上下文拼接和输出控制。

因此，处理敏感信息输出时，第一步不应是"立刻换模型"，而是先回答：

这段信息是如何进入模型上下文，并最终被输出的？

通常可以从四类来源展开调查：

复制代码

模型记忆
RAG 检索
日志、缓存与会话记忆
当前上下文与工具返回

一、模型记忆：信息是否被训练或微调过程吸收

1. 什么是模型记忆

模型记忆通常指敏感信息出现在模型的参数中。

它可能来自：

预训练数据；
微调数据；
偏好优化数据；
评测数据；
训练过程中的泄露；
不受控的用户对话回流；
外部数据集；
不当的数据合并。

当用户输入特定提示时，模型可能复现训练阶段见过的内容或高度相似的片段。

例如，模型在没有连接企业知识库、没有访问历史会话、没有调用工具的情况下，仍输出某段专有源代码或客户资料。

这才更接近通常所说的"模型记住了数据"。

2. 模型记忆的典型特征

模型记忆泄露通常具有以下特征：

关闭 RAG 后仍然出现；
在全新会话中仍可能复现；
换账号、换设备后仍可能出现；
不依赖当前用户权限；
在相近提示词下具有一定稳定性；
输出与某些训练数据存在高度相似；
即使没有工具调用也可能发生。

但需要注意：模型偶尔生成了一个看似敏感的片段，不一定证明它真的记住了真实数据。

模型可能产生幻觉、常见模式补全或拼接式生成。

因此，需要用原始数据、训练集记录、输出相似度和可重复性综合判断。

3. 如何排查

可以按照以下顺序：

复制代码

关闭 RAG
   ↓
关闭会话记忆
   ↓
禁用工具调用
   ↓
使用新会话和不同账号
   ↓
在隔离环境复现
   ↓
对比基础模型与微调模型
   ↓
检查训练、微调和评测数据来源

如果在这些依赖都被关闭后，模型仍能稳定输出与真实敏感数据高度一致的内容，才需要重点调查训练数据和模型参数层面的泄露风险。

4. 主要整改方向

清理训练、微调和评测数据；
建立训练数据来源与版本追踪；
对高敏感数据进行去标识化和最小化；
禁止将生产对话默认回流训练；
做训练前后泄露测试；
重新微调、回滚或替换受影响模型；
对模型发布建立数据供应链审计；
对高风险输出增加检测与拦截。

二、RAG 检索：模型只是查到了不该查的资料

1. RAG 是什么

RAG，即检索增强生成，是企业 AI 最常见的能力之一。

模型回答问题前，会先从文档库、共享盘、Wiki、工单系统、数据库或向量库中检索相关内容，然后将结果拼接进上下文。

流程大致是：

复制代码

用户提问
   ↓
生成查询向量
   ↓
检索相关文档或片段
   ↓
将片段放入模型上下文
   ↓
模型整理并输出答案

如果检索系统没有正确处理权限、租户、密级、版本和字段限制，模型就可能读到不该读的资料。

这时，敏感信息不是模型"记住"的，而是模型"刚刚查到"的。

2. RAG 泄露的典型特征

常见特征包括：

输出内容与某份文档高度一致；
问题换一个问法后可能不再出现；
关闭检索后输出消失；
有权限账号能看到，无权限账号也能看到；
输出与某个知识库、共享盘或工单系统强相关；
输出中可能携带文档标题、版本、术语或引用痕迹；
特定时间内文档更新后，模型输出也随之变化。

例如，用户问：

某客户的项目进度怎么样？

模型回答中包含其他客户的合同金额、联系人和内部风险备注。

这很可能不是模型记忆，而是检索阶段没有进行对象级权限或租户过滤。

3. 常见根因

向量库未携带权限元数据；
检索时只做关键词相似度，不做 ACL 过滤；
文档同步后权限没有同步；
用户角色只在前端判断，检索服务不知道真实身份；
多租户索引混用；
文档删除后向量索引未清理；
缓存命中结果没有按用户隔离；
低密级问题召回高密级文档；
工具检索结果未做字段过滤。

4. 排查方法

排查时应记录：

用户身份和租户；
原始问题；
检索查询；
候选文档列表；
排序得分；
最终进入上下文的片段；
文档来源、版本、权限和密级；
过滤规则是否生效；
模型最终输出与引用片段的对应关系。

关键问题是：

这条敏感信息是否在模型运行前，就已经被放进了上下文？

如果答案是"是"，就应优先修复检索权限，而不是纠结模型参数。

5. 主要整改方向

在检索前实施租户和用户权限过滤；
将文档权限、密级、有效期等元数据同步到向量索引；
对检索结果做字段级最小化；
高敏感文档默认不进入通用检索；
文档变更、撤销和删除同步清理索引；
对检索命中、上下文拼接和模型引用保留审计记录；
对高风险回答要求展示来源和版本；
进行跨租户、跨角色和跨会话的持续红队测试。

三、日志、缓存与会话记忆：数据没有被模型"学会"，却被系统"带错了"

1. 为什么这类问题很常见

企业 AI 应用为了提升体验和排障能力，经常使用：

会话历史；
长期记忆；
Redis 或其他缓存；
Prompt 缓存；
API 网关日志；
应用调试日志；
链路追踪平台；
错误监控系统；
质量评估样本；
用户画像和偏好存储。

这些系统本身不一定会被模型直接读取，但如果集成方式不当，旧数据就可能被重新带入新的会话。

例如：

会话 ID 复用；
缓存 Key 没有包含租户或用户；
多个用户共用同一个 Agent 状态；
长期记忆没有做对象级权限；
调试接口把历史 Prompt 返回给前端；
异常重试时拼接了错误会话上下文；
日志检索工具把其他用户的历史记录返回给模型。

这类问题往往比"模型记忆"更常见，也更容易导致跨用户或跨租户泄露。

2. 典型特征

日志、缓存和记忆泄露通常表现为：

只在某一会话、某一用户或某个时间窗口出现；
清理缓存、重新登录或新建会话后现象消失；
输出中带有上一位用户的上下文痕迹；
不同用户看到相似的历史回答；
发生在高并发、异常重试或版本切换后；
与系统日志、调试工具或内存缓存有关；
在隔离环境或新实例中不容易复现。

例如，用户甲刚上传了一份合同；随后用户乙发起普通问题，却收到模型生成的合同摘要。

这种情况很可能是会话串线或缓存隔离失败，而不是模型在短时间内"记住并主动泄露"了合同。

3. 如何排查

重点检查：

会话 ID 是否全局唯一；
缓存 Key 是否包含用户、租户、应用、环境和版本；
是否有请求上下文复用；
记忆库是否绑定正确主体；
Prompt 缓存命中是否进行权限复核；
错误重试是否误带上一次请求数据；
并发请求隔离是否可靠；
调试日志和追踪数据是否被 Agent 检索；
是否存在共享浏览器会话、共享账号或代理层串话。

可以设计验证：

复制代码

新建用户
→ 新建租户
→ 新建会话
→ 禁用记忆与缓存
→ 重复提问
→ 比较是否仍出现敏感内容

4. 主要整改方向

缓存 Key 强制包含租户、用户和会话维度；
对会话与记忆实施严格主体绑定；
对 Prompt 缓存和结果缓存做权限再校验；
敏感数据不进入通用缓存；
缩短会话和日志保留期限；
禁止生产环境输出完整 Prompt 到普通日志；
对调试和追踪平台实施脱敏、最小权限和审计；
建立缓存清理、会话终止和记忆删除机制；
对并发、重试和故障切换进行隔离测试。

四、当前上下文泄露：模型没有记住，也没有检索，只是看到了不该看到的内容

1. 什么是当前上下文泄露

当前上下文泄露指的是，敏感信息已经在本次模型调用中被拼接进 Prompt，而模型在回答时将其带出。

这些信息可能来自：

系统提示词；
开发者指令；
工具调用返回结果；
内部数据库查询结果；
当前会话的隐含字段；
安全产品的检测结果；
其他 Agent 的中间输出；
RAG 返回但未直接展示的内容；
业务后台的内部备注；
多模态输入中的元数据。

例如，客服 Agent 查询订单时，后台工具返回：

复制代码

订单状态
客户姓名
手机号
地址
内部风控标签
客服备注

用户只问"订单什么时候发货"，但模型因为拿到了全部字段，可能在回答中泄露手机号、地址或内部备注。

问题不在模型记忆，也不一定在检索权限，而在于工具返回的数据超过了任务所需范围。

2. 当前上下文泄露的特征

常见特征包括：

与当前请求和当前工具调用高度相关；
在同一轮或同一会话中出现；
禁用某个工具后现象消失；
输出包含内部字段名、状态码、备注或调试信息；
模型可能在受到提示词注入后泄露更多上下文；
同一用户重复触发相同工具时可复现；
输出不一定与任何知识库文档一致。

例如：

复制代码

用户：请告诉我订单状态。
模型：订单已发货。另外系统备注显示该客户为高风险客户……

用户不应看到的内容不是来自训练，也不一定是 RAG 查到的，而是工具把内部备注交给了模型。

3. 常见根因

工具接口返回全量字段；
模型拥有过大的数据库查询权限；
系统提示词中包含敏感配置；
多个 Agent 的上下文未隔离；
内部调试信息进入 Prompt；
模型输出未经字段级过滤；
提示词注入诱导模型复述上下文；
多模态文件解析带入隐藏内容；
工具结果中包含其他用户或其他租户数据。

4. 主要整改方向

工具按任务设计最小化返回结构；
在服务端做字段级授权和脱敏；
不把密钥、令牌、内部地址和敏感配置写入 Prompt；
对不同 Agent、用户和租户实施上下文隔离；
把工具返回内容标记为数据，而非可执行指令；
高敏感字段不进入模型上下文；
对输出做敏感信息检测和策略拦截；
对系统提示词、工具参数、返回值和最终输出做全链路审计。

五、四类来源如何快速区分

发生泄露后，可以先进行一个基础判断矩阵：

观察问题	模型记忆	RAG 检索	日志/缓存/记忆	当前上下文
关闭检索后仍出现	常见	通常消失	可能存在	视工具而定
新建会话后仍出现	常见	取决于检索	通常消失	通常消失
换账号后仍出现	可能	取决于权限缺陷	通常消失	取决于调用
与具体文档高度一致	可能	常见	可能	不一定
与当前工具调用强相关	较少	可能	可能	常见
清理缓存后消失	较少	较少	常见	较少
基础模型也可复现	可能	否	否	否

这张表只能用于初步定位，不能替代完整调查。

实际事件中，多个来源也可能叠加。

例如：

复制代码

RAG 检索到敏感文档
   ↓
工具返回更多内部字段
   ↓
结果被写入长期记忆
   ↓
后续会话再次泄露

此时不能只修一个点。

六、推荐的调查流程

当模型输出疑似敏感信息时，可以按以下顺序处理：

复制代码

固定输入、输出、会话和时间
   ↓
隔离相关模型、应用、工具和知识库版本
   ↓
检查当前 Prompt 的实际构成
   ↓
检查检索命中文档和权限过滤
   ↓
检查工具调用与返回字段
   ↓
检查会话记忆、缓存和日志关联
   ↓
在隔离环境关闭外部依赖后复现
   ↓
对比基础模型、微调模型和不同版本
   ↓
判断是否涉及训练数据或模型参数
   ↓
修复并做跨租户、跨会话回归测试

第一时间应保留的证据包括：

原始用户输入；
模型输出；
会话 ID；
用户与租户身份；
模型版本；
系统提示词版本；
RAG 检索记录；
工具调用参数与返回结果；
缓存命中记录；
日志和追踪记录；
相关文档版本和权限信息；
环境配置和发布时间。

七、从信息安全角度，真正要治理的是"上下文供应链"

模型不是凭空输出信息。

在企业环境中，它的回答往往依赖一条上下文供应链：

复制代码

训练数据
+ 系统提示词
+ 用户输入
+ 历史会话
+ 长期记忆
+ RAG 文档
+ 工具返回
+ 日志和缓存
= 模型最终可见内容

任何一个环节失控，都可能让敏感数据进入输出。

因此，企业不应只问：

模型有没有记住数据？

还应问：

哪些数据能够进入模型上下文？

谁决定它们是否进入？

是否经过身份、权限、租户和字段控制？

是否会被缓存、复用、记录或再次检索？

出现泄露后能否定位到具体来源？

结语

敏感信息从模型输出中出现，未必代表模型"记住了企业秘密"。

它可能来自：

复制代码

训练或微调产生的模型记忆
RAG 检索的越权文档
日志、缓存或会话记忆串线
当前 Prompt 中的系统、工具或业务数据

四种来源，对应四套不同的控制措施：

复制代码

模型记忆 → 管训练数据和模型发布
RAG 检索 → 管权限、索引和文档生命周期
日志与缓存 → 管隔离、最小化和清理
当前上下文 → 管提示词、工具返回和字段脱敏

处理敏感输出时，最重要的不是先给事故贴上"模型泄密"的标签，而是沿着数据进入模型的路径还原事实。

找到真正的来源，才能修复真正的边界。