# uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21

## Veille

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.

## Titre Article

Solving the Identity Crisis for AI Agents

## Date

2026-05-21

## URL

https://www.uber.com/us/en/blog/solving-the-agent-identity-crisis/

## Keywords

Uber Engineering, identidad de agentes de IA, crisis de identidad de agentes, definición de agencia, agente-como-delegado, flujo de trabajo multisalto, cadena de actores, preservación de la procedencia, Zero Trust Architecture, Agent Registry, AI Agent Mesh, Security Token Service STS, MCP Gateway, AI Gateway, invocación de herramientas MCP, identidad de carga de trabajo SPIRE, SPIFFE Verifiable IDs SVID, tokens JWT de vida corta, claim de audiencia, tokens de un único salto, intercambio de tokens por salto, OAuth 2.0 Token Exchange RFC 8693, protocolo A2A agente a agente, Standardized A2A Client, BaseAgentProtocolClient, IETF WIMSE working group, draft-klrc-aiagent-auth-01, AI Agent Authentication and Authorization, agente de ingeniero de guardia, Oncall Agent, Investigation Agent, Monitoring Agent, rastro de auditoría, política de acceso de grano fino, punto de aplicación de políticas, redacción de datos AI Guard, seguro por defecto, latencia P99 40 ms, fundamento de identidad y confianza, control de acceso dinámico, plano de aplicación unificado, marco de tres capas, observabilidad de agentes, gobernanza de auditoría, procedencia de agentes, cadena de delegación, credenciales de carga de trabajo firmadas criptográficamente, SPIFFE graduado por la CNCF, asignación agente-carga de trabajo, agentes internos de Uber, miles de agentes en producción, seguridad de la infraestructura de agentes, malla de agentes, ruta segura ruta más fácil, migración de agentes heredados refactorización por fases, limitaciones del modelo de identidad, política de sistemas descendentes, atribución contextual

## Authors

**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.

## Ton

**Perfil**: artículo de ingeniería técnico-explicativo corporativo, en el registro de un *blog de ingeniería de hyperscaler*. Formato canónico de Uber Engineering: exposición didáctica de una solución desplegada en producción, narración *problem-first* (dos problemas identificados y nombrados), diagramas de arquitectura (se mencionan las Figuras 1-4), un ejemplo concreto de recorrido multisalto, métricas de validación, visión a largo plazo. Sin marketing disfrazado, sin hipérbole — un registro de **memo de ingeniería operativo** dirigido a ingenieros de seguridad, arquitectos de plataforma y tech leads.

**Estilo**: voz plural de ingeniero-arquitecto (seis coautores), en el registro **corporativo anglosajón preciso** característico de Uber Eng:
1. **Definiciones axiomáticas breves** — *"Un agente se define mejor como una entidad autorizada a actuar por otra o en su lugar."* Una definición de 18 palabras que estructura todo el resto del documento. Modo proposicional.
2. **Enumeración ortogonal de restricciones** — *"La delegación es el modo por defecto... Los flujos de trabajo son composicionales... El comportamiento es dinámico"* — tres propiedades mutuamente excluyentes y colectivamente exhaustivas que justifican la necesidad de un nuevo modelo de identidad.
3. **Patrón problema → componente → mecanismo → ejemplo → métrica** — cada capa se introduce por el problema que resuelve, luego se especifica por su rol, después se detalla por su mecánica (tokens, claims, audience), luego se instancia mediante un recorrido, y finalmente se valida con una medición. Pedagogía controlada de *zoom-in zoom-out*.
4. **Precisión léxica** — *"short-lived tokens," "single-hop," "specific Audience claim," "time-to-live in the order of minutes," "cryptographically signed"* — vocabulario denso en términos técnicos precisos, sin paráfrasis.

**Metáforas y fórmulas clave**:
- ***"Un agente se define mejor como una entidad autorizada a actuar por otra o en su lugar"*** — la **definición fundacional de la agencia** de Uber, que postula la delegación como una propiedad axiomática del agente.
- ***"El contexto de ejecución (usuario de origen, agentes intermedios) se pierde a través de los saltos entre agentes"*** — una fórmula de encuadre breve y operativa para el problema de la procedencia.
- ***"Single-hop, short-lived tokens"*** — el eslogan-doctrina de la solución, el equivalente funcional del *"least privilege"* del Zero Trust clásico adaptado al régimen agéntico.
- ***"La ruta segura es también la ruta más fácil para que los desarrolladores implementen llamadas A2A"*** — la doctrina de adopción: seguridad por defecto sin fricción para el desarrollador (un paralelo directo con el clásico *"paved road"* de SRE).
- ***"La latencia P99 de la API STS Token Exchange se mantiene sistemáticamente por debajo de 40 milisegundos"*** — la fórmula-métrica que zanja el debate *"¿es esta arquitectura viable a la escala de Uber?"* — respuesta: sí, con margen de sobra.

**Posición epistémica**: los autores hablan como **operadores en producción** (miles de agentes internos, P99 medido, un panel de observabilidad ya existente). No teorizan — **documentan una solución ya entregada**. El tono es seguro pero no triunfalista, con un reconocimiento explícito de que el trabajo continúa (*"visión a largo plazo,"* *"refactorización por fases"* de los agentes heredados).

**Autoridad construida mediante**: (a) **tracción en producción** (cifras concretas — P99 <40 ms, miles de agentes), (b) **profundidad arquitectónica** (seis componentes identificados, mecánica criptográfica expuesta), (c) **alineación con estándares** (SPIFFE/SPIRE graduado por la CNCF, RFC 8693, IETF WIMSE), (d) **composición del equipo** (seis coautores en el post — una señal de que se trata de una plataforma transversal madura, no de un POC), (e) **momento de publicación** (publicado mientras la conversación de la industria sobre seguridad de agentes aún está emergiendo — Uber se posiciona como referencia).

**Audiencia e impacto esperado**: un artículo calibrado para **arquitectos de plataforma e ingenieros de seguridad** de grandes empresas que comienzan a desplegar agentes de IA internamente. Audiencia secundaria: la comunidad CNCF/SPIFFE, los colaboradores de los drafts IETF WIMSE, los proveedores de MCP/gateway. Efecto esperado: convertirse en una **referencia canónica** de la doctrina de seguridad agéntica de 2026, junto a las publicaciones de MCP de Anthropic, el Toolshed de Stripe y el trabajo de edge de Cloudflare.

## Pense-betes

- **Fuente**: blog de Uber Engineering (uber.com/blog), publicación oficial. Artículo fechado el **21 de mayo de 2026** — 2 días antes de la fecha de consulta 2026-05-23.
- **Autores (seis coautores)**:
- **Matt Mathew** — Ingeniero Sénior Staff (Sr Staff Engineer)
- **Prasad Borole** — Ingeniero de Software Staff
- **Meng Huang** — Gerente de Ingeniería
- **Sergey Burykin** — Ingeniero de Software Sénior
- **Gaurav Goel** — Ingeniero de Software II
- **Bayard Walsh** — Ingeniero de Software I
- Equipo de infraestructura de Seguridad/Identidad de Uber, responsable de la arquitectura de identidad de agentes en producción.
- **Tesis epistemológica central**: ***"Un agente se define mejor como una entidad autorizada a actuar por otra o en su lugar."*** Esta definición postula la **delegación** como una propiedad axiomática del agente — lo que trastoca el modelo de identidad clásico (humano o carga de trabajo, pero nunca *en nombre de otro*).
- **Dos problemas operativos identificados**: 1. **Current Identity Model Doesn't Describe Agency** — los marcos de identidad existentes cubren a humanos y cargas de trabajo, pero no modelan **actuar en nombre de otro** como modo por defecto. Consecuencias:
- **La delegación es el modo por defecto** — los agentes trabajan en nombre de otros
- **Los flujos de trabajo son composicionales** — los agentes llaman a otros agentes, herramientas y sistemas
- **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."* Consecuencias:
- **Rastros de auditoría incompletos**
- **Aplicación incoherente** de políticas de acceso de grano fino
- Ninguna capacidad de razonar sobre la cadena completa de actores que iniciaron una solicitud
- **Arquitectura — seis componentes identificados**: | Componente | Rol | |-----------|------| | **Agent Registry** | Fuente de verdad para las asignaciones agente↔carga de trabajo | | **AI Agent Mesh** | Plano de datos para la comunicación entre agentes | | **STS (Security Token Service)** | Emite JWT breves y de alcance específico (por audiencia) | | **MCP Gateway** | Punto de aplicación de políticas para la invocación de herramientas (herramientas MCP) | | **AI Gateway** | Mediación de las llamadas a modelos de IA externos + barreras de seguridad (AI Guard para la redacción) | | **SPIRE** | Proveedor de credenciales de carga de trabajo (extensión de la infraestructura Zero Trust existente de Uber) |
- **Mecánica criptográfica de extremo a extremo**: 1. Las cargas de trabajo obtienen de SPIRE **SPIFFE Verifiable IDs (SVID)** firmados criptográficamente. 2. El SDK solicita **JWT** al STS usando la identidad de la carga de trabajo (el SVID). 3. El STS **verifica la autorización del agente** contra el Agent Registry. 4. Se emiten **tokens de vida corta** para un **destino específico de un único salto** (claim `Audience` dirigido, TTL **del orden de minutos**). 5. El token transporta la **cadena completa de actores participantes** (la cadena de actores).
- **Doctrina "single-hop, short-lived" (fórmula canónica)**: > *"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."* Consecuencias operativas:
- **Robo de token = radio de impacto mínimo** (TTL en minutos, audiencia única)
- **Sin token bearer reutilizable entre servicios** — un contraste marcado con el OAuth clásico
- **Cada salto solicita un nuevo token** — la sobrecarga de red se compensa con una latencia <40 ms
- **Recorrido multisalto canónico (ejemplo del artículo — Figura 4)**: 1. **user1** (ingeniero de guardia) inicia una sesión con el **Oncall Agent** 2. El **Oncall Agent** contacta al STS, presenta su identidad SPIRE (Workload-1) y solicita un JWT para el **Investigation Agent** 3. El Oncall Agent envía el JWT al **Investigation Agent** (Workload-2) 4. El **Investigation Agent** realiza un **intercambio de token** con el STS para obtener una audiencia **MCP Gateway** 5. El **MCP Gateway** recibe el JWT con la **cadena de actores** `[user1, oncall-agent, investigation-agent]` — decisión de acceso a nivel de herramienta basada en el historial completo
- **Standardized A2A Client (SDK)**:
- Implementación del **protocolo A2A** (Agent-to-Agent, un estándar emergente referenciado en GitHub).
- **Automatiza** los intercambios con el STS, la construcción de la cadena de actores y la propagación entre saltos.
- Doctrina de adopción: ***"la ruta segura es también la ruta más fácil para que los desarrolladores implementen llamadas A2A"*** — seguro por defecto.
- Código mostrado: una clase `BaseAgentProtocolClient` con métodos asíncronos (construcción del contexto de autenticación + llamada al agente).
- Migración por fases de los agentes heredados mediante refactorización.
- **Estándares externos alineados (a tener en cuenta)**: | Estándar | Rol | |----------|------| | **SPIFFE / SPIRE** | Marco de identidad de cargas de trabajo — un proyecto **graduado por la CNCF** | | **OAuth 2.0 Token Exchange (RFC 8693)** | Base conceptual para el intercambio de tokens por salto | | **IETF WIMSE working group** | Workload Identity in Multi-System Environments — drafts sobre identidad de agentes | | **draft-klrc-aiagent-auth-01** | Draft IETF *"AI Agent Authentication and Authorization"* | | **A2A Protocol** | Estándar Agent-to-Agent (referencia en GitHub) |
- **Métricas de producción (puntos clave)**:
- ***"la latencia P99 de la API STS Token Exchange se mantiene sistemáticamente por debajo de 40 milisegundos"***
- **Miles de agentes internos** incorporados
- Panel de observabilidad en tiempo real que traza las sesiones multiagente
- Picos ocasionales, pero sistemáticamente <40 ms en P99
- **Características de seguridad derivadas**:
- **Intercambio de tokens por salto** — tokens válidos únicamente para un destino específico
- **Preservación de la cadena de actores** — visibilidad completa del linaje en todos los sistemas
- **Aplicación de políticas a nivel de herramienta** — decisiones basadas en el historial completo de la solicitud
- **Redacción de datos vía AI Guard** — la información sensible se filtra al pasar por el AI Gateway
- **Visión a largo plazo — Three-Layer Framework** (arquitectura objetivo): 1. **Identity & Trust Foundation** — identidad de agente verificable + cadenas de delegación 2. **Dynamic Access Control** — permisos basados en contexto + opciones human-in-the-loop + autorización de flujos de trabajo 3. **Unified Enforcement Plane** — decisiones de política unificadas + observabilidad + auditoría + gobernanza ***"La visión a largo plazo es una arquitectura cohesionada donde identidad, riesgo y política funcionan juntos de forma fluida."***
- **Por qué este artículo importa (posicionamiento)**:
- **Primera publicación de referencia de un hyperscaler ajeno a los laboratorios de IA** (Uber = logística/movilidad) que industrializa la seguridad de agentes a nivel de infraestructura.
- **Cierra la brecha doctrinal** entre los frameworks de skills/harness (Vincent *Superpowers*, Lattice, PROJ-AI, Wescale Usine Logicielle Augmentée) que hablan de productividad, y las **cuestiones de identidad de nivel empresarial** que hasta ahora carecían de una doctrina pública.
- **Se alinea con estándares emergentes** (SPIFFE/SPIRE ya adoptado, IETF WIMSE en curso) en lugar de inventar un protocolo propietario — el clásico patrón *cathedral and bazaar* de Uber Eng.
- **Se convierte en una referencia para los CISO** que afrontan el despliegue interno de agentes.
- **Articulación del dosier**:
- **Familia inmediata (infraestructura de agentes empresariales)**:
- **Stripe Minions (Gray 2026-02-09 y 2026-02-19)** — fichas [gray-stripe-minions-coding-agents-part1-2026-02-09] y [gray-stripe-minions-coding-agents-part2-2026-02-19]: más de 1000-1300 PR autónomos/semana, **Toolshed con ~500 herramientas MCP**, devboxes aislados. Stripe y Uber convergen en la **industrialización de los agentes internos** — Stripe se centra en los agentes de codificación y el toolshed MCP, Uber se centra en la **capa de identidad** que hace gobernables estos despliegues.
- **Levie *Building for trillions of agents*** (ficha [levie-building-trillions-agents-software-2026-03-07]) — Aaron Levie (Box): *"software API-first para agentes, infraestructura agéntica, modelos de negocio."* Levie predice; Uber **entrega**.
- **Thoughtworks AI/works™** (ficha [thoughtworks-aiworks-agentic-development-platform-2026-05-12]) — un Control Plane con *"barreras de seguridad activas + linaje de extremo a extremo."* Uber es la **implementación en producción** de lo que Thoughtworks vende como producto.
- **Familia MCP / herramientas**:
- **Anthropic 2026 Agentic Coding Trends Report** (ficha [anthropic-agentic-coding-trends-report-2026-02]) — democratización y supervisión.
- **Cloudflare Markdown for Agents** (ficha [martinho-allen-cloudflare-markdown-for-agents-2026-02-12]) — conversión de HTML a Markdown en el edge. Cloudflare y Uber abordan dos dimensiones distintas de la infraestructura de agentes: la forma de los datos (Cloudflare) frente a la identidad (Uber).
- **Familia harness / arquitectura de agentes**:
- **Trivedy *Anatomy of an Agent Harness*** (ficha [trivedy-langchain-anatomy-agent-harness-2026-03-10]) — Agent = Model + Harness. Uber añade: el harness ahora incluye una **capa de identidad dedicada y consciente de los saltos**.
- **Osmani *Agent Harness Engineering*** (ficha [osmani-agent-harness-engineering-2026-04-19]) — Uber es un ejemplo operativo de lo que Osmani teoriza.
- **Seale *Semantic Agent: (Model+Harness) + (Ontology+Data)*** (ficha [seale-semantic-agent-model-harness-ontology-data-2026-04-17]) — Uber añade una tercera dimensión: *(Identity + Provenance)*.
- **Familia zero trust / seguridad de plataforma**:
- **Sierra AI-native interview** (fichas [sierra-ai-native-interview-iyengar-asemanfar-wang-2026-04-22] y [taylor-sierra-ai-native-interview-engineering-hiring-2026-04-20]) — contratación para las fuerzas. El perfil de ingeniero objetivo de Uber: Plan/Build/Review con competencias en seguridad de agentes.
- **Familia soberanía / defensa / riesgo**:
- **Mensch / Mistral ante la comisión de investigación de la Asamblea Nacional francesa** (ficha [mensch-mistral-commission-enquete-vulnerabilites-numeriques-souverainete-ia-2026-05-13]) — *"seguridad económica"* + *"ciber: capacidades ofensivas lineales."* Uber muestra **cómo** asegurar las cosas operativamente; Mensch muestra **por qué** importa estratégicamente para la soberanía.
- **AISI UK GPT-5.5 cyber capabilities** (ficha [aisi-uk-gpt55-cyber-capabilities-evaluation-2026-04-30]) — modelos capaces de descubrir vulnerabilidades. La defensa pasa por arquitecturas como la de Uber.
- **Sun *Permanent Underclass*** (ficha [sun-nyt-silicon-valley-permanent-underclass-2026-04-30]) — desplazamiento del trabajo hacia el capital. Uber ilustra la capa de infraestructura de *"capital"* que hace posible la automatización a escala.
- **Puntos débiles / preguntas abiertas**:
- **Sin detalles sobre el costo** de la arquitectura (cuántos servidores STS, cuánto QPS, cuántos JWT emitidos por día).
- **Sin cifras sobre las pérdidas de productividad de los desarrolladores** derivadas de la migración de agentes heredados (¿cuántos PR de refactorización? ¿duración total?).
- **No se aborda la posición frente a soluciones de proveedores** (Auth0, Okta, ForgeRock) — Uber optó por construir internamente sobre SPIRE en lugar de comprar, pero sin explicitar el razonamiento build-vs-buy.
- **Sin discusión de los modos de fallo** — ¿qué ocurre si el STS cae? ¿qué modo degradado? ¿qué circuit breaker?
- **Privacidad / RGPD / datos personales** en la cadena de actores — no se aborda (un ingeniero de guardia puede quedar rastreable de forma identificable a través de todos los saltos).
- **Sin discusión** de los ataques de confusión de la cadena de delegación ni de la inyección de eslabones falsos.
- **El protocolo A2A** se cita como dependencia externa — pero el draft del IETF aún no es un estándar. Riesgo: adopción temprana de un protocolo que aún puede evolucionar.
- **Vocabulario Uber-eng a recordar**: *agency (definición de Uber)*, *single-hop short-lived tokens*, *actor chain*, *agent registry*, *AI agent mesh*, *secure path = easiest path*, *per-hop token exchange*, *provenance preservation*, *MCP gateway como policy enforcement point*, *AI gateway como capa de redacción*, *three-layer framework (identidad / acceso / aplicación)*.
- **Útil para**:
- Presentaciones ejecutivas para CISO sobre seguridad de agentes empresariales (referencia canónica).
- Doctrina de arquitectura para clientes industriales que despliegan agentes internos (≥100 agentes en flota).
- Comparación build-vs-buy para soluciones de IAM agéntico.
- Argumento a favor de SPIFFE/SPIRE como el **estándar de facto** para la identidad de cargas de trabajo (graduado por la CNCF + adoptado por Uber).
- Referencia en cualquier documento de planificación de plataformas de agentes empresariales (control plane, capa de identidad, observabilidad).
- Convergencia con la doctrina **Usine Logicielle Augmentée** de Wescale y **AI/works™** de Thoughtworks sobre la necesidad de un *"control plane"* maduro.

## RésuméDe400mots

Seis ingenieros de **Uber** (Matt Mathew et al.) publicaron un artículo en el blog de Uber Engineering el 21 de mayo de 2026, en el que exponen la **arquitectura de identidad y control de acceso de agentes de IA** desplegada en producción en Uber para **miles de agentes internos**. **Tesis central**: ***"un agente se define mejor como una entidad autorizada a actuar por otra o en su lugar,"*** lo que deja obsoleto el modelo clásico de identidad humano+carga de trabajo.

**Dos problemas identificados**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — la delegación es el modo por defecto, los flujos de trabajo son composicionales, el comportamiento es dinámico; (2) ***"Original Provenance Isn't Effectively Carried Forward Across Agents to Systems"*** — *"el contexto de ejecución se pierde a través de los saltos entre agentes"* — lo que genera lagunas de auditoría e impide la aplicación coherente de políticas de acceso de grano fino.

**Arquitectura** como extensión de la Zero Trust Architecture de Uber: **Agent Registry** (fuente de verdad 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** (aplicación de políticas para herramientas) + **AI Gateway** (mediación de LLM + redacción vía AI Guard) + **SPIRE** (proveedor de credenciales de carga de trabajo).

**Mecánica**: las cargas de trabajo obtienen de SPIRE **SPIFFE Verifiable IDs (SVID)** firmados criptográficamente → el SDK solicita un JWT al STS → el STS verifica la autorización 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`). **Doctrina canónica**: ***"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."***

**Recorrido multisalto**: un ingeniero de guardia `user1` → Oncall Agent → Investigation Agent → MCP Gateway. El JWT final transporta una **cadena de actores** verificable `[user1, oncall-agent, investigation-agent]` — decisiones de acceso a nivel de herramienta basadas en el **historial completo** de la solicitud.

**Estandarización**: un SDK **Standardized A2A (Agent-to-Agent) Client** 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."*** 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, observabilidad en tiempo real.

**Visión a largo plazo — marco de tres capas**: (1) Identity & Trust Foundation, (2) Dynamic Access Control, (3) Unified Enforcement Plane.

**Estándares externos**: SPIFFE/SPIRE (graduado por la CNCF), OAuth 2.0 Token Exchange (RFC 8693), grupo de trabajo IETF WIMSE, draft `draft-klrc-aiagent-auth-01`, protocolo A2A.

**Alcance**: la primera publicación de referencia de un hyperscaler ajeno a los laboratorios de IA que industrializa la **seguridad de agentes a nivel de infraestructura**, cerrando la brecha doctrinal entre los frameworks de skills/harness (productividad) y las cuestiones de **identidad de nivel empresarial** (gobernabilidad). Se convierte en una referencia canónica para arquitectos de plataforma, ingenieros de seguridad y CISO que afrontan el despliegue interno de agentes.

## GrapheDeConnaissance

- Uber Engineering —a_créé→ architecture identité agent IA (déployée en production) (TECHNOLOGIE, 0.98)
- Matt Mathew —travaille_chez→ Uber Engineering (ORGANISATION, 0.98)
- Prasad Borole —travaille_chez→ Uber Engineering (ORGANISATION, 0.98)
- Meng Huang —travaille_chez→ Uber Engineering (ORGANISATION, 0.98)
- Uber Engineering —affirme_que→ un agent = entité autorisée à agir pour ou à la place d'un autre (AFFIRMATION, 0.99)
- Uber Engineering —affirme_que→ le modèle d'identité classique ne décrit pas l'agency (AFFIRMATION, 0.98)
- workflows agentiques —est_instance_de→ processus compositionnels (agents appellent agents et tools) (CONCEPT, 0.97)
- comportement agentique —est_instance_de→ comportement dynamique (plans évoluent selon résultats intermédiaires) (CONCEPT, 0.97)
- Uber Engineering —affirme_que→ "Execution context (originating user, intermediate agents) is dropped across agent hops" (CITATION, 0.98)
- perte de provenance —réduit→ cohérence d'application des politiques fine-grained (CONCEPT, 0.96)
- architecture Uber —est_basé_sur→ Zero Trust Architecture (METHODOLOGIE, 0.97)
- Agent Registry —est_instance_de→ source of truth pour mappings agent↔workload (CONCEPT, 0.98)
- AI Agent Mesh —est_instance_de→ data plane pour communication inter-agents (CONCEPT, 0.97)
- STS (Security Token Service) —permet→ émission de JWT short-lived scopés single-hop (CONCEPT, 0.98)
- MCP Gateway —est_instance_de→ policy enforcement point pour invocation outils (CONCEPT, 0.97)
- AI Gateway —permet→ médiation des appels LLM externes avec guardrails (CONCEPT, 0.96)
- AI Gateway —utilise→ AI Guard (CONCEPT, 0.95)
- SPIRE —permet→ workload credentials signés cryptographiquement (CONCEPT, 0.97)
- SPIFFE Verifiable IDs (SVID) —fait_partie_de→ SPIFFE (TECHNOLOGIE, 0.97)
- workloads Uber —utilise→ SPIFFE Verifiable IDs (SVID) (CONCEPT, 0.97)
- SDK Uber —utilise→ STS (Security Token Service) (TECHNOLOGIE, 0.97)
- STS (Security Token Service) —utilise→ Agent Registry (TECHNOLOGIE, 0.97)
- JWT Uber —s_applique_à→ destination single-hop spécifique (claim Audience) (CONCEPT, 0.98)
- JWT Uber —utilise→ TTL court de l'ordre de minutes (short-lived) (CONCEPT, 0.97)
- actor chain —fait_partie_de→ JWT Uber (TECHNOLOGIE, 0.97)
- actor chain —permet→ décisions accès tool-level basées sur historique requête (CONCEPT, 0.97)
- Standardized A2A Client —permet→ STS (Security Token Service) (TECHNOLOGIE, 0.97)
- Standardized A2A Client —permet→ actor chain (CONCEPT, 0.97)
- Standardized A2A Client —utilise→ A2A protocol (TECHNOLOGIE, 0.95)
- Uber Engineering —recommande→ secure path = easiest path (METHODOLOGIE, 0.97)
- architecture Uber —est_basé_sur→ OAuth 2.0 Token Exchange (RFC 8693) (TECHNOLOGIE, 0.95)
- Uber Engineering —converge_avec→ draft-klrc-aiagent-auth-01 (DOCUMENT, 0.96)
- draft-klrc-aiagent-auth-01 —s_applique_à→ authentification et autorisation des agents IA (CONCEPT, 0.94)
- STS (Security Token Service) —mesure→ P99 latency <40 millisecondes (MESURE, 0.98)
- Uber Engineering —utilise→ milliers d'agents internes adoptés (CONCEPT, 0.95)
- Uber Engineering —utilise→ dashboard observabilité temps réel sessions multi-agents (TECHNOLOGIE, 0.94)
- Uber Engineering —recommande→ three-layer framework (Uber) (METHODOLOGIE, 0.95)
- Uber Engineering —utilise→ refactoring phasé pour migrer les agents legacy (METHODOLOGIE, 0.94)
- SPIRE —fait_partie_de→ CNCF (projet graduated) (ORGANISATION, 0.97)
- article Uber —est_instance_de→ première publication référence hyperscaler non-AI-lab sur identity agent (CONCEPT, 0.93)
- identity layer Uber —résout→ gap entre frameworks skills/harness et identity enterprise (CONCEPT, 0.92)
- Uber on-call engineer —utilise→ Oncall Agent (initiation de session) (TECHNOLOGIE, 0.96)
- Oncall Agent —utilise→ Investigation Agent (TECHNOLOGIE, 0.96)
- Investigation Agent —utilise→ MCP Gateway (TECHNOLOGIE, 0.96)
- MCP Gateway —utilise→ actor chain (CONCEPT, 0.97)

---
Canonical: https://www.thekb.eu/es/fiches/uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21/