智能体审计应记录工具操作的授权依据

Agent 调用了什么工具，不等于系统为什么允许它调用。原文讨论的是企业 AI Agent 的审计记录：当 Agent 能修改业务数据时，只保存对话、调用时间和成功状态，还不足以解释一次操作是否获得了恰当授权。

作者的主张很明确：每次工具调用都应该留下可串联的证据，覆盖任务意图、执行身份、调用参数、控制决策和执行结果。对正在给 AI 接入内部系统的开发者，这比再做一个日志搜索页面更值得先想清楚。

工具返回成功，为什么还解释不了一次操作

原文用一个假设场景说明问题：Agent 收到修改供应商资料的请求，读取内部文档，提取供应商信息，调用 update_supplier，随后收到成功响应。

日志记录了工具名称、完成状态和调用时间。看起来信息齐全，安全工程师复查时却仍然答不上来：

• 当时使用的是哪个 Agent 身份，它获得了谁的授权？
• 哪些指令和数据促成了操作，实际发送的参数是什么？
• 哪条策略允许执行，是否需要人工审批，审批有没有被绕过？
• 目标系统修改了一个字段还是多个字段，结果是否按预期返回给 Agent？

操作发生过的记录，不能单独证明操作受到过控制。

这里的审计轨迹（audit trail），可以理解为一次操作从提出到获准、执行、返回的证据链。聊天记录能帮助理解上下文，却无法自动补齐授权依据和实际变更。

每次调用要留下哪五类证据

作者建议，把每次工具调用连接到五个信息点：

信息点	需要回答的问题
意图（Intent）	Agent 当时试图完成什么任务？
身份（Identity）	哪个 Agent、版本、用户或委托权限发起了请求？
参数（Arguments）	准备向工具发送的精确参数是什么？
控制决策（Control decision）	哪条策略评估了请求，评估结果是什么？
结果（Outcome）	工具返回了什么，操作是否实际完成？

这里不能只记录「检查通过」。复查者还要知道，策略当时看到了什么、基于什么作出判断。否则，即使后来发现执行结果不符合预期，也难以区分是授权范围过宽、检查条件遗漏，还是工具执行出了问题。

这些记录还需要一个共享的执行标识（execution identifier）。原文没有规定字段名或实现方式，但明确要求它能关联用户请求、中间模型步骤、策略决策、人工审批、工具调用和工具结果。

一次任务可能跨越模型服务、审批系统和业务接口。没有共同标识，调查者就得靠时间和文字描述猜测哪些事件属于同一次执行。

验收审计能力，要现场还原一笔操作

作者给出的验收方法很直接：请平台团队拿出一笔已经完成的 Agent 操作，根据存储记录从头重建。

重点不是看仪表盘是否漂亮，而是回答四个问题：Agent 当时有什么权限，策略检查读取了什么，哪些内容被批准、拒绝或升级处理，目标系统最终发生了什么变化。

如果必须翻找几份互不关联的日志，或者只能相信应用生成的一段摘要，作者认为这样的审计记录仍然偏向描述活动，还不足以证明控制过程。

这里并不是说日志不能分散存储。关键在于，记录之间是否有可靠关联，以及调查者能否依据原始证据复核结论。原文没有给出具体存储架构，也没有要求采用某种日志产品。

我的判断

我认同作者把授权过程放进审计范围的方向。对于能写入企业数据的 Agent，只知道工具执行成功，确实无法判断它是否在授权范围内行动。

但这篇属于设计建议，没有实测、事故复盘或对照数据。供应商修改是一个假设案例，不能据此推断某种方案已经降低了多少风险。文末还引向 AXEC 的产品沟通，读者应把前面的原则与后面的推广分开判断。

它也没有覆盖完整落地问题。例如，精确参数和输入文档可能包含敏感信息，如何限制审计记录的访问权限、如何防止记录被篡改，原文都没说清。共享执行标识能帮助关联事件，却不能单独保证记录真实完整。

和常见的接口日志、分布式追踪相比，这套建议补充的是授权依据和审批过程。已有追踪系统可以承载关联关系，但仅有调用链和耗时，还缺少「为什么放行」的证据。

能拿来做什么

• 给 Agent 接入有写入能力的业务工具前，先用五类信息点检查记录设计，尤其确认执行身份、精确参数和策略评估结果是否可查。
• 如果用 Node 服务封装工具调用，可以沿用同一个执行标识关联请求、审批、调用和返回记录，确保跨服务后仍能还原一次操作。
• 验收内部 Agent 平台时，挑一笔真实完成的数据修改，让团队依据存储记录解释授权过程和最终变更，检验记录是否足以支持复查。