共享 API 密钥和服务账户模糊了单个智能体与请求发起者之间的区别。日志里记录的只是某个凭证，而不是具体的智能体，也看不出是哪位支持工程师代表客户执行了操作。规模较小时，这只是个不便；到了企业级规模，就会变成严重隐患。无法归因的账单、医疗记录或基础设施变更会造成合规漏洞、增加事件调查难度，还会迫使团队采用过于宽松的策略，扩大风险。

多智能体工作流通常会经过编排器、工具智能体和 MCP 服务器等多个环节。如果身份无法在调用链中传递，最终系统就只能选择信任中间环节，或拒绝请求。Agent Identity 支持多种方式：当下游系统信任原始令牌时，可透传令牌；需要智能体以自身身份行动时，可使用 OAuth2 客户端凭证；也可通过 OBO 交换生成代表“智能体代用户执行操作”的令牌。这样，记录系统便能按正确的用户权限完成授权，而无需修改智能体。

只有能够据身份采取行动，身份才有实际价值。TrueFoundry 为每个智能体配置允许列表，明确哪些用户、团队、应用和其他智能体可以调用它，并设置其可访问的模型、MCP 服务器和服务等出站权限。撤销授权后，网关会立即返回 403。将这些控制集中管理，可以避免在智能体中重复编写脆弱的访问逻辑，并提供统一的位置来审计、撤销和调整权限，及时应对规模或风险的变化。

TrueFoundry 支持多种身份模型：可使用 TrueFoundry 签发的令牌快速接入，也可采用由 IdP 支持的身份，将身份映射到 Okta、Entra 或任何 OIDC 提供商中的 subject 声明。平台还支持 AWS 工作流所需的 SigV4 签名。智能体无论部署在哪里，都可以纳入治理：经代理转发的智能体可实施入站策略控制，嵌入式智能体则可实施出站治理。团队因此可以分阶段推广——先注册高风险智能体，再逐步扩大覆盖范围，无需重新设计部署架构。

在网关层集中管理身份，也意味着风险随之集中：令牌交换、缓存和撤销都将成为关键基础设施。团队需要承担新的运维工作，包括监控令牌生命周期、扩展网关容量，以及强化令牌交换链路。还应评估高负载下 OBO 流程和 SigV4 签名的延迟与故障模式。TrueFoundry 通过令牌缓存、刷新逻辑和 OpenTelemetry 跟踪解决了其中许多问题，但平台团队仍须将网关纳入服务级目标（SLO）和事件响应预案。