Analysis by Janakiram MSV (The New Stack, July 20, 2026) of the **architectural convergence** of the three hyperscalers' enterprise agent platforms: in nine months, **Amazon Bedrock AgentCore**, **Microsoft Foundry**, and **Gemini Enterprise Agent Platform** have converged on the **same six primitives** — runtime, memory, tool gateway, identity, observability, governance — under different brand names. What was a fragmented collection of libraries 18 months ago is becoming a distinct **platform layer**. The thesis: this convergence replays the **2011-2016 PaaS inflection**, where **Cloud Foundry** and **Heroku** unified VMs, load balancers, queues, and secret stores around a portable **application contract** — except that here **no equivalent contract yet exists**, and **no open source project has claimed it**. Consequence: an enterprise cannot **move an agent from one cloud to another** (session state, traces, and identity all end up with a single provider; migrating means rebuilding everything). The author proposes a **line-by-line mapping** of the Cloud Foundry contract onto agents, sets out three design principles (package the agent as **one deployable unit**, **attach** capabilities rather than embedding providers, integrate the **operational** layer into the abstraction), points to what open protocols (MCP, A2A, OpenTelemetry) leave out of scope — the **lifecycle** — and delivers three due diligence questions: **governance** (neutral foundation vs. vendor), **packaging** (the same artifact on two clouds without rewriting), **state** (exportable memory). Verdict: whoever ends up owning the **agent control plane** will define *what an agent is*.
Engineering article published on the **Uber** Engineering blog by six engineers (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) on **May 21, 2026**, laying out the **AI agent identity and access-control doctrine** deployed in production at Uber for several thousand internal agents. **Pivot thesis**: existing identity models (humans + workloads) fail to describe **agency** — *"an agent is best defined as an entity that is authorized to act for or in the place of another"* — and lose **provenance** across the hops of an agentic workflow. **Two operational problems identified**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — delegation is the default mode, workflows are compositional (agents calling agents calling tools), 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."* **Proposed architecture** as an extension of Uber's Zero Trust Architecture: **Agent Registry** (source of truth for agent↔workload mappings) + **AI Agent Mesh** (inter-agent data plane) + **STS (Security Token Service)** (short-scoped JWT issuance) + **MCP Gateway** (policy enforcement point for tool invocation) + **AI Gateway** (mediation of external LLM calls with guardrails) + **SPIRE** (workload credential provider). **Cryptographic mechanics**: workloads fetch cryptographically signed **SVIDs (SPIFFE Verifiable IDs)** from SPIRE → the SDK requests a JWT from the STS via the workload identity → the STS verifies the agent's authorization against the Agent Registry → a short-lived token (TTL on the order of minutes) is issued for a **specific single-hop destination** (targeted `Audience` claim). **Pivot doctrine**: ***"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."*** **Preservation of the actor chain**: a multi-hop example with on-call engineer `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway; the final JWT carries a verifiable **actor chain `[user1, oncall-agent, investigation-agent]`**, enabling tool-level access decisions based on the **full history of the request**. **Standardization**: a **Standardized A2A (Agent-to-Agent) Client** that automates STS exchanges and actor-chain propagation — *"the secure path is also the easiest path for developers to implement A2A calls"* — with phased migration of legacy agents. **Production metrics**: ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds,"*** thousands of internal agents onboarded, a real-time observability dashboard tracing multi-agent sessions. **Long-term vision — three-layer framework**: (1) Identity & Trust Foundation (verifiable agent identity + delegation chains), (2) Dynamic Access Control (context-based permissions + human-in-the-loop), (3) Unified Enforcement Plane (centralized, observable policy). **Standards alignment**: the IETF **WIMSE** working group + draft `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, conceptually grounded in **OAuth 2.0 Token Exchange (RFC 8693)** and **SPIFFE/SPIRE** (CNCF graduated). The first reference publication from a non-AI-lab hyperscaler (logistics/mobility) industrializing agent security at the infrastructure level, closing the doctrinal gap between skills/harness frameworks (Vincent, Lattice, PROJ-AI) and enterprise-grade identity questions.