AI agent 往往会把用户输入、知识库片段、工具结果、模型输出和日志串成一条完整链路。如果没有数据脱敏策略，敏感字段可能进入模型上下文、日志系统、评测样本，甚至被后续任务复用。
脱敏的目标不是把所有信息都删掉，而是在完成任务的前提下减少不必要暴露。真正的难点在于：既要保留足够上下文让 agent 完成任务，又不能把无关敏感字段带进模型、日志和评测集。
先给结论：敏感信息要在进入模型前处理
| 位置 | 策略 |
|---|---|
| 用户输入 | 识别并打码不必要字段 |
| 工具参数 | 只传必需字段 |
| 知识库检索 | 按权限召回 |
| 日志记录 | 摘要和脱敏保存 |
| 输出结果 | 发布前检查敏感字段 |
不要只指望模型“不要泄露”。
先定义数据分级
没有分级，就不知道哪些字段能进模型，哪些只能进工具，哪些必须移除。一个实用分级可以是：
| 等级 | 示例 | 处理方式 |
|---|---|---|
| public | 公开文档标题、公开链接 | 可进入上下文 |
| internal | 内部流程、项目状态 | 按权限进入上下文 |
| confidential | 客户联系方式、报价、账号信息 | 默认脱敏或摘要 |
| secret | token、密钥、私有凭证 | 永不进入模型和日志 |
分级应该写进数据字典和工具 schema，而不是靠开发者临时判断。
一、上下文最小化优先于事后补救
如果任务不需要完整手机号、邮箱、地址、内部编号，就不要把这些字段放进 prompt。模型没看到的信息，自然不会在输出里泄露。
上下文最小化是最简单也最有效的保护方式。
可以为每个任务类型定义允许字段：
{
"taskType": "content_brief_generation",
"allowedContextFields": [
"projectType",
"targetAudience",
"publicCaseSummary",
"deadline",
"contentGoal"
],
"blockedContextFields": [
"phone",
"email",
"accessToken",
"privateNote"
]
}
这样上下文拼装器可以先过滤，再把内容交给模型。
二、字段脱敏要分级
不同字段处理方式不同：
| 字段 | 处理方式 |
|---|---|
| 手机号 | 中间位打码 |
| 邮箱 | 用户名部分打码 |
| token / key | 完全移除 |
| 内部价格 | 按权限决定是否传入 |
| 用户备注 | 摘要后传入 |
不要用一个正则处理所有字段，容易漏掉特殊格式。
脱敏结果要保留“形状”，让 agent 仍能判断字段类型：
{
"phone": "138****5678",
"email": "li***@example.com",
"apiKey": "[REDACTED_SECRET]",
"budget": "[CONFIDENTIAL_AMOUNT]",
"customerNote": "用户希望页面更强调交付速度。"
}
[REDACTED_SECRET] 比空字符串更好，因为它告诉 agent：这里确实有字段，只是不能使用。
三、日志不要保存完整 prompt
完整 prompt 对排查有价值，但也最容易包含敏感内容。可以保存 prompt 摘要、字段清单、检索来源 id、脱敏后的输入输出。
高风险任务如果需要完整留存，也要限制访问权限和保留时间。
日志可以保存结构化摘要：
{
"traceId": "run_123",
"taskType": "content_brief_generation",
"promptVersion": "brief-agent-v8",
"contextFields": ["projectType", "targetAudience", "deadline"],
"redactedFields": ["phone", "email"],
"sourceIds": ["doc_rule_01", "message_345"],
"outputRisk": "low"
}
这类日志足够排查上下文来源，又不会保存完整敏感文本。
四、评测样本也要脱敏
很多团队会把失败任务加入回归集。如果直接复制真实用户输入，评测集就会积累敏感信息。更稳的做法是保留任务结构和问题类型，替换具体个人信息。
这样既能复现问题，也减少数据风险。
评测样本处理流程建议是：
失败 run -> 提取最小复现输入 -> 替换真实个人字段 -> 保留结构和错误类型 -> 写入期望输出
不要把用户原始输入直接复制到 eval dataset。评测集会长期存在，比普通日志更容易被多人访问。
五、输出前再做一次敏感字段检查
即使输入做了脱敏，输出前仍要检查。原因很简单：模型可能从上下文摘要中重组出不该出现的信息，也可能引用工具返回的字段。
输出检查可以按两层做：
| 检查 | 方式 |
|---|---|
| 规则检查 | 正则、字段黑名单、secret pattern |
| 语义检查 | 判断是否包含未授权个人信息或内部信息 |
命中后不要直接删除整段内容，可以返回修正后的输出，并在 trace 中记录拦截原因。
六、失败案例：日志系统保存了完整工具参数
一个 agent 为了排查方便，把每次工具调用参数完整写入日志。后来发现其中包含客户联系方式和内部备注。修复后，工具层统一做参数摘要，敏感字段进入日志前脱敏。
关键变化是脱敏前置到工具包装层，而不是依赖开发者手动处理。所有工具返回进入日志前，先经过统一 redaction adapter；所有评测样本入库前，也经过同一套规则。
七、脱敏 Checklist
- 是否定义敏感字段清单
- 信息是否在进入模型前最小化
- 工具参数是否只传必需字段
- 日志是否默认脱敏
- 完整记录是否有权限和保留期
- 回归样本是否替换真实个人信息
- 输出前是否做敏感字段检查
- 数据分级是否写进字段字典
- 上下文拼装器是否按任务类型过滤字段
- 评测样本是否只保留最小复现信息
- 脱敏规则是否在工具、日志、评测中复用
结语
AI agent 的数据保护要贯穿输入、上下文、工具、日志、评测和输出。越早脱敏，越少补救；越少无关字段进入模型，系统越容易被信任。真正可靠的做法，是把脱敏做成统一 adapter，而不是让每个 prompt 自己承诺谨慎。
延伸阅读：
