Article d'ingénierie publié sur le blog d'Uber par six ingénieurs (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) le 21 mai 2026, exposant la doctrine d'identité et de contrôle d'accès des agents IA déployée en production chez Uber pour plusieurs milliers d'agents internes. Thèse-pivot : les modèles d'identité existants (humains + workloads) ne décrivent pas l'agency — « an agent is best defined as an entity that is authorized to act for or in the place of another » — et perdent la provenance à travers les hops d'un workflow agentique. Deux problèmes opérationnels identifiés : (1) « Current Identity Model Doesn't Describe Agency » — la délégation est le mode par défaut, les workflows sont compositionnels (agents qui appellent agents qui appellent tools), le comportement est dynamique (plans évoluent selon résultats intermédiaires) ; (2) « Original Provenance Isn't Effectively Carried Forward Across Agents to Systems » — « Execution context (originating user, intermediate agents) is dropped across agent hops. »Architecture proposée comme extension de la Zero Trust Architecture Uber : Agent Registry (source of truth des mappings agent↔workload) + AI Agent Mesh (data plane inter-agents) + STS (Security Token Service) (émission JWT scopés courts) + MCP Gateway (policy enforcement point pour invocation d'outils) + AI Gateway (médiation appels LLM externes avec guardrails) + SPIRE (provider de workload credentials). Mécanique cryptographique : workloads récupèrent des SVID (SPIFFE Verifiable IDs) signés cryptographiquement depuis SPIRE → SDK demande JWT au STS via identité workload → STS vérifie l'autorisation agent contre Agent Registry → token court (TTL en minutes) émis pour destination single-hop spécifique (claim Audience ciblé). Doctrine pivot : *« Single-hop, short-lived tokens.
Par **Matt Mathew**// Source uber.com ↗/Lecture 2 min/.md/
Six ingénieurs d'Uber (Matt Mathew et al.) publient le 21 mai 2026 sur le blog Uber Engineering un article exposant l'architecture d'identité et de contrôle d'accès pour agents IA déployée en production chez Uber pour des milliers d'agents internes. Thèse-pivot : « an agent is best defined as an entity that is authorized to act for or in the place of another », ce qui rend caduc le modèle d'identité classique humain+workload.
Deux problèmes nommés : (1) « Current Identity Model Doesn't Describe Agency » — la délégation est le mode par défaut, les workflows sont compositionnels, le comportement dynamique ; (2) « Original Provenance Isn't Effectively Carried Forward Across Agents to Systems » — « Execution context is dropped across agent hops » — créant des trous d'audit et empêchant l'application cohérente des politiques d'accès fine-grained.
Single-hop, short-lived tokens. Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes.
— **Matt Mathew** , uber.com
Architecture comme extension de la Zero Trust Architecture Uber : Agent Registry (source of truth agent↔workload) + AI Agent Mesh (data plane inter-agents) + STS (Security Token Service) (émission JWT courts scopés) + MCP Gateway (policy enforcement pour tools) + AI Gateway (médiation LLM + redaction via AI Guard) + SPIRE (provider credentials workload).
Mécanique : workloads récupèrent des SPIFFE Verifiable IDs (SVIDs) cryptographiquement signés depuis SPIRE → SDK demande JWT au STS → STS vérifie l'autorisation contre Agent Registry → token court (TTL en minutes) émis pour destination single-hop spécifique (claim Audience). Doctrine canonique : « Single-hop, short-lived tokens. Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes. »
Walkthrough multi-hop : un on-call engineer user1 → Oncall Agent → Investigation Agent → MCP Gateway. Le JWT final transporte l'actor chain [user1, oncall-agent, investigation-agent] vérifiable — décisions d'accès tool-level basées sur l'historique complet de la requête.
Standardisation : un Standardized A2A (Agent-to-Agent) Client SDK automatise les échanges STS et la propagation de l'actor chain — « the secure path is also the easiest path for developers to implement A2A calls ». Migration phasée des agents legacy.
Métriques production : « P99 latency for the STS Token Exchange API is consistently below 40 milliseconds », milliers d'agents internes adoptés, observabilité temps réel.
Vision long terme — three-layer framework : (1) Identity & Trust Foundation, (2) Dynamic Access Control, (3) Unified Enforcement Plane.
Importance : première publication de référence d'un hyperscaler non-AI-lab qui industrialise la sécurité agent au niveau infrastructure, comblant le gap doctrinal entre les frameworks de skills/harness (productivité) et les questions d'identité enterprise grade (gouvernabilité). Devient une référence canonique pour les architectes plateforme, security engineers, et CISO confrontés au déploiement d'agents en interne.
À retenir
Source. blog Uber Engineering (uber.com/blog), publication officielle. Article du 21 mai 2026 — 2 jours avant la date de consultation 2026-05-23.
Auteurs (six co-auteurs).
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
Équipe Security/Identity infrastructure Uber, responsable de l'architecture agent identity production.
Thèse-pivot épistémologique.« An agent is best defined as an entity that is authorized to act for or in the place of another. » Cette définition pose la délégation comme propriété axiomatique de l'agent — ce qui change tout du modèle d'identité classique (humain ou workload, mais jamais for someone else).
Deux problèmes opérationnels nommés. 1. Current Identity Model Doesn't Describe Agency — les frameworks d'identité existants couvrent les humains et les workloads, mais ne modélisent pas l'acting on behalf of comme mode par défaut. Conséquences :
Delegation is the default mode. — agents work on behalf of others
Workflows are compositional. — agents call other agents, tools, and systems
Behavior is dynamic. — plans evolve based on intermediate results 2. Original Provenance Isn't Effectively Carried Forward Across Agents to Systems — « Execution context (originating user, intermediate agents) is dropped across agent hops. » Conséquences :
Audit trails incomplets.
Application incohérente. des politiques d'accès fine-grained
Pas de capacité à raisonner sur la chaîne complète d'acteurs ayant initié une requête
Architecture — six composants nommés. | Composant | Rôle | |-----------|------| | Agent Registry | Source of truth pour les mappings agent↔workload | | AI Agent Mesh | Data plane pour la communication inter-agents | | STS (Security Token Service) | Émet des JWT courts et scopés (audience-specific) | | MCP Gateway | Policy enforcement point pour l'invocation d'outils (MCP tools) | | AI Gateway | Médiation des appels aux modèles IA externes + guardrails de sécurité (AI Guard pour redaction) | | SPIRE | Provider de credentials workload (extension de l'infra Zero Trust existante Uber) |
Mécanique cryptographique end-to-end. 1. Workloads récupèrent des SPIFFE Verifiable IDs (SVIDs)cryptographiquement signés depuis SPIRE. 2. Le SDK demande des JWT au STS en utilisant l'identité workload (le SVID). 3. Le STS vérifie l'autorisation de l'agent contre l'Agent Registry. 4. Short-lived tokens émis pour une destination single-hop spécifique (claim Audience ciblé, TTL en minutes). 5. Le token transporte la chaîne complète des acteurs participants (l'actor chain).
Doctrine single-hop, short-lived (formule canonique). > « Single-hop, short-lived tokens. Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes. » Conséquences opérationnelles :
Pas de bearer token réutilisable cross-services. — contraste fort avec OAuth classique
Chaque hop demande un nouveau token. — overhead réseau compensé par latency <40ms
Walkthrough multi-hop canonique (exemple article — Figure 4). 1. user1 (on-call engineer) initie une session avec Oncall Agent 2. Oncall Agent contacte le STS, présente son identité SPIRE (Workload-1), demande un JWT pour Investigation Agent 3. Oncall Agent envoie le JWT à Investigation Agent (Workload-2) 4. Investigation Agent effectue un token exchange avec le STS pour obtenir une audience MCP Gateway 5. MCP Gateway reçoit le JWT avec l'actor chain [user1, oncall-agent, investigation-agent] — décision d'accès tool-level basée sur l'historique complet
Standardized A2A Client (SDK).
Implémentation du A2A protocol (Agent-to-Agent, standard émergent référencé sur GitHub).
Automatise. les échanges STS, la construction de l'actor chain, et la propagation cross-hop.
Doctrine d'adoption : « the secure path is also the easiest path for developers to implement A2A calls » — sécurité-par-défaut.
Code montré : classe BaseAgentProtocolClient avec méthodes async (authentication context building + agent calling).
Migration phasée des agents legacy via refactoring.
Standards externes alignés (à connaître). | Standard | Rôle | |----------|------| | SPIFFE / SPIRE | Framework d'identité workload — projet CNCF graduated | | OAuth 2.0 Token Exchange (RFC 8693) | Base conceptuelle du per-hop token exchange | | IETF WIMSE working group | Workload Identity in Multi-System Environments — drafts pour identité agent | | draft-klrc-aiagent-auth-01 | Draft IETF « AI Agent Authentication and Authorization » | | A2A Protocol | Agent-to-Agent standard (référence GitHub) |
Métriques production (à retenir).
*« P99 latency for the STS Token Exchange API is consistently below 40 milliseconds ». *
Milliers d'agents internes. adoptés
Dashboard d'observabilité temps réel traçant les sessions multi-agents
Spikes occasionnels mais consistent <40ms en P99
Features sécurité dérivées.
Per-hop token exchange. — tokens valides uniquement pour une destination spécifique
Actor chain preservation. — visibilité complète du lignage à travers tous les systèmes
Policy enforcement tool-level. — décisions basées sur l'historique complet de la requête
Data redaction via AI Guard. — informations sensibles filtrées au passage par l'AI Gateway
Vision long terme — Three-Layer Framework. (architecture cible) : 1. Identity & Trust Foundation — identité agent vérifiable + delegation chains 2. Dynamic Access Control — permissions context-based + human-in-the-loop options + workflow authorization 3. Unified Enforcement Plane — décisions de politique + observabilité + audit + governance unifiés « Long-term vision is a cohesive architecture where identity, risk, and policy work together seamlessly. »
Pourquoi cet article est important (positionnement).
Première publication de référence d'un hyperscaler non-AI-lab. (Uber = logistique/mobilité) qui industrialise la sécurité agent au niveau infrastructure.
Comble le gap doctrinal. entre les frameworks de skills/harness (Vincent Superpowers, Lattice, PROJ-AI, Wescale Usine Logicielle Augmentée) qui parlent de productivité, et les questions d'identité enterprise grade qui n'avaient pas de doctrine publique.
Aligne sur les standards émergents. (SPIFFE/SPIRE déjà adopté, IETF WIMSE en cours) plutôt que d'inventer un protocole propriétaire — pattern cathedral and bazaar classique d'Uber Eng.
Devient une référence pour les RSSI / CISO. confrontés au déploiement d'agents en interne.
Articulation dossier veille.
Famille immédiate (infrastructure agent enterprise).
Stripe Minions (Gray 2026-02-09 et 2026-02-19). — fiche [gray-stripe-minions-coding-agents-part1-2026-02-09] et [gray-stripe-minions-coding-agents-part2-2026-02-19] : 1000-1300+ PRs/semaine autonomes, Toolshed ~500 MCP tools, devboxes isolés. Stripe et Uber convergent sur l'industrialisation des agents internes — Stripe focus sur les coding agents et le toolshed MCP, Uber focus sur l'identity layer qui rend ces déploiements gouvernables.
Levie *Building for trillions of agents. (fiche [levie-building-trillions-agents-software-2026-03-07]) — Aaron Levie (Box) : « logiciel API-first pour agents, infrastructure agentique, modèles économiques »*. Levie prédit ; Uber livre.
Thoughtworks AI/works™. (fiche [thoughtworks-aiworks-agentic-development-platform-2026-05-12]) — Control Plane avec « active guardrails + end-to-end lineage ». Uber est l'implémentation production de ce que Thoughtworks vend comme produit.
Cloudflare Markdown for Agents. (fiche [martinho-allen-cloudflare-markdown-for-agents-2026-02-12]) — conversion HTML→Markdown en edge. Cloudflare et Uber adressent deux dimensions distinctes de l'infra agent : data shape (Cloudflare) vs identity (Uber).
Famille harness / agent architecture.
Trivedy *Anatomy of an Agent Harness. * (fiche [trivedy-langchain-anatomy-agent-harness-2026-03-10]) — Agent=Modèle+Harnais. Uber complète : Harnais inclut désormais une identity layer dédiée, hop-aware.
Osmani *Agent Harness Engineering. * (fiche [osmani-agent-harness-engineering-2026-04-19]) — Uber est un exemple opérationnel de ce que Osmani théorise.
Seale *Semantic Agent: (Model+Harness) + (Ontology+Data). (fiche [seale-semantic-agent-model-harness-ontology-data-2026-04-17]) — Uber ajoute une troisième dimension : (Identity + Provenance)*.
Famille zero trust / sécurité plateforme.
Sierra AI-native interview. (fiches [sierra-ai-native-interview-iyengar-asemanfar-wang-2026-04-22] et [taylor-sierra-ai-native-interview-engineering-hiring-2026-04-20]) — recrute pour les forces. Profil ingénieur Uber visé : Plan/Build/Review avec compétence sécurité agent.
Famille souveraineté / défense / risque.
Mensch / Mistral devant commission Assemblée nationale. (fiche [mensch-mistral-commission-enquete-vulnerabilites-numeriques-souverainete-ia-2026-05-13]) — « sécurité économique » + « cyber : capacités offensives linéaires ». Uber montre comment sécuriser opérationnellement ; Mensch montre pourquoi c'est stratégique pour la souveraineté.
AISI UK GPT-5.5 cyber capabilities. (fiche [aisi-uk-gpt55-cyber-capabilities-evaluation-2026-04-30]) — modèles capables de découvrir vulnérabilités. La défense passe par des architectures comme celle d'Uber.
Sun *Permanent Underclass. (fiche [sun-nyt-silicon-valley-permanent-underclass-2026-04-30]) — déplacement travail → capital. Uber illustre la couche d'infrastructure « capital »* qui rend possible l'automatisation à l'échelle.
Points faibles / questions ouvertes.
Pas de détails sur le coût. de l'architecture (combien de serveurs STS, combien de QPS, combien d'auteurs JWT/jour).
Pas de chiffres sur les pertes de productivité développeurs. dues à la migration des agents legacy (combien de PRs de refactoring ? quelle durée totale ?).
Position vs. solutions vendor. (Auth0, Okta, ForgeRock) non discutée — Uber a choisi de construire en interne sur SPIRE plutôt que d'acheter, mais sans expliciter le raisonnement build-vs-buy.
Pas de discussion sur les failure modes. — que se passe-t-il si le STS est en panne ? Quel mode dégradé ? Quel circuit breaker ?
Privacy / GDPR / données personnelles. dans l'actor chain — pas évoqué (un on-call engineer peut être nommément traçable dans tous les hops).
Pas de discussion. sur les attaques par confusion de delegation chain ou par injection d'un faux maillon.
L'A2A protocol. est cité comme dépendance externe — mais le draft IETF n'est pas encore un standard. Risque : adoption précoce sur un protocole qui peut évoluer.
Vocabulaire uber-eng à retenir.agency (définition 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 as policy enforcement point, AI gateway as redaction layer, three-layer framework (identity / access / enforcement).
À mobiliser pour.
Présentations dirigeants CISO/RSSI sur la sécurité des agents en entreprise (référence canonique).
Doctrine d'architecture pour les clients industriels qui déploient des agents internes (≥ 100 agents en flotte).
Comparaison build-vs-buy pour solutions IAM agentiques.
Argumentaire en faveur de SPIFFE/SPIRE comme standard de facto pour l'identité workload (CNCF graduated + adopté par Uber).
Référence dans tout document de plan plateforme agent enterprise (control plane, identity layer, observability).
Convergence avec la doctrine Usine Logicielle Augmentée Wescale et AI/works™ Thoughtworks sur la nécessité d'un « control plane » mature.