AI 编程 Agent 凭证访问的结构化审计日志设计

AI coding agent 是过去十年来开发者机器上权限最高的新用户：它们读取源代码、执行命令、访问凭证。与其他所有特权用户不同的是，它们几乎从未被审计过。如果现在有人问你"这周我的 agent 触碰了哪些 API key？"，你能回答吗？

为什么审计日志对 agent 更重要

传统的 secret 访问有人在循环中：开发者执行一条命令，人的意图就是上下文。Agent 改变了这个等式：

归属不清晰。Agent 执行的命令是由模型决定的——受到其上下文、工具以及潜在注入指令的影响。"谁访问了这个 key"需要包含"当时 agent 在做什么"。

归属不清晰。Agent 执行的命令是由模型决定的——受到其上下文、工具以及潜在注入指令的影响。"谁访问了这个 key"需要包含"当时 agent 在做什么"。

爆炸半径覆盖整个会话。一个 agent 会话通过多次调用触碰多个凭证。如果没有日志，妥协在造成其他损害之前是不可见的。

爆炸半径覆盖整个会话。一个 agent 会话通过多次调用触碰多个凭证。如果没有日志，妥协在造成其他损害之前是不可见的。

合规浮出水面。如果你的架构需要回答"这个 secret 是否被暴露了？"——无论是出于事件调查、客户需求还是你自己的安心——日志决定了答案是确切的还是一个猜测。

合规浮出水面。如果你的架构需要回答"这个 secret 是否被暴露了？"——无论是出于事件调查、客户需求还是你自己的安心——日志决定了答案是确切的还是一个猜测。

好的凭证审计日志是什么样的

结构化的。JSON lines，而不是散文。每个事件是一条包含字段的记录：timestamp、credential key、operation（resolve / refresh / scrub）、invoking context 以及 outcome。

仅追加。日志不能被审计对象重写。基于文件的日志设置 0600 权限并在轮转时重新打开（这样 logrotate 不会丢失事件）；journald 是一个可靠替代方案。

完整的。每个凭证解析都要记录——不只是失败。事件的缺失本身也是信息。

机器可读的。cron、SIEM 或告警使用 --json 输出："连续三次 Bitwarden 解锁失败"应该是你可以检测到的东西，而不是你偶然注意到的东西。

Agent 凭证访问的有用基线：

Resolutions——哪个 key 被解析了、何时、由哪个调用。这是"谁触碰了什么"的记录。

OAuth 生命周期——login、refresh、reauth_required。Token 刷新失败是凭证被撤销或策略变更的早期指标。

DLP 命中——出站模式匹配，带模式（log vs mask）。log 模式下的模式命中是一个差点离开机器的 secret。

Scrub 操作——什么东西被清除了、从哪里清除的。你的擦除层的审计跟踪。

测试：你能回答这个问题吗？

测试 agent 架构是否有足够的审计的好方法：事件审查询问"在那次会话期间 agent 是否访问了生产 key？"如果诚实的答案需要翻阅 shell 历史，你就没有审计日志——你只有希望。

trustless 为每个解析、OAuth 刷新、DLP 命中和 scrub 写入结构化凭证审计事件（0600 权限的仅追加 JSONL，文件或 journald）——外加 trustless doctor --json 用于机器可读形式的设置健康检查。审计命令在命令参考中。

Agent 会变得越来越强大，这意味着每个会话触碰的凭证越来越多。问题不是是否要记录——而是你想让"发生了什么"的答案是查询还是谜团。