技术深度解析
凭证代理的核心架构围绕一个凭证代理服务（CBS）构建，它位于AI代理与目标服务之间。代理不再持有长期有效的API密钥，而是向CBS进行身份验证，CBS随后发放一个短期、上下文绑定的令牌——通常是JWT（JSON Web Token）或带有精细作用域的OAuth 2.0令牌。令牌的生命周期以分钟或小时计，而非数月，其作用域仅限于代理当前任务所需的特定操作。
架构组件：
1. 代理身份提供者（IdP）： 注册代理的身份，通常使用去中心化标识符（DID）或公钥对。这使代理与人类用户的身份解耦。
2. 策略引擎： 根据一组预定义策略评估代理的请求——例如，“仅读取日历事件”、“仅向team@domain.com发送邮件”。该引擎可以是基于规则的，或者越来越多地由一个小型LLM驱动，以解释自然语言策略。
3. 令牌保险库： 存储目标服务的实际凭证（API密钥、OAuth刷新令牌）。代理永远看不到这些凭证；保险库仅释放一个派生令牌。
4. 审计日志： 每次令牌的发放、使用和撤销都会被记录。这为合规性和取证分析提供了完整的监管链。
技术实现示例：
该领域一个流行的开源项目是OAuth2 Proxy（GitHub: oauth2-proxy/oauth2-proxy，10k+星标），它作为一个反向代理来强制执行身份验证。虽然最初是为人类用户设计的，但其令牌交换和会话管理功能正在被适配用于代理工作负载。另一个值得注意的项目是Keycloak（GitHub: keycloak/keycloak，25k+星标），一个开源的身份与访问管理解决方案，现已支持服务账户和细粒度的授权策略，使其成为代理凭证代理的候选方案。
性能考量：
| 指标 | 传统API密钥 | 凭证代理 |
|---|---|---|
| 令牌生命周期 | 数月至数年 | 数分钟至数小时 |
| 作用域粒度 | 粗粒度（全有或全无） | 细粒度（按操作、按资源） |
| 撤销延迟 | 数小时至数天（密钥轮换） | 即时（令牌过期或策略变更） |
| 审计追踪 | 有限（IP日志） | 完整（令牌ID、操作、资源、时间戳） |
| 每次请求开销 | 极小（密钥查找） | 中等（策略评估 + 令牌生成） |
数据要点： 凭证代理每次令牌发放会引入50-200毫秒的延迟开销，但对于大多数代理任务（耗时数秒到数分钟）而言，这可以忽略不计。这种权衡换来了安全粒度和可审计性的巨大提升。
算法创新：
一些高级实现使用基于能力的安全模型，其中令牌本身编码了允许的操作（例如，“read:calendar, write:todo”）。这类似于最初为去中心化网络开发的UCAN（用户控制授权网络）协议。UCAN令牌是自包含的，可以在不联系发行者的情况下进行委托，非常适合代理间的通信。
要点： 技术基础是扎实的，但真正的挑战在于跨不同云提供商和SaaS平台标准化策略语言和令牌格式。预计在未来12-18个月内，将推动Agent OAuth 2.1扩展的制定。
关键玩家与案例研究
已有几家公司率先为AI代理提供凭证代理服务，要么作为独立产品，要么作为更大平台中的功能。
1. WorkOS – 这家初创公司为企业SSO和目录同步提供API。他们最近推出了Agent Identity功能，可发放针对特定SaaS操作的作用域临时令牌。例如，一个客户支持代理可以被授予一个令牌，仅允许读取标记为“紧急”的工单，并使用预定义模板进行回复。WorkOS按令牌发放次数和审计日志保留时间收费，与“凭证交换”模式保持一致。
2. Clerk – 一个用户管理平台，已增加了带有细粒度权限的机器对机器（M2M）身份验证。他们的方法使用带有自定义声明的JWT（例如，`{ "agent": "calendar-bot", "scopes": ["calendar:read"] }`）。Clerk的仪表盘允许管理员定义代理角色并查看实时令牌使用情况。
3. Auth0 (Okta) – 企业身份巨头一直在悄悄开发Agent Access Management，作为其Okta Identity Cloud的一部分。他们的解决方案与现有企业IAM系统集成，允许代理继承人类角色的权限，但带有时间限制的委托。例如，代表销售代表的代理只能在营业时间内访问Salesforce机会。
4. Google Cloud – Google的Identity-Aware Proxy (IAP) 正在被扩展以支持代理工作负载。IAP已经提供上下文感知的访问控制。