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.
Von **Matt Mathew**// Quelle uber.com ↗/Lesezeit 2 min/.md// Automatisch geprüfte Übersetzung
#Uber Engineering#KI-Agentenidentität#Agentenidentitätskrise#Agency-Definition#Agent als Delegierter#Multi-Hop-Workflow#Akteurskette#Provenienzerhalt
Zusammenfassung
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.
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.
Kernpunkte
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:
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.
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.
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."