Las claves de API compartidas y las cuentas de servicio borran la distinción entre cada agente y quien está detrás de una solicitud. Los registros muestran una credencial, no un agente ni a un ingeniero de soporte que actúa por cuenta de un cliente. A pequeña escala, esto resulta incómodo; a escala empresarial, es peligroso. Los cambios en facturación, historiales médicos o infraestructura que no pueden atribuirse a nadie generan brechas de cumplimiento, complican la investigación de incidentes y obligan a aplicar políticas demasiado permisivas que aumentan el riesgo.

Los flujos de trabajo con varios agentes suelen pasar por orquestadores, agentes de herramientas y servidores MCP. Sin propagación de identidad, el sistema final debe confiar en el intermediario o rechazar la solicitud. Agent Identity admite el paso directo del token cuando los sistemas de destino confían en el token original, las credenciales de cliente de OAuth2 cuando el agente debe actuar por cuenta propia y los intercambios OBO, que generan un token que representa al «agente que actúa en nombre del usuario». Así, el sistema de registro puede aplicar los permisos adecuados para cada usuario sin modificar los agentes.

Una identidad solo es útil si puedes actuar en función de ella. TrueFoundry vincula listas de permitidos a cada agente (usuarios, equipos, aplicaciones y otros agentes) y define permisos de salida para modelos, servidores MCP y servicios. Al retirar una autorización, la puerta de enlace responde de inmediato con un error 403. Al centralizar estos controles, evitas una lógica de acceso duplicada y frágil en los agentes, y dispones de un único lugar para auditar, revocar y ajustar los permisos a medida que cambian la escala o el riesgo.

TrueFoundry admite distintos modelos de identidad: tokens emitidos por TrueFoundry para agilizar la incorporación o identidades respaldadas por un IdP, vinculadas a las reclamaciones de sujeto de Okta, Entra o cualquier proveedor OIDC. También admite la firma SigV4 para flujos de AWS. Los agentes pueden ejecutarse en cualquier entorno y seguir bajo gobernanza: los agentes intermediados reciben controles de políticas de entrada y los agentes integrados, gobernanza de salida. Para los equipos, esto permite una implementación gradual: registrar primero los agentes de alto riesgo y ampliar la cobertura sin rediseñar las implementaciones.

Centralizar la identidad en la puerta de enlace también concentra el riesgo: el intercambio, el almacenamiento en caché y la revocación de tokens pasan a ser funciones críticas de la infraestructura. Habrá nuevas tareas operativas, como supervisar el ciclo de vida de los tokens, escalar la puerta de enlace y reforzar las rutas de intercambio. También conviene evaluar la latencia y los modos de fallo de los flujos OBO y la firma SigV4 bajo carga. TrueFoundry aborda muchas de estas preocupaciones con caché de tokens, lógica de renovación y trazabilidad de OpenTelemetry, pero los equipos de plataforma deben incluir la puerta de enlace en sus SLO y planes de respuesta a incidentes.