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

## Veille

Engineering-Artikel, veröffentlicht im **Uber** Engineering-Blog von sechs Ingenieuren (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) am **21. Mai 2026**, der die bei Uber für mehrere Tausend interne Agenten produktiv eingesetzte **Doktrin für Agentenidentität und Zugriffskontrolle bei KI** darlegt. **Kernthese**: Bestehende Identitätsmodelle (Menschen + Workloads) scheitern daran, **Handlungsvollmacht (Agency)** zu beschreiben — *"an agent is best defined as an entity that is authorized to act for or in the place of another"* — und verlieren die **Provenienz** über die Hops eines agentischen Workflows hinweg. **Zwei identifizierte operative Probleme**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — Delegation ist der Standardmodus, Workflows sind kompositional (Agenten rufen Agenten auf, die Tools aufrufen), das Verhalten ist dynamisch (Pläne entwickeln sich basierend auf Zwischenergebnissen); (2) ***"Original Provenance Isn't Effectively Carried Forward Across Agents to Systems"*** — *"Execution context (originating user, intermediate agents) is dropped across agent hops."* **Vorgeschlagene Architektur** als Erweiterung von Ubers Zero-Trust-Architektur: **Agent Registry** (Source of Truth für Agent↔Workload-Zuordnungen) + **AI Agent Mesh** (Datenebene zwischen Agenten) + **STS (Security Token Service)** (Ausstellung kurz begrenzter JWTs) + **MCP Gateway** (Policy-Enforcement-Point für Tool-Aufrufe) + **AI Gateway** (Vermittlung externer LLM-Aufrufe mit Guardrails) + **SPIRE** (Anbieter von Workload-Credentials). **Kryptografische Mechanik**: Workloads beziehen kryptografisch signierte **SVIDs (SPIFFE Verifiable IDs)** von SPIRE → das SDK fordert über die Workload-Identität ein JWT vom STS an → der STS prüft die Autorisierung des Agenten gegen die Agent Registry → ein kurzlebiges Token (TTL in der Größenordnung von Minuten) wird für ein **spezifisches Single-Hop-Ziel** ausgestellt (gezielter `Audience`-Claim). **Kerndoktrin**: ***"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."*** **Erhalt der Akteurskette**: ein Multi-Hop-Beispiel mit Bereitschaftsingenieur `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway; das finale JWT trägt eine verifizierbare **Akteurskette `[user1, oncall-agent, investigation-agent]`**, die Zugriffsentscheidungen auf Tool-Ebene auf Basis der **vollständigen Historie der Anfrage** ermöglicht. **Standardisierung**: ein **Standardized A2A (Agent-to-Agent) Client**, der STS-Austausche und die Propagierung der Akteurskette automatisiert — *"the secure path is also the easiest path for developers to implement A2A calls"* — mit schrittweiser Migration von Legacy-Agenten. **Produktionskennzahlen**: ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds,"*** Tausende interner Agenten im Einsatz, ein Echtzeit-Observability-Dashboard, das Multi-Agenten-Sitzungen nachverfolgt. **Langfristvision — dreischichtiges Framework**: (1) Identity & Trust Foundation (verifizierbare Agentenidentität + Delegationsketten), (2) Dynamic Access Control (kontextbasierte Berechtigungen + Human-in-the-Loop), (3) Unified Enforcement Plane (zentralisierte, beobachtbare Policy). **Abstimmung mit Standards**: die IETF-**WIMSE**-Arbeitsgruppe + der Entwurf `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, konzeptionell gestützt auf **OAuth 2.0 Token Exchange (RFC 8693)** und **SPIFFE/SPIRE** (CNCF graduated). Die erste Referenzpublikation eines Hyperscalers außerhalb der KI-Labs (Logistik/Mobilität), der Agentensicherheit auf Infrastrukturebene industrialisiert und die doktrinäre Lücke zwischen Skills-/Harness-Frameworks (Vincent, Lattice, PROJ-AI) und Fragen der Unternehmensidentität schließt.

## 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, KI-Agentenidentität, Agentenidentitätskrise, Agency-Definition, Agent als Delegierter, Multi-Hop-Workflow, Akteurskette, Provenienzerhalt, Zero-Trust-Architektur, Agent Registry, AI Agent Mesh, Security Token Service STS, MCP Gateway, AI Gateway, MCP-Tool-Aufruf, SPIRE-Workload-Identität, SPIFFE Verifiable IDs (SVID), JWT kurzlebige Tokens, Audience-Claim, Single-Hop-Tokens, Token-Exchange pro Hop, OAuth 2.0 Token Exchange (RFC 8693), A2A-Protokoll Agent-to-Agent, Standardized A2A Client, BaseAgentProtocolClient, IETF WIMSE working group, draft-klrc-aiagent-auth-01, AI Agent Authentication and Authorization, Bereitschaftsingenieur-Agent, Oncall Agent, Investigation Agent, Monitoring Agent, Audit-Trail, feingranulare Zugriffsrichtlinie, Policy-Enforcement-Point, Datenredaktion AI Guard, Secure-by-Default, P99-Latenz 40 ms, Identity & Trust Foundation, Dynamic Access Control, Unified Enforcement Plane, dreischichtiges Framework, Agenten-Observability, Audit-Governance, Agenten-Provenienz, Delegationskette, kryptografisch signierte Workload-Credentials, SPIFFE CNCF graduated, Agent-zu-Workload-Zuordnung, interne Agenten bei Uber, Tausende Agenten in Produktion, Sicherheit der Agenteninfrastruktur, Agent Mesh, sicherer Pfad = einfachster Pfad, Migration von Legacy-Agenten schrittweises Refactoring, Grenzen des Identitätsmodells, Policy nachgelagerter Systeme, kontextuelle Zuordnung

## 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

**Profil**: Unternehmens-technisch-erklärender Engineering-Artikel im Register eines *Hyperscaler-Engineering-Blogs*. Kanonisches Uber-Engineering-Format: didaktische Darlegung einer produktiv eingesetzten Lösung, *Problem-first*-Erzählweise (zwei identifizierte und benannte Probleme), Architekturdiagramme (Abbildungen 1–4 erwähnt), ein konkretes Multi-Hop-Durchlaufbeispiel, Validierungskennzahlen, Langfristvision. Kein verkapptes Marketing, keine Übertreibung — ein Register im Stil eines **operativen Engineering-Memos**, gerichtet an Sicherheitsingenieure, Plattformarchitekten und Tech Leads.

**Stil**: Kollektive Ingenieur-Architekten-Stimme (sechs Mitautoren), im **präzisen angelsächsisch-korporativen** Register, das für Uber Eng charakteristisch ist:
1. **Kurze axiomatische Definitionen** — *"An agent is best defined as an entity that is authorized to act for or in the place of another."* Eine 18 Wörter umfassende Definition, die den gesamten restlichen Text strukturiert. Propositionaler Modus.
2. **Orthogonale Aufzählung von Constraints** — *"Delegation is the default mode... Workflows are compositional... Behavior is dynamic"* — drei sich gegenseitig ausschließende, gemeinsam erschöpfende Eigenschaften, die die Notwendigkeit eines neuen Identitätsmodells begründen.
3. **Muster Problem → Komponente → Mechanismus → Beispiel → Kennzahl** — jede Ebene wird durch das Problem eingeführt, das sie löst, dann durch ihre Rolle spezifiziert, dann durch ihre Mechanik (Tokens, Claims, Audience) detailliert, dann durch einen Durchlauf konkretisiert, dann durch eine Messung validiert. Kontrollierte *Zoom-in-Zoom-out*-Pädagogik.
4. **Lexikalische Präzision** — *"short-lived tokens," "single-hop," "specific Audience claim," "time-to-live in the order of minutes," "cryptographically signed"* — ein an präzisen Fachbegriffen dichtes Vokabular, ohne Umschreibung.

**Metaphern und Schlüsselformeln**:
- ***"An agent is best defined as an entity that is authorized to act for or in the place of another"*** — Ubers **Gründungsdefinition von Agency**, die Delegation als axiomatische Eigenschaft des Agenten setzt.
- ***"Execution context (originating user, intermediate agents) is dropped across agent hops"*** — eine kurze, operative Framing-Formel für das Provenienzproblem.
- ***"Single-hop, short-lived tokens"*** — der Doktrin-Slogan der Lösung, das funktionale Äquivalent des klassischen Zero-Trust-*"Least Privilege"*, angepasst an das agentische Regime.
- ***"The secure path is also the easiest path for developers to implement A2A calls"*** — die Adoptionsdoktrin: Sicherheit standardmäßig ohne Reibung für Entwickler (eine direkte Parallele zur klassischen SRE-*"Paved Road"*).
- ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds"*** — die Kennzahl-Formel, die die Debatte *"ist diese Architektur im Uber-Maßstab tragfähig?"* entscheidet — Antwort: ja, mit Reserven.

**Epistemische Position**: Die Autoren sprechen als **Produktionsbetreiber** (Tausende interner Agenten, gemessenes P99, ein bestehendes Observability-Dashboard). Sie theoretisieren nicht — sie **dokumentieren eine ausgelieferte Lösung**. Der Ton ist selbstbewusst, aber nicht triumphalistisch, mit expliziter Anerkennung, dass die Arbeit weitergeht (*"long-term vision,"* *"phased refactoring"* von Legacy-Agenten).

**Autorität aufgebaut durch**: (a) **produktive Traktion** (konkrete Zahlen — P99 <40 ms, Tausende Agenten), (b) **architektonische Tiefe** (sechs benannte Komponenten, offengelegte kryptografische Mechanik), (c) **Abstimmung mit Standards** (SPIFFE/SPIRE CNCF graduated, RFC 8693, IETF WIMSE), (d) **Teamzusammensetzung** (sechs Mitautoren des Beitrags — ein Signal, dass es sich um eine ausgereifte, funktionsübergreifende Plattform handelt, nicht um einen POC), (e) **Timing** (veröffentlicht, während die Branchendiskussion zur Agentensicherheit noch im Entstehen ist — Uber steckt eine Referenzposition ab).

**Zielgruppe und erwartete Wirkung**: Ein Artikel, kalibriert für **Plattformarchitekten und Sicherheitsingenieure** in großen Unternehmen, die beginnen, KI-Agenten intern einzusetzen. Sekundäre Zielgruppe: die CNCF-/SPIFFE-Community, Mitwirkende an den IETF-WIMSE-Entwürfen, MCP-/Gateway-Anbieter. Erwartete Wirkung: eine **kanonische Referenz** in der agentischen Sicherheitsdoktrin 2026 zu werden, neben Anthropics MCP-Publikationen, Stripes Toolshed und Cloudflares Edge-Arbeit.

## Pense-betes

- **Quelle**: Uber-Engineering-Blog (uber.com/blog), offizielle Publikation. Artikel datiert auf den **21. Mai 2026** — 2 Tage vor dem Abrufdatum 2026-05-23.
- **Autoren (sechs Mitautoren)**:
- **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
- Uber-Team für Security-/Identity-Infrastruktur, verantwortlich für die produktive Agentenidentitäts-Architektur.
- **Erkenntnistheoretische Kernthese**: ***"An agent is best defined as an entity that is authorized to act for or in the place of another."*** Diese Definition setzt **Delegation** als axiomatische Eigenschaft des Agenten voraus — was das klassische Identitätsmodell (Mensch oder Workload, aber nie *für jemand anderen*) auf den Kopf stellt.
- **Zwei benannte operative Probleme**: 1. **Current Identity Model Doesn't Describe Agency** — bestehende Identitäts-Frameworks decken Menschen und Workloads ab, modellieren aber **das Handeln im Auftrag von** nicht als Standardmodus. Konsequenzen:
- **Delegation ist der Standardmodus** — Agenten arbeiten im Auftrag anderer
- **Workflows sind kompositional** — Agenten rufen andere Agenten, Tools und Systeme auf
- **Das Verhalten ist dynamisch** — Pläne entwickeln sich basierend auf Zwischenergebnissen 2. **Original Provenance Isn't Effectively Carried Forward Across Agents to Systems** — *"Execution context (originating user, intermediate agents) is dropped across agent hops."* Konsequenzen:
- **Unvollständige Audit-Trails**
- **Inkonsistente Durchsetzung** feingranularer Zugriffsrichtlinien
- Keine Möglichkeit, über die vollständige Kette der Akteure, die eine Anfrage ausgelöst haben, Rückschlüsse zu ziehen
- **Architektur — sechs benannte Komponenten**: | Komponente | Rolle | |-----------|------| | **Agent Registry** | Source of Truth für Agent↔Workload-Zuordnungen | | **AI Agent Mesh** | Datenebene für die Kommunikation zwischen Agenten | | **STS (Security Token Service)** | Stellt kurze, begrenzte (audience-spezifische) JWTs aus | | **MCP Gateway** | Policy-Enforcement-Point für Tool-Aufrufe (MCP-Tools) | | **AI Gateway** | Vermittlung von Aufrufen externer KI-Modelle + Security-Guardrails (AI Guard zur Redaktion) | | **SPIRE** | Anbieter von Workload-Credentials (Erweiterung von Ubers bestehender Zero-Trust-Infrastruktur) |
- **End-to-End-kryptografische Mechanik**: 1. Workloads beziehen **kryptografisch signierte SPIFFE Verifiable IDs (SVIDs)** von SPIRE. 2. Das SDK fordert über die Workload-Identität (die SVID) **JWTs** vom STS an. 3. Der STS **prüft die Autorisierung des Agenten** gegen die Agent Registry. 4. **Kurzlebige Tokens** werden für ein **spezifisches Single-Hop-Ziel** ausgestellt (gezielter `Audience`-Claim, TTL **in der Größenordnung von Minuten**). 5. Das Token trägt die **vollständige Kette der beteiligten Akteure** (die Akteurskette).
- **"Single-hop, short-lived"-Doktrin (kanonische Formel)**: > *"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."* Operative Konsequenzen:
- **Token-Diebstahl = minimaler Blast-Radius** (TTL in Minuten, einzelne Audience)
- **Kein wiederverwendbares dienstübergreifendes Bearer-Token** — deutlicher Kontrast zum klassischen OAuth
- **Jeder Hop fordert ein neues Token an** — Netzwerk-Overhead durch eine Latenz von <40 ms ausgeglichen
- **Kanonischer Multi-Hop-Durchlauf (Artikelbeispiel — Abbildung 4)**: 1. **user1** (Bereitschaftsingenieur) startet eine Sitzung mit dem **Oncall Agent** 2. Der **Oncall Agent** kontaktiert den STS, weist seine SPIRE-Identität (Workload-1) nach und fordert ein JWT für den **Investigation Agent** an 3. Der Oncall Agent sendet das JWT an den **Investigation Agent** (Workload-2) 4. Der **Investigation Agent** führt einen **Token-Exchange** mit dem STS durch, um eine Audience für das **MCP Gateway** zu erhalten 5. Das **MCP Gateway** erhält das JWT mit der **Akteurskette `[user1, oncall-agent, investigation-agent]`** — Zugriffsentscheidung auf Tool-Ebene basierend auf der vollständigen Historie
- **Standardized A2A Client (SDK)**:
- Implementierung des **A2A-Protokolls** (Agent-to-Agent, ein entstehender, auf GitHub referenzierter Standard).
- **Automatisiert** STS-Austausche, den Aufbau der Akteurskette und die hopübergreifende Propagierung.
- Adoptionsdoktrin: ***"the secure path is also the easiest path for developers to implement A2A calls"*** — secure by default.
- Gezeigter Code: eine Klasse `BaseAgentProtocolClient` mit asynchronen Methoden (Aufbau des Authentifizierungskontexts + Agentenaufruf).
- Schrittweise Migration von Legacy-Agenten per Refactoring.
- **Abgestimmte externe Standards (wissenswert)**: | Standard | Rolle | |----------|------| | **SPIFFE / SPIRE** | Framework für Workload-Identität — ein **CNCF graduated** Projekt | | **OAuth 2.0 Token Exchange (RFC 8693)** | Konzeptionelle Grundlage für den Token-Exchange pro Hop | | **IETF WIMSE working group** | Workload Identity in Multi-System Environments — Entwürfe zur Agentenidentität | | **draft-klrc-aiagent-auth-01** | IETF-Entwurf *"AI Agent Authentication and Authorization"* | | **A2A Protocol** | Agent-to-Agent-Standard (GitHub-Referenz) |
- **Produktionskennzahlen (wichtigste Erkenntnisse)**:
- ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds"***
- **Tausende interner Agenten** im Einsatz
- Echtzeit-Observability-Dashboard zur Nachverfolgung von Multi-Agenten-Sitzungen
- Gelegentliche Spitzen, aber durchgängig <40 ms bei P99
- **Abgeleitete Sicherheitsmerkmale**:
- **Token-Exchange pro Hop** — Tokens gelten nur für ein spezifisches Ziel
- **Erhalt der Akteurskette** — vollständige Sichtbarkeit der Herkunft über alle Systeme hinweg
- **Policy-Enforcement auf Tool-Ebene** — Entscheidungen basierend auf der vollständigen Historie der Anfrage
- **Datenredaktion via AI Guard** — sensible Informationen werden beim Durchlauf durch das AI Gateway gefiltert
- **Langfristvision — Three-Layer Framework** (Zielarchitektur): 1. **Identity & Trust Foundation** — verifizierbare Agentenidentität + Delegationsketten 2. **Dynamic Access Control** — kontextbasierte Berechtigungen + Human-in-the-Loop-Optionen + Workflow-Autorisierung 3. **Unified Enforcement Plane** — einheitliche Policy-Entscheidungen + Observability + Audit + Governance ***"Long-term vision is a cohesive architecture where identity, risk, and policy work together seamlessly."***
- **Warum dieser Artikel relevant ist (Positionierung)**:
- **Erste Referenzpublikation eines Hyperscalers außerhalb der KI-Labs** (Uber = Logistik/Mobilität), der Agentensicherheit auf Infrastrukturebene industrialisiert.
- **Schließt die doktrinäre Lücke** zwischen Skills-/Harness-Frameworks (Vincent *Superpowers*, Lattice, PROJ-AI, Wescale Usine Logicielle Augmentée), die über Produktivität sprechen, und Fragen der **Unternehmensidentität**, für die bislang eine öffentliche Doktrin fehlte.
- **Orientiert sich an entstehenden Standards** (SPIFFE/SPIRE bereits übernommen, IETF WIMSE in Arbeit), statt ein proprietäres Protokoll zu erfinden — das klassische *Cathedral-and-Bazaar*-Muster von Uber Eng.
- **Wird zur Referenz für CISOs**, die vor dem internen Einsatz von Agenten stehen.
- **Einordnung im Dossier**:
- **Unmittelbare Familie (Unternehmens-Agenteninfrastruktur)**:
- **Stripe Minions (Gray 2026-02-09 und 2026-02-19)** — Fiche [gray-stripe-minions-coding-agents-part1-2026-02-09] und [gray-stripe-minions-coding-agents-part2-2026-02-19]: 1000–1300+ autonome PRs/Woche, **Toolshed mit ~500 MCP-Tools**, isolierte Devboxes. Stripe und Uber konvergieren bei der **Industrialisierung interner Agenten** — Stripe fokussiert sich auf Coding-Agenten und den MCP-Toolshed, Uber auf die **Identitätsschicht**, die diese Einsätze governance-fähig macht.
- **Levie *Building for trillions of agents*** (Fiche [levie-building-trillions-agents-software-2026-03-07]) — Aaron Levie (Box): *"API-first software for agents, agentic infrastructure, business models."* Levie prognostiziert; Uber **liefert**.
- **Thoughtworks AI/works™** (Fiche [thoughtworks-aiworks-agentic-development-platform-2026-05-12]) — eine Control Plane mit *"active guardrails + end-to-end lineage."* Uber ist die **produktive Umsetzung** dessen, was Thoughtworks als Produkt verkauft.
- **MCP-/Tools-Familie**:
- **Anthropic 2026 Agentic Coding Trends Report** (Fiche [anthropic-agentic-coding-trends-report-2026-02]) — Demokratisierung und Aufsicht.
- **Cloudflare Markdown for Agents** (Fiche [martinho-allen-cloudflare-markdown-for-agents-2026-02-12]) — HTML-zu-Markdown-Konvertierung am Edge. Cloudflare und Uber adressieren zwei unterschiedliche Dimensionen der Agenteninfrastruktur: Datenform (Cloudflare) vs. Identität (Uber).
- **Harness-/Agentenarchitektur-Familie**:
- **Trivedy *Anatomy of an Agent Harness*** (Fiche [trivedy-langchain-anatomy-agent-harness-2026-03-10]) — Agent = Model + Harness. Uber ergänzt: Der Harness umfasst nun eine **dedizierte, hop-bewusste Identitätsschicht**.
- **Osmani *Agent Harness Engineering*** (Fiche [osmani-agent-harness-engineering-2026-04-19]) — Uber ist ein operatives Beispiel dessen, was Osmani theoretisiert.
- **Seale *Semantic Agent: (Model+Harness) + (Ontology+Data)*** (Fiche [seale-semantic-agent-model-harness-ontology-data-2026-04-17]) — Uber ergänzt eine dritte Dimension: *(Identity + Provenance)*.
- **Zero-Trust-/Plattform-Security-Familie**:
- **Sierra AI-native interview** (Fiches [sierra-ai-native-interview-iyengar-asemanfar-wang-2026-04-22] und [taylor-sierra-ai-native-interview-engineering-hiring-2026-04-20]) — Einstellung für die Kräfte. Ubers Zielprofil für Ingenieure: Plan/Build/Review mit Kompetenzen in Agentensicherheit.
- **Souveränitäts-/Verteidigungs-/Risiko-Familie**:
- **Mensch / Mistral vor dem Untersuchungsausschuss der Assemblée nationale** (Fiche [mensch-mistral-commission-enquete-vulnerabilites-numeriques-souverainete-ia-2026-05-13]) — *"economic security"* + *"cyber: linear offensive capabilities."* Uber zeigt **wie** man operativ absichert; Mensch zeigt **warum** dies strategisch für die Souveränität wichtig ist.
- **AISI UK GPT-5.5 Cyber-Fähigkeiten** (Fiche [aisi-uk-gpt55-cyber-capabilities-evaluation-2026-04-30]) — Modelle, die in der Lage sind, Schwachstellen zu entdecken. Verteidigung läuft über Architekturen wie die von Uber.
- **Sun *Permanent Underclass*** (Fiche [sun-nyt-silicon-valley-permanent-underclass-2026-04-30]) — Verschiebung von Arbeit zu Kapital. Uber illustriert die *"Kapital"*-Infrastrukturschicht, die Automatisierung im großen Maßstab ermöglicht.
- **Schwachpunkte / offene Fragen**:
- **Keine Details zu den Kosten** der Architektur (wie viele STS-Server, wie viel QPS, wie viele JWTs pro Tag ausgestellt).
- **Keine Zahlen zu Produktivitätsverlusten der Entwickler** durch die Migration von Legacy-Agenten (wie viele Refactoring-PRs? Gesamtdauer?).
- **Positionierung gegenüber Anbieterlösungen** (Auth0, Okta, ForgeRock) nicht diskutiert — Uber entschied sich für den Eigenbau auf Basis von SPIRE statt für den Kauf, ohne die Build-vs-Buy-Begründung darzulegen.
- **Keine Diskussion der Fehlermodi** — Was passiert, wenn der STS ausfällt? Welcher Degraded Mode? Welcher Circuit Breaker?
- **Privacy / DSGVO / personenbezogene Daten** in der Akteurskette — nicht behandelt (ein Bereitschaftsingenieur kann über alle Hops hinweg identifizierbar nachverfolgbar sein).
- **Keine Diskussion** von Delegation-Chain-Confusion-Angriffen oder Fake-Link-Injection.
- **Das A2A-Protokoll** wird als externe Abhängigkeit angeführt — der IETF-Entwurf ist jedoch noch kein Standard. Risiko: frühe Übernahme eines Protokolls, das sich noch weiterentwickeln kann.
- **Zu merkendes Uber-Eng-Vokabular**: *agency (Ubers Definition)*, *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)*.
- **Nützlich für**:
- CISO-Führungspräsentationen zur Unternehmens-Agentensicherheit (kanonische Referenz).
- Architekturdoktrin für Industriekunden, die interne Agenten einsetzen (≥100 Agenten in der Flotte).
- Build-vs-Buy-Vergleich für agentische IAM-Lösungen.
- Argument zugunsten von SPIFFE/SPIRE als **De-facto-Standard** für Workload-Identität (CNCF graduated + von Uber übernommen).
- Referenz in jedem Planungsdokument für Enterprise-Agentenplattformen (Control Plane, Identitätsschicht, Observability).
- Konvergenz mit Wescales Doktrin **Usine Logicielle Augmentée** und Thoughtworks' **AI/works™** hinsichtlich der Notwendigkeit einer ausgereiften *"Control Plane."*

## RésuméDe400mots

Sechs **Uber**-Ingenieure (Matt Mathew et al.) veröffentlichten am 21. Mai 2026 im Uber-Engineering-Blog einen Artikel, der die bei Uber für **Tausende interne Agenten** produktiv eingesetzte **Architektur für Agentenidentität und Zugriffskontrolle** darlegt. **Kernthese**: ***"an agent is best defined as an entity that is authorized to act for or in the place of another,"*** wodurch das klassische Identitätsmodell aus Mensch + Workload obsolet wird.

**Zwei benannte Probleme**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — Delegation ist der Standardmodus, Workflows sind kompositional, das Verhalten ist dynamisch; (2) ***"Original Provenance Isn't Effectively Carried Forward Across Agents to Systems"*** — *"Execution context is dropped across agent hops"* — was Audit-Lücken erzeugt und die konsistente Durchsetzung feingranularer Zugriffsrichtlinien verhindert.

**Architektur** als Erweiterung von Ubers Zero-Trust-Architektur: **Agent Registry** (Source of Truth für Agent↔Workload) + **AI Agent Mesh** (Datenebene zwischen Agenten) + **STS (Security Token Service)** (Ausstellung kurz begrenzter JWTs) + **MCP Gateway** (Policy-Enforcement für Tools) + **AI Gateway** (LLM-Vermittlung + Redaktion via AI Guard) + **SPIRE** (Anbieter von Workload-Credentials).

**Mechanik**: Workloads beziehen kryptografisch signierte **SPIFFE Verifiable IDs (SVIDs)** von SPIRE → das SDK fordert ein JWT vom STS an → der STS prüft die Autorisierung gegen die Agent Registry → ein **kurzlebiges Token (TTL in der Größenordnung von Minuten) wird für ein spezifisches Single-Hop-Ziel ausgestellt** (`Audience`-Claim). **Kanonische Doktrin**: ***"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."***

**Multi-Hop-Durchlauf**: ein Bereitschaftsingenieur `user1` → Oncall Agent → Investigation Agent → MCP Gateway. Das finale JWT trägt eine verifizierbare **Akteurskette `[user1, oncall-agent, investigation-agent]`** — Zugriffsentscheidungen auf Tool-Ebene basierend auf der **vollständigen Historie** der Anfrage.

**Standardisierung**: ein **Standardized A2A (Agent-to-Agent) Client**-SDK automatisiert STS-Austausche und die Propagierung der Akteurskette — ***"the secure path is also the easiest path for developers to implement A2A calls."*** Schrittweise Migration von Legacy-Agenten.

**Produktionskennzahlen**: ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds,"*** Tausende interner Agenten im Einsatz, Echtzeit-Observability.

**Langfristvision — dreischichtiges Framework**: (1) Identity & Trust Foundation, (2) Dynamic Access Control, (3) Unified Enforcement Plane.

**Externe Standards**: SPIFFE/SPIRE (CNCF graduated), OAuth 2.0 Token Exchange (RFC 8693), IETF-WIMSE-Arbeitsgruppe, Entwurf `draft-klrc-aiagent-auth-01`, A2A-Protokoll.

**Bedeutung**: die erste Referenzpublikation eines Hyperscalers außerhalb der KI-Labs, der **Agentensicherheit auf Infrastrukturebene** industrialisiert und die doktrinäre Lücke zwischen Skills-/Harness-Frameworks (Produktivität) und Fragen der **Unternehmensidentität** (Governance-Fähigkeit) schließt. Wird zur kanonischen Referenz für Plattformarchitekten, Sicherheitsingenieure und CISOs, die vor dem internen Einsatz von Agenten stehen.

## 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/de/fiches/uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21/