Analyse von Janakiram MSV (The New Stack, 20. Juli 2026) über die **architektonische Konvergenz** der Enterprise-Agentenplattformen der drei Hyperscaler: Innerhalb von neun Monaten haben sich **Amazon Bedrock AgentCore**, **Microsoft Foundry** und die **Gemini Enterprise Agent Platform** auf **dieselben sechs Primitiven** geeinigt — Runtime, Memory, Tool-Gateway, Identität, Observability, Governance — unter unterschiedlichen Markennamen. Was vor 18 Monaten noch eine fragmentierte Sammlung von Bibliotheken war, wird zu einer eigenständigen **Plattformschicht**. Die These: Diese Konvergenz wiederholt die **PaaS-Wende von 2011–2016**, als **Cloud Foundry** und **Heroku** VMs, Load Balancer, Warteschlangen und Secret Stores um einen portablen **Anwendungsvertrag** herum vereinheitlichten — nur dass hier **noch kein gleichwertiger Vertrag existiert** und **kein Open-Source-Projekt ihn für sich beansprucht hat**. Konsequenz: Ein Unternehmen kann **einen Agenten nicht von einer Cloud in eine andere verschieben** (Sitzungszustand, Traces und Identität landen allesamt bei einem einzigen Anbieter; eine Migration bedeutet, alles neu aufzubauen). Der Autor schlägt eine **zeilenweise Abbildung** des Cloud-Foundry-Vertrags auf Agenten vor, formuliert drei Gestaltungsprinzipien (den Agenten als **eine einzige deploybare Einheit** verpacken, Fähigkeiten **anhängen** statt Anbieter einzubetten, die **operative** Schicht in die Abstraktion integrieren), zeigt auf, was offene Protokolle (MCP, A2A, OpenTelemetry) außen vor lassen — den **Lebenszyklus** — und liefert drei Due-Diligence-Fragen: **Governance** (neutrale Foundation vs. Anbieter), **Packaging** (dasselbe Artefakt auf zwei Clouds ohne Neuschreiben), **Zustand** (exportierbares Memory). Fazit: Wer am Ende die **Agenten-Control-Plane** besitzt, wird definieren, *was ein Agent ist*.
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.