跳到主要内容

03-数据外泄与输出处理

核对日期：2026-05-13。

不稳定项：供应商数据保留政策、企业隐私要求、行业监管规则、模型日志字段、浏览器渲染安全和结构化输出能力变化较快；上线前必须按目标环境重新审查。

1. 学习目标​

本专题聚焦两个经常被低估的风险：模型看到了不该看的数据，以及模型输出被当成可信内容继续执行。

学完后你应该能做到：

  • 识别数据外泄在上下文、日志、缓存、RAG、工具和供应商链路中的发生点。
  • 设计数据分类、最小上下文、脱敏、保留、删除和访问控制策略。
  • 解释为什么模型输出不能直接进入 HTML、SQL、shell、文件路径或权限判断。
  • 为输出处理设计 schema 校验、净化、白名单、沙箱和人工确认。
  • 把数据治理和输出治理纳入上线门禁。

2. 数据外泄链路​

数据外泄不只发生在“模型回答了敏感信息”这一刻。更常见的是中间链路不受控。

链路风险防护
上下文构造把完整用户资料、密钥、内部日志发给模型最小字段、脱敏、按任务取数
RAG 检索无权限文档进入上下文ACL 过滤、tenant 隔离
工具调用模型请求过多字段工具字段级授权、后端校验
日志/trace保存完整输入输出脱敏、hash、访问控制
缓存跨用户复用敏感结果cache key 带权限、用户、版本
评测集真实用户数据进入公开样例匿名化、合成数据
供应商数据被保留、训练或跨境处理DPA、企业协议、区域配置
前端展示隐藏内容或脚本执行安全渲染、内容净化

核心原则：模型只应该看到完成当前任务的最小必要信息。

3. 数据分类​

建议至少分四级：

等级示例能否进模型上下文
公开官网 FAQ、公开文档可以，但仍需来源和版本
内部内部制度、非公开说明可以按权限和任务最小化进入
敏感手机号、邮箱、订单、合同、客户反馈脱敏后按需进入，默认不进日志
受监管/凭据密钥、密码、支付信息、身份证、医疗、法律、人事默认不进入，需专项审批和替代方案

数据分类要映射到：

  • 是否可进入 Prompt。
  • 是否可进入 RAG 索引。
  • 是否可进入日志和 trace。
  • 是否可被缓存。
  • 谁可以访问。
  • 保留多久。
  • 如何删除。

4. 最小上下文策略​

错误做法：

把完整用户对象、完整订单、完整聊天历史、完整制度文档全部塞进上下文，让模型自己判断。

正确做法：

任务需要什么字段 -> 后端按权限查询 -> 脱敏/裁剪 -> 加来源和版本 -> 进入上下文

字段级策略示例：

字段处理
user_name可进入上下文
phone只保留后四位或不进入
email可掩码进入，如 a***@example.com
payment_card不进入
api_key不进入，且输出层检测
order_items只给任务需要的字段
internal_note按角色和任务授权

5. 日志和缓存治理​

日志需要可复盘，但不能成为第二个泄漏源。

审计日志建议分层：

层内容访问
业务日志request id、feature、状态、错误类型研发和运维
安全审计用户、工具、审批、策略决策、风险等级安全和授权负责人
受限证据输入输出摘要、证据 ID、参数 hash最小授权、短保留期
原始内容完整上下文和输出默认不存；必要时加密、短期、审批访问

缓存必须满足：

  • key 包含 tenant、user/role、权限版本、prompt version、model version。
  • 不缓存高敏结果。
  • 不跨租户复用。
  • 有失效和删除机制。
  • 缓存命中进入 trace。

6. 输出处理风险​

模型输出默认不可信。尤其当输出会进入另一个解释器时，风险会放大。

输出去向风险防护
HTML/MarkdownXSS、隐藏链接、恶意脚本安全渲染、白名单净化、CSP
SQL注入、误删、越权查询参数化、只读账号、查询模板
shell命令注入、破坏文件禁止直接执行、沙箱、审批
代码RCE、依赖投毒静态检查、隔离运行
URL钓鱼、SSRF域名白名单、协议限制
文件路径路径穿越、覆盖文件规范化、根目录限制
权限判断越权权限只由后端策略决定
金额/结算财务错误规则引擎和人工确认

模型可以建议，不能直接裁决安全、权限和资金。

7. 结构化输出校验​

结构化输出不是为了“看起来整齐”，而是为了让系统能拒绝不合格输出。

示例 schema：

{
  "type": "object",
  "required": ["answer", "citations", "risk_flags"],
  "properties": {
    "answer": { "type": "string", "maxLength": 1200 },
    "citations": {
      "type": "array",
      "items": { "type": "string" },
      "minItems": 1
    },
    "risk_flags": {
      "type": "array",
      "items": {
        "type": "string",
        "enum": ["none", "sensitive_data", "unsafe_instruction", "insufficient_evidence"]
      }
    }
  }
}

校验失败后的处理：

  • 有限重试。
  • 降级为安全拒答。
  • 记录失败样例。
  • 高风险功能触发人工复核。

8. 工程案例​

8.1 日志泄露手机号​

问题：客服摘要功能把完整用户对话和手机号写入 debug 日志。

修正：

  • 日志前统一脱敏。
  • 原始内容默认不记录。
  • trace 只保存 input_hash 和证据 ID。
  • 线上排查需要审批临时访问。

8.2 模型输出 HTML​

问题：运营助手生成 HTML 卡片，前端直接渲染模型输出。

修正：

  • 模型输出改为结构化 JSON。
  • 前端只渲染允许字段。
  • HTML 由模板生成，不由模型直接生成。
  • 如必须渲染 Markdown，使用白名单净化。

8.3 SQL 助手​

问题：模型生成 SQL 后直接连生产库执行。

修正：

  • 只读账号。
  • SQL AST 校验，只允许 SELECT。
  • 表和字段白名单。
  • 限制行数和超时。
  • 高风险查询需审批。

9. 常见反模式​

反模式表现后果修正
全量上下文什么都给模型泄漏面巨大最小必要字段
日志为调试牺牲隐私保存完整输入输出二次泄漏脱敏和分级访问
缓存不带权限同问题复用答案跨用户泄漏key 绑定权限
输出直接渲染HTML/Markdown 原样插入XSS净化和模板
输出直接执行SQL/shell/代码直接跑注入和破坏校验、沙箱、审批

10. 练习​

为一个“合同摘要助手”设计数据治理方案：

  • 列出公开、内部、敏感、受监管/凭据数据。
  • 说明哪些字段可以进入模型上下文。
  • 设计日志字段和保留期。
  • 设计缓存策略。
  • 说明模型输出如何进入前端展示和下游流程。

11. 验收题​

  1. 数据外泄可能发生在哪些非输出链路？
  2. 为什么日志和缓存也要做权限设计？
  3. 什么是最小上下文？
  4. 为什么模型输出不能直接作为 HTML、SQL 或 shell 执行？
  5. 结构化输出校验失败后应该如何处理？

12. 延伸阅读​