AI Agent 一旦接入真实系统，凭证管理就不再是部署细节。搜索、邮件、CRM、项目管理、云盘、数据库，每个工具背后都可能有 API 密钥或访问令牌。凭证一旦混用，Agent 做错事时很难判断是谁授权、用的哪个身份、影响了哪些数据。
昨天写 AI Agent 最小权限 时，重点讲工具、数据和上下文分层。凭证管理是同一条安全线的下一步：权限写在设计文档里还不够，真正执行时要落实到具体密钥、令牌和工具身份。
先区分密钥和令牌
API 密钥通常更像长期凭证，适合由服务端安全保存，不应该被放进提示词、日志或前端配置。访问令牌更适合短期授权，可以带过期时间、作用域和用户身份。两者混在一起，会让权限回收和审计变得很难。
如果 Agent 需要代表用户执行动作，尽量使用带范围和时效的令牌，而不是直接拿一个长期管理员密钥。这样出现异常时，能更快吊销，也能把影响范围控制在当前任务内。
工具身份要和人类身份分开
很多事故来自共用账号。团队为了方便，把一个员工账号授权给 Agent 调工具，后面日志里只看到这个员工做了操作，却看不出是人工处理还是 Agent 执行。更稳的做法是给 Agent 单独工具身份，并在写入动作里记录触发人和确认人。
这能接上 工具权限模型。只读、草稿、执行、回滚不应该共用一套凭证，高风险写入更不应该和查询凭证放在一起。
凭证不要进入上下文
凭证是给工具层使用的，不是给模型阅读的。Agent 可以知道自己有哪些工具、工具能做什么、失败时如何处理，但不需要看到密钥原文。日志也一样，要记录调用了哪个凭证别名、作用域和返回状态，而不是把 token 打出来。
如果需要排查问题，可以参考 决策日志 和 Agent 观测性 的思路：保留足够证据，但敏感字段脱敏。
轮换和吊销要提前设计
凭证管理不能等泄露后才补。每类凭证都应该有负责人、过期时间、轮换频率、吊销方式和影响范围说明。Agent 工作流上线前，要测试凭证过期、权限不足、被吊销时会怎么报错，不能让它继续猜或重复重试。
对外发送、付款、权限修改等高风险动作，还要进入 人工确认节点。凭证只能证明系统允许执行，不代表业务上应该执行。
总结
AI Agent 凭证管理的核心，是把密钥、令牌和工具身份分开。长期密钥少用，短期令牌带范围，工具身份可追踪，日志脱敏，轮换和吊销提前演练。Agent 越多，凭证越不能靠临时配置维持。
