Solving the Identity Crisis for AI Agents

Kernpunkte

1. Quelle. Uber Engineering Blog (uber.com/blog), offizielle Publikation. Artikel vom 21. Mai 2026 — 2 Tage vor dem Konsultationsdatum 2026-05-23.
2. Autoren (sechs Co-Autoren).
3. Matt Mathew. — Sr Staff Engineer
4. Prasad Borole. — Staff Software Engineer
5. Meng Huang. — Engineering Manager
6. Sergey Burykin. — Sr Software Engineer
7. Gaurav Goel. — Software Engineer II
8. Bayard Walsh. — Software Engineer I
9. Uber Security/Identity Infrastructure Team, verantwortlich für die produktive Architektur der Agentenidentität.
10. Zentrale epistemische These. « Ein Agent lässt sich am besten als eine Entität definieren, die dazu befugt ist, für eine andere oder an deren Stelle zu handeln. » Diese Definition setzt Delegation als axiomatische Eigenschaft des Agenten voraus — was das klassische Identitätsmodell (Mensch oder Workload, aber niemals für jemand anderen) grundlegend verändert.
11. Zwei benannte operative Probleme. 1. Das aktuelle Identitätsmodell bildet Agency nicht ab — bestehende Identitäts-Frameworks decken Menschen und Workloads ab, modellieren aber das Handeln im Auftrag nicht als Standardmodus. Konsequenzen:
12. Delegation ist der Standardmodus. — Agenten handeln im Auftrag anderer
13. Workflows sind kompositional. — Agenten rufen andere Agenten, Tools und Systeme auf
14. Das Verhalten ist dynamisch. — Pläne entwickeln sich anhand von Zwischenergebnissen weiter 2. Die ursprüngliche Provenienz wird nicht wirksam über Agenten hinweg an Systeme weitergereicht — « Der Ausführungskontext (ursprünglicher Nutzer, zwischengeschaltete Agenten) geht über die Agenten-Hops hinweg verloren. » Konsequenzen:
15. Unvollständige Audit-Trails.
16. Inkonsistente Durchsetzung. granularer Zugriffsrichtlinien
17. Keine Möglichkeit, die vollständige Kette der Akteure nachzuvollziehen, die eine Anfrage initiiert haben
18. Architektur — sechs benannte Komponenten. | Komponente | Rolle | |-----------|------| | Agent Registry | Source of Truth für Agent↔Workload-Zuordnungen | | AI Agent Mesh | Data Plane für die Kommunikation zwischen Agenten | | STS (Security Token Service) | Stellt kurzlebige, scope-begrenzte (audience-spezifische) JWTs aus | | MCP Gateway | Policy-Enforcement-Punkt für Tool-Aufrufe (MCP-Tools) | | AI Gateway | Vermittlung von Aufrufen an externe KI-Modelle + Sicherheits-Guardrails (AI Guard für Redaction) | | SPIRE | Anbieter von Workload-Credentials (Erweiterung von Ubers bestehender Zero-Trust-Infrastruktur) |
19. End-to-End-Kryptografiemechanik. 1. Workloads beziehen von SPIRE kryptografisch signierte SPIFFE Verifiable IDs (SVIDs). 2. Das SDK fordert unter Verwendung der Workload-Identität (der SVID) JWTs beim 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 Minuten). 5. Das Token trägt die vollständige Kette der beteiligten Akteure (die Actor Chain).
20. Kanonische Single-Hop, kurzlebige Doktrin (kanonische Formel). > « Single-Hop, kurzlebige Tokens. Jedes vom STS ausgestellte JWT ist für genau einen Hop bestimmt, mit einem spezifischen Audience-Claim und einer kurzen Time-to-Live in der Größenordnung von Minuten. » Operative Konsequenzen:
21. Token-Diebstahl = minimaler Blast Radius. (TTL in Minuten, einzelne Audience)
22. Kein wiederverwendbares Bearer-Token über Services hinweg. — ein deutlicher Kontrast zum klassischen OAuth
23. Jeder Hop erfordert ein neues Token. — der Netzwerk-Overhead wird durch eine Latenz von <40 ms kompensiert
24. Kanonischer Multi-Hop-Ablauf (Beispiel aus dem Artikel — Abbildung 4). 1. user1 (Bereitschaftsingenieur) initiiert eine Session mit Oncall Agent 2. Oncall Agent kontaktiert den STS, legt seine SPIRE-Identität (Workload-1) vor, fordert ein JWT für Investigation Agent an 3. Oncall Agent sendet das JWT an Investigation Agent (Workload-2) 4. Investigation Agent führt mit dem STS einen Token Exchange durch, um eine MCP Gateway-Audience zu erhalten 5. MCP Gateway erhält das JWT mit der Actor Chain [user1, oncall-agent, investigation-agent] — Zugriffsentscheidung auf Tool-Ebene anhand der vollständigen Historie
25. Standardized A2A Client (SDK).
26. Implementierung des A2A Protocol (Agent-to-Agent, ein aufkommender, auf GitHub referenzierter Standard).
27. Automatisiert. STS-Austausche, den Aufbau der Actor Chain und die Propagation über Hops hinweg.
28. Adoptionsdoktrin: « der sichere Weg ist für Entwickler zugleich der einfachste Weg, A2A-Aufrufe zu implementieren » — Secure by Default.
29. Gezeigter Code: eine BaseAgentProtocolClient-Klasse mit asynchronen Methoden (Aufbau des Authentifizierungskontexts + Aufruf von Agenten).
30. Schrittweise Migration von Legacy-Agenten per Refactoring.
31. Angeschlossene externe Standards (wissenswert). | Standard | Rolle | |----------|------| | SPIFFE / SPIRE | Workload-Identity-Framework — 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 — Drafts für Agentenidentität | | draft-klrc-aiagent-auth-01 | IETF-Draft « AI Agent Authentication and Authorization » | | A2A Protocol | Agent-to-Agent-Standard (Referenz auf GitHub) |
32. Produktionsmetriken (merkenswert).
33. *« Die P99-Latenz der STS Token Exchange API liegt durchgängig unter 40 Millisekunden ». *
34. Tausende interner Agenten. onboarded
35. Echtzeit-Observability-Dashboard, das Multi-Agent-Sessions nachverfolgt
36. Gelegentliche Spitzen, aber durchgängig <40 ms bei P99
37. Abgeleitete Sicherheitsmerkmale.
38. Token Exchange pro Hop. — Tokens sind nur für ein spezifisches Ziel gültig
39. Erhalt der Actor Chain. — vollständige Sichtbarkeit der Herkunft über alle Systeme hinweg
40. Policy-Durchsetzung auf Tool-Ebene. — Entscheidungen anhand der vollständigen Anfragehistorie
41. Datenredaktion via AI Guard. — sensible Informationen werden beim Durchlaufen des AI Gateway gefiltert
42. Langfristige Vision — Drei-Schichten-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 « Die langfristige Vision ist eine kohärente Architektur, in der Identität, Risiko und Policy nahtlos zusammenwirken. »
43. Warum dieser Artikel wichtig ist (Positionierung).
44. Die erste Referenzpublikation eines Hyperscalers außerhalb der KI-Labs. (Uber = Logistik/Mobilität), die Agentensicherheit auf Infrastrukturebene industrialisiert.
45. Überbrückt die doktrinäre Lücke. zwischen Skill-/Harness-Frameworks (Vincent Superpowers, Lattice, PROJ-AI, Wescale Usine Logicielle Augmentée), die von Produktivität sprechen, und Fragen der Enterprise-tauglichen Identität, für die bislang eine öffentliche Doktrin fehlte.
46. Schließt an aufkommende Standards an. (SPIFFE/SPIRE bereits übernommen, IETF WIMSE in Arbeit), statt ein proprietäres Protokoll zu erfinden — das klassische cathedral and bazaar-Muster von Uber Eng.
47. Wird zur Referenz für CISOs. , die vor dem internen Einsatz von Agenten stehen.
48. Verknüpfung mit der Watch-List.
49. Engste Familie (Enterprise-Agenten-Infrastruktur).
50. Stripe Minions (Gray 2026-02-09 und 2026-02-19). — Fiches [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 ~500 MCP-Tools, isolierte Devboxes. Stripe und Uber konvergieren bei der Industrialisierung interner Agenten — Stripe fokussiert auf Coding-Agenten und den MCP-Toolshed, Uber fokussiert auf die Identitätsschicht, die diese Deployments governance-fähig macht.
51. Levie *Building for trillions of agents. (Fiche [levie-building-trillions-agents-software-2026-03-07]) — Aaron Levie (Box): « API-first-Software für Agenten, agentische Infrastruktur, ökonomische Modelle »*. Levie prognostiziert; Uber liefert.
52. Thoughtworks AI/works™. (Fiche [thoughtworks-aiworks-agentic-development-platform-2026-05-12]) — eine Control Plane mit « aktiven Guardrails + End-to-End-Lineage ». Uber ist die produktive Umsetzung dessen, was Thoughtworks als Produkt verkauft.
53. MCP-/Tooling-Familie.
54. Anthropic 2026 Agentic Coding Trends Report. (Fiche [anthropic-agentic-coding-trends-report-2026-02]) — Demokratisierung und Supervision.
55. Cloudflare Markdown for Agents. (Fiche [martinho-allen-cloudflare-markdown-for-agents-2026-02-12]) — HTML→Markdown-Konvertierung am Edge. Cloudflare und Uber adressieren zwei unterschiedliche Dimensionen der Agenten-Infrastruktur: Datenform (Cloudflare) vs. Identität (Uber).
56. Harness-/Agentenarchitektur-Familie.
57. 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.
58. Osmani *Agent Harness Engineering. * (Fiche [osmani-agent-harness-engineering-2026-04-19]) — Uber ist ein operatives Beispiel für das, was Osmani theoretisiert.
59. 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)*.
60. Zero-Trust-/Plattformsicherheit-Familie.
61. 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]) — Recruiting für diese Skills. Ingenieurprofil, auf das Uber abzielt: Plan/Build/Review mit Kompetenz in Agentensicherheit.
62. Souveränitäts-/Verteidigungs-/Risiko-Familie.
63. Mensch / Mistral vor dem Untersuchungsausschuss der französischen Nationalversammlung. (Fiche [mensch-mistral-commission-enquete-vulnerabilites-numeriques-souverainete-ia-2026-05-13]) — « wirtschaftliche Sicherheit » + « Cyber: linear wachsende offensive Fähigkeiten ». Uber zeigt wie man dies operativ absichert; Mensch zeigt warum dies strategisch bedeutsam für die Souveränität ist.
64. AISI UK GPT-5.5 Cyber Capabilities. (Fiche [aisi-uk-gpt55-cyber-capabilities-evaluation-2026-04-30]) — Modelle, die in der Lage sind, Schwachstellen zu entdecken. Verteidigung führt über Architekturen wie die von Uber.
65. 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 erst ermöglicht.
66. Schwachpunkte / offene Fragen.
67. Keine Kostenangaben. zur Architektur (wie viele STS-Server, wie viele QPS, wie viele JWTs pro Tag ausgestellt).
68. Keine Zahlen zu Produktivitätsverlusten der Entwickler. durch die Migration von Legacy-Agenten (wie viele Refactoring-PRs? welche Gesamtdauer?).
69. Positionierung gegenüber Vendor-Lösungen. (Auth0, Okta, ForgeRock) nicht diskutiert — Uber entschied sich für Eigenentwicklung auf Basis von SPIRE statt Zukauf, ohne die Build-vs-Buy-Begründung darzulegen.
70. Keine Diskussion von Failure Modes. — was passiert, wenn der STS ausfällt? Welcher Degraded Mode? Welcher Circuit Breaker?
71. Privacy / DSGVO / personenbezogene Daten. in der Actor Chain — nicht behandelt (ein Bereitschaftsingenieur kann über alle Hops hinweg namentlich nachverfolgbar sein).
72. Keine Diskussion. von Delegation-Chain-Confusion-Angriffen oder der Injektion eines gefälschten Glieds in die Kette.
73. Das A2A Protocol. wird als externe Abhängigkeit angeführt — der IETF-Draft ist jedoch noch kein Standard. Risiko: frühe Adoption eines Protokolls, das sich noch weiterentwickeln kann.
74. Zu merkendes Uber-Eng-Vokabular. Agency (Ubers Definition), Single-Hop-kurzlebige Tokens, Actor Chain, Agent Registry, AI Agent Mesh, sicherer Weg = einfachster Weg, Token Exchange pro Hop, Erhalt der Provenienz, MCP Gateway als Policy Enforcement Point, AI Gateway als Redaction-Schicht, Drei-Schichten-Framework (Identity / Access / Enforcement).
75. Verwendung für.
76. CISO-/Executive-Präsentationen zu Enterprise-Agentensicherheit (kanonische Referenz).
77. Architekturdoktrin für Industriekunden, die interne Agenten einsetzen (≥ 100 Agenten in einer Flotte).
78. Build-vs-Buy-Vergleich für agentische IAM-Lösungen.
79. Argument zugunsten von SPIFFE/SPIRE als De-facto-Standard für Workload-Identität (CNCF graduated + von Uber übernommen).
80. Referenz in jedem Planungsdokument für Enterprise-Agentenplattformen (Control Plane, Identitätsschicht, Observability).
81. Konvergenz mit der Wescale-Usine Logicielle Augmentée- und Thoughtworks-AI/works™-Doktrin zur Notwendigkeit einer ausgereiften « Control Plane ».