敏感信息泄露是什么：LLM 场景下的风险与防护机制
敏感信息泄露指敏感数据被不当披露的风险，常见于 LLM 回答、训练数据或用户会话。本文梳理敏感数据发现、分类定位、DLP 与 WAF 检测的基本思路。
什么是敏感信息泄露？
敏感信息泄露，也称 Sensitive Information Disclosure，指机密、私人、专有或受限制的数据被不当披露的风险。在通用数据安全语境中，数据泄露是一类安全事件，通常涉及受保护、机密或敏感数据被未经授权访问、获取或披露。
在 LLM 和生成式 AI 场景中，敏感信息泄露常表现为模型在回答中无意暴露不应返回的信息，例如与训练数据、用户会话或业务上下文相关的受限制内容。它与普通错误输出的区别，不在于回答是否正确，而在于输出是否暴露了受保护或不应公开的数据。
| 对比项 | 普通错误输出 | 敏感信息泄露 |
|---|---|---|
| 核心问题 | 内容不准确、不完整或理解偏差 | 暴露机密、私人、专有或受限制数据 |
| 风险对象 | 用户体验、业务判断 | 数据安全、隐私保护、访问控制 |
| 判断重点 | 回答是否符合事实或任务要求 | 回答是否包含不应被看到的数据 |
| 常见影响 | 误导、返工、体验下降 | 未授权披露、合规和安全风险 |
要点： 判断敏感信息泄露的关键，是看系统是否披露了不应公开的数据，而不是看回答表面上是否合理。
LLM 场景下敏感信息为什么更难控制？
LLM 的输出会受输入、上下文和模型能力影响，敏感信息披露可能直接发生在模型回答阶段。风险不一定表现为文件下载、数据库导出等传统形式，也可能隐藏在一段自然语言回答、总结、补全或对话续写中。
更复杂的是，泄露来源不一定只来自当前用户输入。训练数据中的信息、用户会话中的上下文，以及应用提供给模型的业务数据，都可能影响最终回答。如果这些数据中包含机密、私人、专有或受限制内容，就需要同时审视多个环节。
可以用四个环节梳理 LLM 应用的风险面：
| 环节 | 需要关注的问题 | 风险说明 |
|---|---|---|
| 输入数据 | 用户是否提交了敏感信息 | 用户可能在提示词、表单或对话中输入私人或业务敏感内容 |
| 训练数据 | 模型是否可能暴露训练数据中的信息 | 如果训练数据包含不应公开的内容，输出阶段可能出现披露风险 |
| 上下文 | 会话、检索结果或业务数据是否包含受限制内容 | 应用提供给模型的上下文越丰富，越需要控制可见范围 |
| 输出回答 | 模型是否返回了不应返回的信息 | 敏感信息泄露常直接体现在最终回答内容中 |
因此，生成式 AI 应用的安全控制不能只停留在数据库或接口层，还需要覆盖输入、上下文组装和输出回答等环节。
敏感信息可能从哪些位置流出？
敏感信息泄露并不只发生在单一系统边界。对于现代应用，数据可能在模型、会话、Web 请求和云端存储之间流动，每个位置都可能形成不同的暴露路径。
| 数据位置 | 可能暴露方式 | 需要关注的控制点 |
|---|---|---|
| 模型回答 | 回答中包含机密、私人、专有或受限制数据 | 输出检测、回答范围控制、敏感内容识别 |
| 训练数据 | 模型输出与训练数据中的敏感信息相关 | 训练数据治理、敏感数据排查、使用范围控制 |
| 用户会话 | 对话上下文中包含用户或业务敏感信息 | 会话隔离、上下文边界、权限控制 |
| 网站请求 | 请求链路中出现敏感字段或不应暴露的数据 | Web 请求检测、字段识别、例外规则控制 |
| 云端数据存储 | 敏感数据分散在不同数据位置 | 敏感数据发现、分类、位置识别和风险管理 |
在 Web 应用场景中，防敏感信息泄露规则可作为识别外泄风险的一类机制。一些云 WAF 在相关功能开启后，会让网站请求默认经过防敏感信息泄露规则检测，从而帮助发现请求链路中的敏感数据暴露风险。
不过，WAF 检测主要覆盖 Web 请求和相关流量场景。对于训练数据、用户会话、云端数据存储和模型输出，还需要结合数据发现、分类、访问控制和 DLP 等机制共同治理。
敏感数据发现与分类有什么治理价值？
敏感数据发现与分类的价值在于先回答一个基础问题：敏感数据在哪里。只有知道哪些数据属于敏感数据、它们位于哪些系统或存储位置，后续风险评估和防护策略才有明确对象。
敏感数据发现服务通常用于持续监控数据并进行分类，也可以显示敏感数据和高风险数据所在的位置。这使安全团队能够从“猜测风险”转向“定位风险”。
常见治理流程
| 步骤 | 目标 | 说明 |
|---|---|---|
| 发现数据 | 找到系统中的数据资产 | 明确哪些系统、表或存储位置包含需要关注的数据 |
| 识别类型 | 判断哪些数据属于敏感或高风险数据 | 例如私人信息、机密业务数据或受限制字段 |
| 定位位置 | 明确敏感数据分布在哪里 | 帮助确定优先治理的系统、字段或存储区域 |
| 制定保护措施 | 将发现结果转化为安全策略 | 可用于访问控制、检测规则和风险管理 |
要点： 敏感数据发现不是最终防护措施，而是数据安全治理的基础环节。它帮助团队先看清敏感数据的位置和类型，再决定如何保护。
数据泄露防护机制如何降低风险？
数据泄露防护通常关注一个核心目标：防止内部或外部人员有意或无意地将敏感信息发送给未经授权的第三方。在企业和云环境中，这类机制常与敏感数据发现、分类、访问控制、流量检测和告警策略配合使用。
DLP 的核心作用
DLP，即 Data Loss Prevention，通常用于降低敏感数据被不当发送、转移或披露的风险。它的重点不是阻止所有数据流动，而是识别敏感信息并控制其流向，尤其是控制是否发送给未经授权的对象。
适合纳入 DLP 关注范围的场景包括：
- 员工或系统向外部发送敏感数据；
- 应用返回内容中包含不应展示的字段；
- 自动化流程将敏感数据传递到未授权位置；
- 生成式 AI 应用把上下文中的受限制信息写入回答。
WAF 检测与白名单边界
在 Web 应用中，防敏感信息泄露规则可以作为流量层面的检测机制。一些 WAF 在相关功能开启后，会让网站请求默认经过防敏感信息泄露规则检测，用于识别可能的敏感信息外泄。
同时，部分防护机制也支持数据安全白名单，使满足条件的请求忽略检测。白名单适合处理明确可信、业务必要且条件清晰的例外请求，但不应被当作普遍绕过检测的手段。
| 机制 | 主要作用 | 需要注意的边界 |
|---|---|---|
| 敏感数据发现 | 找到并分类敏感数据 | 解决“在哪里”的问题，不等同于自动阻断泄露 |
| DLP | 防止敏感信息发送给未经授权第三方 | 需要结合数据类型、流向和权限策略配置 |
| WAF 防敏感信息泄露规则 | 检测 Web 请求链路中的外泄风险 | 主要覆盖 Web 流量场景，不能替代全链路数据治理 |
| 白名单 | 对满足条件的请求忽略检测 | 应严格限定条件，避免扩大例外范围 |
哪些系统需要优先关注敏感信息泄露？
并不是所有系统的敏感信息泄露风险都相同。优先级通常取决于系统是否处理敏感数据、是否存在自动输出、是否对外提供查询能力，以及是否具备足够的检测和例外控制机制。
| 系统类型 | 用户需求 | 解决方式 | 预期效果 |
|---|---|---|---|
| 包含 LLM 或生成式 AI 回答能力的系统 | 避免模型输出机密、私人或受限制数据 | 梳理输入、训练数据、上下文和输出回答的风险面 | 降低回答阶段无意披露的可能性 |
| 持有大量云端数据的系统 | 先知道敏感数据在哪里 | 进行敏感数据发现、分类和高风险位置识别 | 为访问控制和风险管理提供依据 |
| 对外提供网站或接口的系统 | 防止请求链路中出现敏感数据外泄 | 使用 Web 请求检测、字段识别和规则控制 | 降低外部访问导致的数据暴露风险 |
| 存在内部或外部数据流转的系统 | 防止敏感信息发送给未经授权对象 | 引入 DLP 思路，控制敏感数据流向 | 降低有意或无意外发风险 |
优先排查清单
可以用以下问题判断系统是否需要优先纳入敏感信息泄露治理：
- 系统是否处理机密、私人、专有或受限制数据？
- 是否存在用户会话、对话上下文或自动生成回答？
- 是否会把检索结果或业务上下文提供给 LLM？
- 是否对外提供网站、接口、查询或下载能力？
- 请求或返回内容中是否可能包含敏感字段？
- 是否已经进行敏感数据发现、分类和位置识别？
- 是否具备 Web 请求检测、DLP 或类似的数据流向控制机制？
- 是否存在白名单或例外机制，且例外范围是否清晰可控？
如果多个问题的答案为“是”，说明该系统更可能出现敏感信息泄露风险，应优先建立数据识别、输出检测和防护策略的组合机制。