AI Agent 接入业务系统以后，凭证管理很容易被放到最后。团队先把 API Key 填进配置，确认工具能调通，后面再慢慢补权限和审计。问题是，Agent 一旦能持续执行任务，长期密钥就会变成最危险的基础设施。
凭证轮换的目标，不是让配置工作更麻烦，而是让 Agent 就算出错、越权或被错误调用，也不会无限期拿着同一把钥匙到处跑。它应该和 权限审计、数据边界、审计日志字段 放在一起设计。
长期密钥只适合留在控制面
长期密钥不应该直接交给每一次 Agent 运行。更稳的做法是把长期密钥留在后端控制面，由控制面根据任务、用户、工具和风险级别签发短期令牌。Agent 拿到的是一次任务能用的临时凭证，而不是永久通行证。
这样做的好处很直接：任务结束以后令牌自动失效；工具调用范围可以按任务收窄；一旦发现异常，只需要吊销当前令牌或某类工具授权，不必全站换钥匙。
轮换周期要和风险级别匹配
不是所有凭证都需要同一个轮换周期。只读检索、内部草稿、客户外发、财务写入、删除动作，风险完全不同。高风险凭证应该更短、更细、更容易吊销。
这里可以复用 客户可见动作确认 的分层思路。能影响客户、资金、权限和不可逆数据的凭证，不应该和普通查询凭证放在同一个篮子里。
失效验证比轮换记录更重要
很多团队会记录“密钥已轮换”，却没有验证旧密钥是否真的失效。凭证轮换至少要跑一次反向检查：旧密钥还能不能访问，旧令牌有没有缓存，失败日志有没有出现异常重试。
如果 Agent 运行环境里还有旧配置，轮换就只是文档动作。发布前可以把凭证检查加入 质量门禁，确认新旧凭证状态都可查。
审计日志要能追到凭证来源
凭证出问题时，团队要能查清它从哪里签发、给了谁、允许调哪些工具、什么时候失效、被用在哪些任务里。只记录“调用成功”或“调用失败”不够。
凭证轮换和审计日志打通以后，后续做异常复盘、权限收敛和泄露止损才有证据。否则一旦发现异常调用，团队只能临时猜测影响范围。
总结
AI Agent 凭证轮换的关键，是把长期密钥从运行过程里拿出来，用短期令牌、最小权限、失效验证和审计日志控制每一次工具调用。Agent 越能自动执行，凭证就越要短、细、可追踪。
