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.
#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
Resumen
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.
Puntos clave
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.
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.
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.