智能体凭据轮换：尚未被映射到 AI 领域的 DevOps 难题

每个 DevOps 团队都有一套凭据轮换政策。大多数团队已经针对其服务、CI 流水线和数据库实现了自动化。但当你部署一个持有跨五个不同集成的 API 密钥的自主 AI Agent 时，那套轮换政策就变成了一个地雷。Agent 正在执行任务中——分拣 Bug、更新工单、发送 Slack 通知——突然它的 GitHub 令牌过期了。进程看起来很健康。日志显示没有崩溃。但无声无息地，一切都不再起作用了。

这是无人从 DevOps 映射到 AI 的凭据轮换问题。传统的轮换假设工作负载是可预测的、由人管理的，并且具有清晰的边界。自主 Agent 打破了每一个这样的假设。

为什么传统的轮换会破坏 Agent

传统基础设施中的机密轮换遵循一个简单的生命周期：配置凭据、在固定期限内使用、按计划轮换、撤销旧凭据。这之所以有效，是因为传统服务具有可预测的生命周期并能优雅地重启。Web 服务器在下一次连接时获取新的数据库密码。CI 任务在每次运行开始时获取新鲜的凭据。

AI Agent 在三个方面打破了这一模型。

首先，Agent 会同时积累跨多个服务的凭据。一个单一的代码 Agent 可能会同时持有 GitHub、Jira、Slack、云提供商和内部 API 的令牌——每个令牌都有不同的过期窗口。GitHub 令牌大约在 8 小时后过期。Google 令牌 1 小时后过期。Slack 令牌 12 小时后过期。没有统一的过期信号，也没有可以处理的单一轮换事件。Agent 正在管理一个具有独立生命周期的凭据组合。

其次，Agent 是长期运行且有状态的。许多 AI SDK 在初始化时需要凭据，从而产生了在整个执行过程中持久存在于进程内存中的长效机密。当轮换在外部发生时——例如，Vault 轮换了 GitHub 令牌——Agent 仍然持有旧的令牌。它将继续使用失效的凭据直到发生故障，而这种故障通常表现为静默的自动化中断，而不是干净利落的错误。

第三，Agent 在不可预测的任务边界上自主运行。人类开发者知道他们何时开始新任务并可以重新进行身份验证。处于多步骤工作流中间的 Agent——关联日志、查询指标、起草事后分析报告——没有刷新凭据的自然边界。在任务中途中断它以重新验证身份会有数据丢失或状态不一致的风险。

静默失败问题

在 Agent 系统中，凭据过期最危险的方面不是失败本身，而是这种失败的隐形性。当 OAuth 访问令牌在持续运行期间过期时，API 请求开始静默失败。Agent 进程报告正常。编排器没有看到崩溃。但诸如 Bug 分拣、工单创建和通知路由之类的工作流直接停止运作。

如果没有专门的监控，这种故障可能会在数小时内都不被察觉。在一种常见的模式中，团队只有在用户报告 Bug 报告不再转换为 GitHub Issue，或者 Slack 警报变安静时才会发现问题。Agent 一直在运行——它只是失去了执行任何有用操作的能力。

这从根本上不同于服务停机。崩溃的服务会触发警报。一个带有过期凭据的运行中的 Agent 从外部看是正常的。这在运维上相当于一台电源已开启但镜头盖没取下的安全摄像头。

Agent 规模下的凭据扩张

这个问题的规模正在迅速增长。GitGuardian 2024 年的研究发现，仅在一年内，公共 GitHub 提交中就有超过 1,270 万个硬编码机密，其中管理不善的环境变量是主要来源。AI Agent 使情况变得更糟，因为它们会自动从配置文件、环境变量和日志中摄取凭据，而用户并没有明确的意识。

每一个工具集成都会使攻击面成倍增加。IDE 集成暴露了包含会话令牌的 Git 分支、本地文件和工作区元数据。云和 API 访问需要用于 CI/CD 流水线、内部 API 和机密检索系统的凭据——形成了每一步都需要不同密钥的依赖链。Model Context Protocol (MCP) 服务器各自维护独立的身份验证逻辑，使插件间的凭据需求成倍增加。

结果就是凭据扩张——凭据在 Agent 的操作面上迅速累积和重叠。与知道自己在使用哪些密钥的人类开发者不同，Agent 可能无法区分它在环境变量中发现的生产数据库凭据和配置文件中留下的测试密钥。

真正有效的模式

行业正在趋向于一套在不同成熟度水平上解决 Agent 凭据管理的模式。正确的选择取决于你的威胁模型和操作复杂性。

即时 (Just-in-time) 凭据配置。 与其预先为 Agent 加载长效机密，JIT 配置会根据需求创建凭据，范围限定在特定任务，并在任务完成后注销。Agent 请求访问，身份编排层配置一个短效令牌（分钟级，而非小时级），凭据在使用后自毁。

这完全消除了轮换问题——你不需要轮换那些会自动过期的东西。

加载中…