Wiki Notes

Appearance

04. 数据、日志、红队与事故响应 ​

版本：v1.1

最后更新：2026-07-08

适用对象：已经意识到 AI 安全不只是 prompt 和工具边界，还需要把数据控制、日志留存、红队回归和事故处理做成长期机制的团队

AI 安全真正难的，往往不是“知道有哪些风险”，而是：

  • 出问题时有没有证据
  • 平时留的日志会不会反过来变成泄露面
  • 红队样例能不能变成长期回归集
  • 事故发生后能不能快速停、快速查、快速回

这篇专题重点讲这条治理链。

1. 数据安全在 AI 系统里为什么更复杂 ​

因为数据不只存在于数据库里，还会散落在很多链路：

  • prompt 上下文
  • 检索结果
  • tool request / response
  • trace
  • debug 日志
  • 缓存
  • 向量索引原文
  • 审批记录

如果只看“模型有没有泄露”，会漏掉更常见的问题：

  • 系统自己把太多敏感信息留在了不该留的地方

2. OpenAI 数据控制文档给我们的现实提醒 ​

OpenAI 当前 Data controls in the OpenAI platform 说明了平台侧数据类别和保留路径，也提醒团队：

  • 平台侧控制不等于应用侧自动安全

对应用团队来说，更重要的问题是：

  • 你自己记录了什么
  • 保留多久
  • 谁能看
  • 哪些内容可以回放，哪些必须脱敏

2.1 “日志保留” 和 “应用状态保留” 不是同一件事 ​

OpenAI 当前官方资料明确把平台侧存储拆成至少两类：

  • abuse monitoring logs
  • application state

这两个概念很容易被业务团队混在一起，但工程含义完全不同：

  • abuse monitoring logs 更像平台为安全与滥用治理保留的日志
  • application state 更像某些 API 功能为了完成任务而持久化的状态

按 2026-07-08 复核到的官方说明，默认情况下：

  • 平台的 abuse monitoring logs 最长通常可保留 30 days
  • /v1/responses 在默认或 store=true 时会有应用状态保留
  • /v1/conversations、/v1/files、/v1/vector_stores、/v1/evals、/v1/batches 这类能力还可能带来“直到删除”的状态保留语义

这给应用团队的启发很重要：

  • store=false 不是一句万能免死金牌
  • 你必须按具体 endpoint、具体能力、具体运行形态去盘点证据会落在哪里

2.2 第三方工具、MCP 与托管执行环境也是数据面 ​

OpenAI 当前官方资料还专门提醒：

  • 发给 MCP server 的数据要受第三方服务自己的保留策略约束
  • Hosted Shell / Code Interpreter 这类托管容器在运行期间会写临时应用状态

很多团队容易漏掉这一层，最后就会出现：

  • 主系统日志做了脱敏
  • 但第三方工具返回结果、临时文件、审批附件、调试脚本输出却在别处裸奔

所以安全盘点不该只看：

  • 主数据库
  • 主应用日志

还应该把下面这些一起算进“实际数据面”：

  • 第三方 MCP / connector
  • 托管容器临时文件
  • 导出报表
  • 审批附件
  • 回放 artifact
  • 调试快照

3. 哪些数据最值得先分级 ​

建议至少分下面四类：

3.1 原始输入数据 ​

  • 用户问题
  • 附件
  • 邮件
  • 会话原文

3.2 上下文与检索数据 ​

  • 文档片段
  • OCR / ASR 结果
  • 工具返回文本

3.3 执行动作数据 ​

  • 工具入参
  • 工具出参
  • 审批意见
  • 业务对象标识

3.4 运行观测数据 ​

  • trace
  • 日志
  • metrics
  • replay artifacts

分级之后，才能进一步做：

  • 脱敏
  • 保留期
  • 访问控制

4. 日志为什么不能“什么都记” ​

很多团队为了排障方便，会默认把：

  • 原始 prompt
  • 检索片段
  • 工具参数
  • 输出全文

全部打进日志。

这短期很爽，长期很危险，因为日志本身会变成：

  • 二次泄露面
  • 合规风险面
  • 内部越权面

5. 更稳的日志分层方式 ​

5.1 运行日志 ​

目标是：

  • 排障

建议只留：

  • request id
  • tenant id
  • route id
  • model id
  • timing
  • error code

5.2 安全审计日志 ​

目标是：

  • 追责和审计

建议重点留：

  • actor
  • action
  • target
  • approval id
  • policy id
  • result

5.3 回放证据 ​

目标是：

  • 复盘

更适合：

  • 分级存放
  • 控制访问
  • 配保留期

而不是进所有人都能看的普通应用日志。

5.4 安全证据仓最好和普通运行日志物理分层 ​

真实事故里最容易出现的一个反模式是：

  • 线上普通日志平台保留了太多明文
  • 真正需要回放的高价值证据却没有完整保住

更稳的做法通常是把下面两类东西分开：

  • 普通运行日志
  • 受控证据仓

普通运行日志更强调：

  • 快速检索
  • 低成本
  • 宽访问面

受控证据仓更强调：

  • 精细授权
  • 明确留存期
  • 访问审计
  • 回放一致性

这也是为什么“为了排障方便把所有 prompt、检索片段、工具返回全文都扔进日志平台”通常不是成熟方案。

6. 哪些字段最值得优先脱敏 ​

通常优先考虑：

  • PII
  • 账号标识
  • 联系方式
  • 财务信息
  • 原始密钥 / token
  • 大段敏感原文

脱敏的目标不是“什么都看不见”，而是：

  • 保留足够排障信号
  • 又不把敏感内容全量暴露

6.1 更稳的脱敏原则通常是“保定位能力，去复原能力” ​

例如：

  • 用户邮箱保留哈希或内部 stable id
  • 手机号只保留尾号或 tokenized key
  • 合同、工单、订单号保留可追溯映射而不是明文全文
  • 大段原文改成摘要 + 受控原文索引

这样做的重点不是“让日志完全没法看”，而是：

  • 排障同学还能定位是哪一类对象出问题
  • 但拿到日志的人不能顺手复原整段敏感内容

6.2 安全标识最好独立于业务身份明文 ​

OpenAI 当前 Safety checks 和 Safety best practices 都明确建议使用 safety_identifier，而且建议对邮箱或内部用户 ID 做 hash，再作为稳定标识发送。

这背后的价值不只在平台侧滥用治理，也很适合应用团队自己做：

  • 单用户风险追踪
  • 灰度样本回溯
  • 安全告警聚类
  • 事故期间的局部封禁

对企业系统来说，一个更稳的做法通常是同时维护：

  • 业务身份映射表
  • 外发安全标识
  • 日志里的脱敏 actor key

而不是让所有系统都直接拿真实用户标识互相透传。

7. 红队为什么不能只做一次 ​

OpenAI 当前 Safety best practices 和 Safety checks 都强调：

  • 要持续测试
  • 要对抗式验证

这背后的现实是：

  • 模型变
  • Prompt 变
  • 工具变
  • 检索源变

攻击面也会跟着变。

所以红队更像：

  • 持续性回归机制

而不是上线前一次性动作。

8. 一套更实用的红队样例桶 ​

建议至少覆盖：

8.1 直接越狱桶 ​

  • 诱导绕过规则
  • 角色伪装
  • 请求输出隐藏内容

8.2 间接注入桶 ​

  • 恶意网页
  • 恶意附件
  • 恶意检索片段
  • 恶意工具返回

8.3 数据泄露桶 ​

  • 跨租户内容
  • 敏感字段回显
  • 历史缓存残留

8.4 工具越权桶 ​

  • 低权限角色触发高权限动作
  • 超出范围的对象写入

8.5 审批绕过桶 ​

  • 高风险动作未停下
  • 审批结果与执行对象不一致

8.6 数据与留痕桶 ​

  • store=false 场景下仍出现不符合预期的状态残留
  • 回放 artifact 带出了原始敏感附件
  • MCP / connector 返回值被无控制地落进 trace
  • 调试导出文件绕开了正常审计链

8.7 会话状态与长期记忆桶 ​

  • 旧会话残留影响新请求
  • 已失效的历史上下文继续进入答案
  • 低权限历史内容污染高权限新会话
  • 记忆摘要里意外保留敏感字段

9. 红队结果怎么进入日常治理 ​

更稳的闭环通常是：

  1. 红队发现问题。
  2. 定位是 prompt / tool / policy / data 哪层问题。
  3. 修复策略进入代码或配置。
  4. 样例回流到回归集。
  5. 后续发布门禁必须重新跑这批样例。

否则红队永远只是“发现过”，而不是“真正修过”。

9.1 最好让每条红队样例都带上 root cause 和 closure code ​

如果红队样例只记录：

  • 输入是什么
  • 输出坏了

那它很难长期服务版本治理。

更实用的样例结构通常还要加上：

  • 风险类型
  • 触发层级：prompt / retrieval / tool / approval / logging / memory
  • 预期防线：guardrail / schema / approval / filter / human review
  • 修复责任方
  • closure code：已修复 / 风险接受 / 待迁移 / 不适用

这样后面团队才不会每次看到同一个失败样例，都还要重新猜“这到底归谁”。

10. 事故响应要先准备什么 ​

很多团队对事故响应的想象还是：

  • 出问题了赶紧改 Prompt

但更成熟的事故响应至少要提前明确：

  • 哪些工具可以立即停用
  • 哪些租户或业务线可以隔离
  • 哪些流量可以切回旧版本
  • 哪些日志字段能支持回放
  • 哪些人负责审批、回滚、沟通

10.1 真正要提前准备的还有“局部止血手柄” ​

很多 AI 事故不需要全站停，但需要能快速做这些动作：

  • 停某个高风险 tool
  • 停某类写操作
  • 停某个租户或某条工作流
  • 关闭某个 connector / MCP server
  • 把高风险请求统一切到人工 review
  • 把某组用户切回只读或低能力模型

如果这些手柄没有预先产品化，事故里就很容易变成：

  • 要么啥也关不掉
  • 要么只能整个站点一起停

11. 一套更实用的事故响应链 ​

建议拆成下面几步：

  1. detect：发现异常
  2. contain：隔离风险面
  3. disable：停用高风险动作或工具
  4. replay：回放关键链路
  5. rollback：回退策略或版本
  6. review：复盘并回流样例

这比单纯“修复再上线”更稳，因为它先把风险面收住。

11.1 每个阶段最好有清晰产物，而不是只有口头同步 ​

例如：

  • detect：异常 case 清单、初始严重级别、影响范围
  • contain：已关闭的工具、已隔离的租户、已冻结的版本
  • disable：策略开关记录、审批升级记录、变更单
  • replay：关键 trace、工具参数、检索证据、回放结果
  • rollback：恢复到哪个 release bundle、哪版 policy、哪版 prompt
  • review：根因、补救动作、回归样例、owner 和截止日期

没有这些产物，事故后最常见的结果就是：

  • 大家都记得“当时很忙”
  • 但没人能证明“到底关了什么、恢复到了哪一版”

12. 哪些信号最值得做安全告警 ​

12.1 输入异常 ​

  • prompt injection 命中率异常
  • jailbreak 样例命中增加

12.2 数据异常 ​

  • 跨租户召回
  • 敏感字段回显

12.3 执行异常 ​

  • 高风险工具调用激增
  • 审批绕过
  • 幂等失败重复执行

12.4 运行异常 ​

  • 拒答率异常变化
  • 红队回归失败
  • 安全校验器大面积触发

12.5 平台侧安全信号 ​

OpenAI 当前 Safety checks 官方资料已经明确说明：

  • GPT-5 及后续模型会对请求做风险阈值分类
  • 如果组织长期反复触达高风险阈值，可能收到告警、报错，最终甚至被停用访问

对应用团队来说，这意味着你不该只盯：

  • 自己的业务成功率

还应该单独观测：

  • 哪些用户或租户最常触发高风险安全请求
  • 哪些请求在流式返回前被延迟检查
  • 哪些安全标识已经进入高风险观察列表

否则很多团队第一次意识到有问题，已经是：

  • 流量开始被限
  • 流式结果被延迟
  • 甚至模型访问被收紧

12.6 安全标识和租户标识最好能联查 ​

更稳的监控字段通常至少包括：

  • safety_identifier
  • tenant / workspace / org id
  • tool family
  • policy / guardrail version
  • release bundle id
  • trace id

这样你才能在事故里快速回答：

  • 是某个用户在恶意打
  • 还是某个租户的工作流配置整体跑偏
  • 还是某版发布把正常请求误打成高风险

13. 安全回放至少要保留什么 ​

建议至少保留：

  • request id
  • actor / tenant
  • prompt version
  • model id
  • retrieval evidence
  • tool calls
  • approval status
  • final output
  • release batch id

这些字段不一定都要长期明文留存，但没有它们就很难做有证据的复盘。

13.1 对 Agent / MCP 系统，还应该补几类“边界证据” ​

如果系统已经进入 Agent、tool calling、MCP 或长工作流阶段，建议再补：

  • tool approval decision
  • connector / MCP endpoint 标识
  • 是否使用结构化输出
  • developer / user message 分层摘要
  • 是否命中 guardrail 或 human review
  • 哪个节点第一次接触到不可信外部文本

OpenAI 当前 Safety in building agents 官方资料特别强调：

  • 不要把不可信变量直接塞进 developer messages
  • 用 structured outputs 压缩自由文本通道
  • 对 MCP tools 保持 tool approvals

这说明对 Agent 事故来说，仅有“最终输出 + 错误码”远远不够；真正关键的是：

  • 不可信输入是怎么进入高权限路径的

13.2 事故证据包最好可直接挂到复盘单 ​

一个更实用的事故证据包通常包括：

  • 触发输入摘要
  • 对应 trace 链接
  • 检索 / tool / approval 三层关键片段
  • 涉及的 release bundle
  • 是否存在跨租户或敏感字段暴露
  • 已执行的隔离动作
  • 后续回归样例编号

这样复盘就不需要重新到五六个系统里拼图。

14. 常见反模式 ​

  • 只做红队，不做持续回归。
  • 为了审计把所有原文全量落日志。
  • 事故后只改 prompt，不处理执行边界。
  • 没有隔离手段，出事只能全站停。
  • 日志里没有 release / policy / prompt 版本。
  • 只看主应用日志，不盘点第三方 MCP、连接器和托管容器的数据面。
  • 只有用户明文身份，没有稳定的脱敏安全标识。
  • 证据都在，但回放链和审批链串不起来。

15. 推荐搭配阅读 ​

16. 重点官方资料 ​

以下资源已按 2026-07-08 复核可访问：