Solving the Identity Crisis for AI Agents
Artículo de ingeniería publicado en el blog de **Uber** Engineering por seis ingenieros (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) el **21 de mayo de 2026**, que expone la **doctrina de identidad y control de acceso de agentes de IA** desplegada en producción en Uber para varios miles de agentes internos. **Tesis central**: los modelos de identidad existentes (humanos + cargas de trabajo) no logran describir la **agencia** — *"un agente se define mejor como una entidad autorizada a actuar por otra o en su lugar"* — y pierden la **procedencia** a lo largo de los saltos de un flujo de trabajo agéntico. **Dos problemas operativos identificados**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — la delegación es el modo por defecto, los flujos de trabajo son composicionales (agentes que llaman a agentes que llaman a herramientas), el comportamiento es dinámico (los planes evolucionan según resultados intermedios); (2) ***"Original Provenance Isn't Effectively Carried Forward Across Agents to Systems"*** — *"El contexto de ejecución (usuario de origen, agentes intermedios) se pierde a través de los saltos entre agentes."* **Arquitectura propuesta** como extensión de la Zero Trust Architecture de Uber: **Agent Registry** (fuente de verdad para las asignaciones agente↔carga de trabajo) + **AI Agent Mesh** (plano de datos entre agentes) + **STS (Security Token Service)** (emisión de JWT de alcance breve) + **MCP Gateway** (punto de aplicación de políticas para la invocación de herramientas) + **AI Gateway** (mediación de las llamadas a LLM externos con barreras de seguridad) + **SPIRE** (proveedor de credenciales de carga de trabajo). **Mecánica criptográfica**: las cargas de trabajo obtienen de SPIRE **SVID (SPIFFE Verifiable IDs)** firmados criptográficamente → el SDK solicita un JWT al STS mediante la identidad de la carga de trabajo → el STS verifica la autorización del agente contra el Agent Registry → se emite un token de vida corta (TTL del orden de minutos) para un **destino específico de un único salto** (claim `Audience` dirigido). **Doctrina central**: ***"Tokens de un único salto y de vida corta. Cada JWT emitido por el STS está pensado para un único salto, con un claim Audience específico y un tiempo de vida corto, del orden de minutos."*** **Preservación de la cadena de actores**: un ejemplo multisalto con el ingeniero de guardia `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway; el JWT final transporta una **cadena de actores** verificable `[user1, oncall-agent, investigation-agent]`, lo que permite decisiones de acceso a nivel de herramienta basadas en el **historial completo de la solicitud**. **Estandarización**: un **Standardized A2A (Agent-to-Agent) Client** que automatiza los intercambios con el STS y la propagación de la cadena de actores — *"la ruta segura es también la ruta más fácil para que los desarrolladores implementen llamadas A2A"* — con una migración por fases de los agentes heredados. **Métricas de producción**: ***"la latencia P99 de la API STS Token Exchange se mantiene sistemáticamente por debajo de 40 milisegundos,"*** miles de agentes internos incorporados, un panel de observabilidad en tiempo real que traza las sesiones multiagente. **Visión a largo plazo — marco de tres capas**: (1) Identity & Trust Foundation (identidad de agente verificable + cadenas de delegación), (2) Dynamic Access Control (permisos basados en contexto + human-in-the-loop), (3) Unified Enforcement Plane (política centralizada y observable). **Alineación con estándares**: el grupo de trabajo IETF **WIMSE** + el draft `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, fundamentado conceptualmente en **OAuth 2.0 Token Exchange (RFC 8693)** y **SPIFFE/SPIRE** (graduado por la CNCF). La primera publicación de referencia de un hyperscaler ajeno a los laboratorios de IA (logística/movilidad) que industrializa la seguridad de los agentes a nivel de infraestructura, cerrando la brecha doctrinal entre los frameworks de skills/harness (Vincent, Lattice, PROJ-AI) y las cuestiones de identidad de nivel empresarial.
**Matt Mathew** (Sr Staff Engineer) · **Prasad Borole** (Staff Software Engineer) · **Meng Huang** (Engineering Manager) · **Sergey Burykin** (Sr Software Engineer) · **Gaurav Goel** (Software Engineer II) · **Bayard Walsh** (Software Engineer I). Tous chez **Uber** · équipe Security/Identity infrastructure responsable du déploiement de l'architecture d'identité agentique en production. Composition d'équipe représentative : un Engineering Manager · un Staff senior cadre · un Staff IC architecte · deux SWE séniors/intermédiaires · un SWE I — pattern classique d'une équipe Uber qui livre une plateforme transverse mission-critical.