Stop Credentialing Your AI Agents Like It’s 2019

别再像 2019 年那样为你的 AI Agent 配置凭证了

TL;DR: Your agent lives for 2 minutes. Its credential lives for 60. That mismatch is your attack surface. A broker that issues task-scoped, short-lived credentials closes the gap before the sprawl starts. 简而言之： 你的 Agent 运行时间只有 2 分钟，但其凭证有效期却长达 60 分钟。这种不匹配就是你的攻击面。通过代理（Broker）发放任务级、短效凭证，可以在凭证蔓延发生前就消除这一隐患。

AI agents are still new. Most teams are just now deploying their first agents at scale. 2026 is year one. And a lot of the identity conversation already assumes the mess exists: registries, inventories, entitlement reviews, cleanup workflows. But the mess is not inevitable. It’s a choice you make at the beginning. AI Agent 尚属新鲜事物。大多数团队才刚刚开始大规模部署他们的首个 Agent。2026 年才是元年。然而，许多关于身份管理的讨论已经默认了混乱的存在：注册表、清单、权限审查、清理工作流。但这种混乱并非不可避免，这取决于你最初的选择。

If you start with a broker where every agent gets a short-lived, task-scoped credential at spawn time, the individual agent credential doesn’t have to become another long-lived thing you track forever. This is the prevention argument: govern the things that persist, but issue ephemeral credentials to the things that don’t. 如果你从一开始就使用代理，让每个 Agent 在生成时获得一个短效的、任务级的凭证，那么单个 Agent 的凭证就不必成为你需要永久追踪的长期资产。这就是预防原则：管理那些持久存在的事物，但为那些瞬时存在的事物发放临时凭证。

The Problem Nobody Talks About

没人谈论的问题

Right now, most teams are credentialing their agents one of three ways: 目前，大多数团队通过以下三种方式之一为 Agent 配置凭证：

1. Shared service account with a static API key. Every agent uses the same key. When one gets compromised, you rotate the key and everything breaks.

2. 带有静态 API 密钥的共享服务账户。 每个 Agent 使用相同的密钥。一旦其中一个被攻破，你必须轮换密钥，导致所有服务中断。

3. OAuth token with a 15-60 minute TTL. The agent runs for a short task, but the credential stays valid much longer.

4. TTL 为 15-60 分钟的 OAuth 令牌。 Agent 执行的是短任务，但凭证的有效期却长得多。

5. Broad IAM role assigned “just in case.” Scoped wide enough to handle every possible task. When an agent gets compromised, it has access to everything.

6. “以防万一”分配的宽泛 IAM 角色。 权限范围大到足以处理任何可能的任务。一旦 Agent 被攻破，攻击者将获得所有权限。

The common thread: credentials outlive the work. The agent is ephemeral. The credential is not. That mismatch is your attack surface. 共同点在于：凭证的寿命超过了任务本身。Agent 是瞬时的，但凭证不是。这种不匹配就是你的攻击面。

The Math on Credential Exposure

凭证暴露的数学逻辑

Let’s make it concrete. 让我们具体来看：

Approach	Agent Lifetime	Credential Lifetime	Exposure Window
方法	Agent 寿命	凭证寿命	暴露窗口
Static API key	2 minutes	Forever	Forever
静态 API 密钥	2 分钟	永久	永久
OAuth token	2 minutes	60 minutes	30x agent lifetime
OAuth 令牌	2 分钟	60 分钟	Agent 寿命的 30 倍
Broker (task-scoped)	2 minutes	Short TTL + release/revocation	Close to task lifetime
代理（任务级）	2 分钟	短 TTL + 释放/撤销	接近任务寿命

At scale, the difference is not academic. The exact numbers depend on your workload, TTLs, and renewal policy, but the shape of the risk is the same. Every 2-minute agent task backed by a 60-minute token leaves 58 extra minutes where a stolen credential is still useful. Multiply that across thousands of agent runs and you’re generating a massive amount of unnecessary credential lifetime every single day. 在大规模场景下，这种差异绝非纸上谈兵。具体数字取决于你的工作负载、TTL 和更新策略，但风险形态是一样的。每一个由 60 分钟令牌支持的 2 分钟 Agent 任务，都会留下 58 分钟的额外窗口，在此期间被盗的凭证依然有效。将其乘以每天数千次的 Agent 运行，你每天都在产生海量不必要的凭证有效期。

When a credential gets stolen, the attacker doesn’t get access to what the agent was doing. They get access to everything that credential could do, for as long as it stays valid. 当凭证被盗时，攻击者获得的不仅仅是 Agent 当时正在执行的操作权限，而是该凭证在有效期内所能执行的一切权限。

Broker vs. Registry: Two Philosophies

代理 vs. 注册表：两种哲学

Registry model: Persistent systems, applications, owners, policies, and audit trails get registered and governed. That’s useful. But if every short-lived agent instance also becomes a persistent identity record, you accumulate thousands of identities, entitlements, and cleanup tasks. At that point, the registry’s value proposition becomes “we’ll help you manage the sprawl.” 注册表模型： 持久化的系统、应用、所有者、策略和审计追踪被注册并受到管理。这很有用。但如果每一个短命的 Agent 实例都变成一个持久的身份记录，你就会积累成千上万的身份、权限和清理任务。此时，注册表的价值主张就变成了“我们将帮你管理这些蔓延的资产”。

Broker model: Every agent gets a credential at spawn. The credential is scoped to exactly what that task needs. It has a short TTL and can be released or revoked when the work is done. The persistent governance layer still exists above the agent, but the per-agent credential doesn’t become a standing entitlement. The broker assumes at least some sprawl is preventable. Its value proposition is “don’t create long-lived agent credentials in the first place.” 代理模型： 每个 Agent 在生成时获得一个凭证。该凭证的范围精确限定在任务所需范围内。它具有较短的 TTL，并在工作完成后可以被释放或撤销。持久化的治理层依然存在于 Agent 之上，但每个 Agent 的凭证不会成为长期存在的权限。代理模型认为，至少部分蔓延是可以预防的。其价值主张是“从一开始就不要创建长期的 Agent 凭证”。

Prevention is usually cheaper than cleanup. Fewer stale identities. Fewer periodic access reviews. Fewer “why did this old agent still have access?” incidents. 预防通常比清理更划算。更少的过期身份，更少的定期权限审查，更少的“为什么这个旧 Agent 还有权限？”这类事故。

What It Looks Like in Code

代码实现示例

Same agent, same system prompt, same LLM, same decision. The only thing that changes is the credential. 同样的 Agent，同样的系统提示词，同样的 LLM，同样的决策。唯一改变的是凭证。

(Code examples omitted for brevity, focusing on the conceptual shift) (为简洁起见省略代码示例，重点在于概念转变)