Engineering article published on Uber's 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. Pivotal thesis: existing identity models (human + workload) do not 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) (issuance of short scoped JWTs) + 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 token (TTL on the order of minutes) is issued for a specific single-hop destination (targeted Audience claim). Pivotal doctrine: *« Single-hop, short-lived tokens.
By **Matt Mathew**// Source uber.com ↗/Reading 2 min/.md// Auto-verified translation
Six Uber engineers (Matt Mathew et al.) published an article on the Uber Engineering blog on May 21, 2026, laying out the AI agent identity and access-control architecture deployed in production at Uber for thousands of internal agents. Pivotal thesis: « an agent is best defined as an entity that is authorized to act for or in the place of another », which renders the classic human+workload identity model obsolete.
Two named problems: (1) « Current Identity Model Doesn't Describe Agency » — delegation is the default mode, workflows are compositional, behavior is dynamic; (2) « Original Provenance Isn't Effectively Carried Forward Across Agents to Systems » — « Execution context is dropped across agent hops » — creating audit gaps and preventing consistent enforcement of fine-grained access policies.
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.
— **Matt Mathew** , uber.com
Architecture as an extension of Uber's Zero Trust Architecture: Agent Registry (agent↔workload source of truth) + AI Agent Mesh (inter-agent data plane) + STS (Security Token Service) (issuance of short scoped JWTs) + MCP Gateway (policy enforcement for tools) + AI Gateway (LLM mediation + redaction via AI Guard) + SPIRE (workload credential provider).
Mechanics: workloads fetch cryptographically signed SPIFFE Verifiable IDs (SVIDs) from SPIRE → the SDK requests a JWT from the STS → the STS verifies authorization against the Agent Registry → a short token (TTL on the order of minutes) is issued for a specific single-hop destination (Audience claim). Canonical 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. »
Multi-hop walkthrough: an on-call engineer user1 → Oncall Agent → Investigation Agent → MCP Gateway. The final JWT carries a verifiable actor chain [user1, oncall-agent, investigation-agent] — tool-level access decisions based on the full history of the request.
Standardization: a Standardized A2A (Agent-to-Agent) Client SDK automates STS exchanges and actor-chain propagation — « the secure path is also the easiest path for developers to implement A2A calls ». 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, real-time observability.
Significance: the first reference publication from a non-AI-lab hyperscaler that industrializes agent security at the infrastructure level, bridging the doctrinal gap between skills/harness frameworks (productivity) and enterprise-grade identity questions (governability). Becomes a canonical reference for platform architects, security engineers, and CISOs facing internal agent deployment.
Key takeaways
Source. Uber Engineering blog (uber.com/blog), official publication. Article from May 21, 2026 — 2 days before the consultation date of 2026-05-23.
Authors (six co-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
Uber Security/Identity infrastructure team, responsible for the production agent identity architecture.
Pivotal epistemic thesis.« An agent is best defined as an entity that is authorized to act for or in the place of another. » This definition posits delegation as an axiomatic property of the agent — which changes everything about the classic identity model (human or workload, but never for someone else).
Two named operational problems. 1. Current Identity Model Doesn't Describe Agency — existing identity frameworks cover humans and workloads, but do not model acting on behalf of as a default mode. Consequences:
Delegation is the default mode. — agents work on behalf of others
Workflows are compositional. — agents call other agents, tools, and systems
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. » Consequences:
Incomplete audit trails.
Inconsistent enforcement. of fine-grained access policies
No ability to reason about the full chain of actors that initiated a request
Architecture — six named components. | Component | Role | |-----------|------| | Agent Registry | Source of truth for agent↔workload mappings | | AI Agent Mesh | Data plane for inter-agent communication | | STS (Security Token Service) | Issues short, scoped (audience-specific) JWTs | | MCP Gateway | Policy enforcement point for tool invocation (MCP tools) | | AI Gateway | Mediation of calls to external AI models + security guardrails (AI Guard for redaction) | | SPIRE | Workload credential provider (extension of Uber's existing Zero Trust infra) |
End-to-end cryptographic mechanics. 1. Workloads fetch cryptographically signedSPIFFE Verifiable IDs (SVIDs) from SPIRE. 2. The SDK requests JWTs from the STS using the workload identity (the SVID). 3. The STS verifies the agent's authorization against the Agent Registry. 4. Short-lived tokens are issued for a specific single-hop destination (targeted Audience claim, TTL in minutes). 5. The token carries the full chain of participating actors (the actor chain).
Canonical single-hop, short-lived doctrine (canonical formula). > « 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. » Operational consequences:
Token theft = minimal blast radius. (TTL in minutes, single audience)
No reusable bearer token across services. — a sharp contrast with classic OAuth
Every hop requires a new token. — network overhead offset by <40ms latency
Canonical multi-hop walkthrough (article example — Figure 4). 1. user1 (on-call engineer) initiates a session with Oncall Agent 2. Oncall Agent contacts the STS, presents its SPIRE identity (Workload-1), requests a JWT for Investigation Agent 3. Oncall Agent sends the JWT to Investigation Agent (Workload-2) 4. Investigation Agent performs a token exchange with the STS to obtain an MCP Gateway audience 5. MCP Gateway receives the JWT with the actor chain [user1, oncall-agent, investigation-agent] — tool-level access decision based on the full history
Standardized A2A Client (SDK).
Implementation of the A2A protocol (Agent-to-Agent, an emerging standard referenced on GitHub).
Automates. STS exchanges, actor-chain construction, and cross-hop propagation.
Adoption doctrine: « the secure path is also the easiest path for developers to implement A2A calls » — secure by default.
Code shown: a BaseAgentProtocolClient class with async methods (authentication context building + agent calling).
Phased migration of legacy agents via refactoring.
Aligned external standards (worth knowing). | Standard | Role | |----------|------| | SPIFFE / SPIRE | Workload identity framework — CNCF graduated project | | OAuth 2.0 Token Exchange (RFC 8693) | Conceptual basis for per-hop token exchange | | IETF WIMSE working group | Workload Identity in Multi-System Environments — drafts for agent identity | | draft-klrc-aiagent-auth-01 | IETF draft « AI Agent Authentication and Authorization » | | A2A Protocol | Agent-to-Agent standard (GitHub reference) |
Production metrics (worth remembering).
*« P99 latency for the STS Token Exchange API is consistently below 40 milliseconds ». *
Per-hop token exchange. — tokens valid only for a specific destination
Actor chain preservation. — full lineage visibility across all systems
Tool-level policy enforcement. — decisions based on the full request history
Data redaction via AI Guard. — sensitive information filtered as it passes through the AI Gateway
Long-term vision — Three-Layer Framework. (target architecture): 1. Identity & Trust Foundation — verifiable agent identity + delegation chains 2. Dynamic Access Control — context-based permissions + human-in-the-loop options + workflow authorization 3. Unified Enforcement Plane — unified policy decisions + observability + audit + governance « Long-term vision is a cohesive architecture where identity, risk, and policy work together seamlessly. »
Why this article matters (positioning).
The first reference publication from a non-AI-lab hyperscaler. (Uber = logistics/mobility) that industrializes agent security at the infrastructure level.
Bridges the doctrinal gap. between skills/harness frameworks (Vincent Superpowers, Lattice, PROJ-AI, Wescale Usine Logicielle Augmentée) that talk about productivity, and enterprise-grade identity questions that lacked public doctrine.
Aligns with emerging standards. (SPIFFE/SPIRE already adopted, IETF WIMSE in progress) rather than inventing a proprietary protocol — the classic cathedral and bazaar pattern of Uber Eng.
Becomes a reference for CISOs. facing internal agent deployment.
Watch-list linkage.
Immediate family (enterprise agent infrastructure).
Stripe Minions (Gray 2026-02-09 and 2026-02-19). — fiches [gray-stripe-minions-coding-agents-part1-2026-02-09] and [gray-stripe-minions-coding-agents-part2-2026-02-19]: 1000-1300+ autonomous PRs/week, Toolshed ~500 MCP tools, isolated devboxes. Stripe and Uber converge on industrializing internal agents — Stripe focuses on coding agents and the MCP toolshed, Uber focuses on the identity layer that makes these deployments governable.
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, economic models »*. Levie predicts; Uber delivers.
Thoughtworks AI/works™. (fiche [thoughtworks-aiworks-agentic-development-platform-2026-05-12]) — a Control Plane with « active guardrails + end-to-end lineage ». Uber is the production implementation of what Thoughtworks sells as a product.
Cloudflare Markdown for Agents. (fiche [martinho-allen-cloudflare-markdown-for-agents-2026-02-12]) — HTML→Markdown conversion at the edge. Cloudflare and Uber address two distinct dimensions of agent infrastructure: data shape (Cloudflare) vs. identity (Uber).
Harness / agent architecture family.
Trivedy *Anatomy of an Agent Harness. * (fiche [trivedy-langchain-anatomy-agent-harness-2026-03-10]) — Agent=Model+Harness. Uber adds: the harness now includes a dedicated, hop-aware identity layer.
Osmani *Agent Harness Engineering. * (fiche [osmani-agent-harness-engineering-2026-04-19]) — Uber is an operational example of what Osmani theorizes.
Seale *Semantic Agent: (Model+Harness) + (Ontology+Data). (fiche [seale-semantic-agent-model-harness-ontology-data-2026-04-17]) — Uber adds a third dimension: (Identity + Provenance)*.
Zero trust / platform security family.
Sierra AI-native interview. (fiches [sierra-ai-native-interview-iyengar-asemanfar-wang-2026-04-22] and [taylor-sierra-ai-native-interview-engineering-hiring-2026-04-20]) — hiring for these skills. Engineer profile Uber targets: Plan/Build/Review with agent-security competence.
Sovereignty / defense / risk family.
Mensch / Mistral before the French National Assembly inquiry committee. (fiche [mensch-mistral-commission-enquete-vulnerabilites-numeriques-souverainete-ia-2026-05-13]) — « economic security » + « cyber: linearly growing offensive capabilities ». Uber shows how to operationally secure this; Mensch shows why it is strategically important for sovereignty.
AISI UK GPT-5.5 cyber capabilities. (fiche [aisi-uk-gpt55-cyber-capabilities-evaluation-2026-04-30]) — models capable of discovering vulnerabilities. Defense goes through architectures like Uber's.
Sun *Permanent Underclass. (fiche [sun-nyt-silicon-valley-permanent-underclass-2026-04-30]) — labor-to-capital shift. Uber illustrates the « capital »* infrastructure layer that makes automation at scale possible.
Weak points / open questions.
No cost details. on the architecture (how many STS servers, how many QPS, how many JWTs issued per day).
No figures on developer productivity losses. from migrating legacy agents (how many refactoring PRs? what total duration?).
Position vs. vendor solutions. (Auth0, Okta, ForgeRock) not discussed — Uber chose to build in-house on SPIRE rather than buy, but without spelling out the build-vs-buy reasoning.
No discussion of failure modes. — what happens if the STS goes down? What degraded mode? What circuit breaker?
Privacy / GDPR / personal data. in the actor chain — not addressed (an on-call engineer may be traceable by name across all hops).
No discussion. of delegation-chain confusion attacks or injection of a fake link in the chain.
The A2A protocol. is cited as an external dependency — but the IETF draft is not yet a standard. Risk: early adoption of a protocol that may still evolve.
Uber-eng vocabulary to remember.agency (Uber's 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).
Use for.
CISO/executive presentations on enterprise agent security (canonical reference).
Architecture doctrine for industrial clients deploying internal agents (≥ 100 agents in a fleet).
Build-vs-buy comparison for agentic IAM solutions.
Argument in favor of SPIFFE/SPIRE as the de facto standard for workload identity (CNCF graduated + adopted by Uber).
Reference in any enterprise agent platform planning document (control plane, identity layer, observability).
Convergence with the Wescale Usine Logicielle Augmentée and Thoughtworks AI/works™ doctrine on the need for a mature « control plane ».