MCP 审计日志设计：让每次工具调用都能复盘，但不泄露敏感数据

工具调用出了问题时，团队最常问的是“模型到底做了什么”。如果日志里只有 tool=update_ticket status=200，这个问题仍然无法回答。一个有用的 MCP 审计体系需要还原决策链：哪个会话触发了哪个工具，Server 根据什么权限允许执行，实际影响了哪些资源，以及是否发生了重试或降级。

把一次调用拆成事件，而不是一条文本

建议至少记录四个事件：请求接收、授权决策、下游执行、最终响应。它们共享同一个 traceId，并保留 toolCallId、用户 ID、客户端 ID、租户 ID、工具名和批次版本。这样可以把一段模型对话、MCP 连接和业务 API 请求串起来。

一个授权事件可以长这样：

{
  "event": "mcp.authorization.decided",
  "traceId": "tr_01H...",
  "tool": "analytics_export",
  "subject": "user_42",
  "tenant": "team_a",
  "decision": "deny",
  "reason": "missing_scope",
  "requiredScope": "analytics.export"
}

这类结构化字段比自由文本更适合过滤、告警和保留。发生事故时，可以按租户、工具或 scope 回溯；发生权限争议时，也能证明 Server 是拒绝了还是下游拒绝了。

记录摘要，不记录秘密

审计的目标不是复制完整请求。密码、token、cookie、访问令牌、原始用户输入中的个人数据、导出文件内容都不该进入普通日志。对于工具参数，记录经过白名单挑选的摘要：资源 ID、字段名、数量、哈希和长度通常足够。

例如导出报表时，记录“导出 1,204 行、字段为 revenue 和 region、目标为内部下载任务”，不要记录每行数据。对于自然语言请求，可以只保存经过脱敏的摘要或在用户同意的前提下保存受限样本。日志系统本身也要按最小权限访问，不能因为想排障就让所有开发者看到所有用户内容。

写操作必须有结果证据

对任何会改变外部状态的工具，审计记录需要包含请求的幂等键、确认来源、目标资源和最终版本号。这样才能区分“模型建议执行”“用户确认执行”“下游实际成功”。如果下游是异步任务，还要记录任务 ID 与最终完成事件。

不要把 HTTP 200 当成唯一成功标准。一个工单更新接口可能返回 200，但实际没有变化；一个异步接口可能返回 202，随后失败。审计模型应让最终业务结果能被补写或关联，而不是在第一次响应时就假设全部完成。

保留、查询和告警

日志保留时间应按事件类型分层：安全与授权事件通常保留更久，调试细节保留更短，敏感字段默认不采集。为高风险工具建立告警规则，例如短时间内大量跨项目读取、连续被拒绝的导出请求、同一幂等键被多次命中、写工具在异常时段集中执行。

查询界面至少支持按 traceId、用户、租户、工具、资源 ID 和结果筛选。没有这几个维度，审计日志会退化成只能全文搜索的文本堆。定期抽样演练一次：从用户反馈的某个结果倒查到授权决策和下游变更，确认日志真能支撑复盘。

用字段白名单实现脱敏

不要依赖一条巨大的正则表达式在日志出口临时删 token。更可靠的方式是在每个工具旁定义允许记录的字段和必须摘要化的字段。比如 projectId 可以原样记录，查询条件只记录字段名和长度，用户输入记录 hash，导出结果只记录行数和文件 ID。日志序列化器根据白名单构造事件，默认丢弃未知字段。

这种设计的额外好处是 schema 变化时会失败得更明显：新加了敏感参数却没有显式分类，测试应拒绝它进入审计事件。对已经落库的日志设置访问级别和保留期，对异常排障需要的原始样本走单独的受控流程，不要让普通业务日志承担取证和数据仓库两种职责。

审计也需要被审计

最后，记录谁查看、导出或删除了审计数据。日志一旦成为证据，篡改风险就需要被管理。可以通过追加写、受限删除、独立存储和定期完整性校验降低风险。一个好的 MCP 审计体系不会让你收集更多数据，而是让你收集恰好足以解释工具行为的数据。

延伸阅读

• MCP 协议深度解析
• LLM 可观测性
• Prompt Injection 防御