# uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21

## Veille

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.

## Titre Article

Solving the Identity Crisis for AI Agents

## Date

2026-05-21

## URL

https://www.uber.com/us/en/blog/solving-the-agent-identity-crisis/

## Keywords

Uber Engineering, AI agent identity, agent identity crisis, agency definition, agent-as-delegate, multi-hop workflow, actor chain, provenance preservation, Zero Trust Architecture, Agent Registry, AI Agent Mesh, Security Token Service STS, MCP Gateway, AI Gateway, MCP tool invocation, SPIRE workload identity, SPIFFE Verifiable IDs SVID, JWT short-lived tokens, audience claim, single-hop tokens, per-hop token exchange, OAuth 2.0 Token Exchange RFC 8693, A2A protocol agent-to-agent, Standardized A2A Client, BaseAgentProtocolClient, IETF WIMSE working group, draft-klrc-aiagent-auth-01, AI Agent Authentication and Authorization, on-call engineer agent, Oncall Agent, Investigation Agent, Monitoring Agent, audit trail, fine-grained access policy, policy enforcement point, data redaction AI Guard, secure-by-default, P99 latency 40ms, identity trust foundation, dynamic access control, unified enforcement plane, three-layer framework, agent observability, audit governance, agent provenance, delegation chain, cryptographically signed workload credentials, SPIFFE CNCF graduated, agent-to-workload mapping, Uber internal agents, thousands of agents production, agent infrastructure security, agent mesh, secure path easiest path, legacy agent migration phased refactoring, identity model limitations, downstream systems policy, contextual attribution

## 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). Tous chez **Uber**, équipe Security/Identity infrastructure responsable du déploiement de l'architecture d'identité agentique en production. Composition d'équipe représentative : un Engineering Manager, un Staff senior cadre, un Staff IC architecte, deux SWE séniors/intermédiaires, un SWE I — pattern classique d'une équipe Uber qui livre une plateforme transverse mission-critical.

## Ton

**Profile**: Corporate technical-explanatory engineering article, in the register of a *hyperscaler engineering blog*. Canonical Uber Engineering format: didactic exposition of a production-deployed solution, *problem-first* narration (two problems identified and named), architecture diagrams (Figures 1-4 mentioned), a concrete multi-hop walkthrough example, validation metrics, long-term vision. No disguised marketing, no hyperbole — an **operational engineering memo** register aimed at security engineers, platform architects, and tech leads.

**Style**: Plural engineer-architect voice (six co-authors), in the **precise Anglo-Saxon corporate** register characteristic of Uber Eng:
1. **Short axiomatic definitions** — *"An agent is best defined as an entity that is authorized to act for or in the place of another."* An 18-word definition that structures the entire rest of the document. Propositional mode.
2. **Orthogonal enumeration of constraints** — *"Delegation is the default mode... Workflows are compositional... Behavior is dynamic"* — three mutually exclusive, collectively exhaustive properties that justify the need for a new identity model.
3. **Problem → component → mechanism → example → metric pattern** — each layer is introduced by the problem it solves, then specified by its role, then detailed by its mechanics (tokens, claims, audience), then instantiated by a walkthrough, then validated by a measurement. Controlled *zoom-in zoom-out* pedagogy.
4. **Lexical precision** — *"short-lived tokens," "single-hop," "specific Audience claim," "time-to-live in the order of minutes," "cryptographically signed"* — vocabulary dense with precise technical terms, without paraphrase.

**Metaphors and key formulas**:
- ***"An agent is best defined as an entity that is authorized to act for or in the place of another"*** — Uber's **founding definition of agency**, which posits delegation as an axiomatic property of the agent.
- ***"Execution context (originating user, intermediate agents) is dropped across agent hops"*** — a short, operative framing formula for the provenance problem.
- ***"Single-hop, short-lived tokens"*** — the doctrine-slogan of the solution, the functional equivalent of classic Zero Trust's *"least privilege"* adapted to the agentic regime.
- ***"The secure path is also the easiest path for developers to implement A2A calls"*** — the adoption doctrine: default security with no developer friction (a direct parallel to the classic SRE *"paved road"*).
- ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds"*** — the metric-formula that settles the *"is this architecture viable at Uber scale?"* debate — answer: yes, with margin to spare.

**Epistemic position**: The authors speak as **production operators** (thousands of internal agents, measured P99, an existing observability dashboard). They are not theorizing — they are **documenting a shipped solution**. The tone is confident but not triumphalist, with explicit acknowledgment that the work continues (*"long-term vision,"* *"phased refactoring"* of legacy agents).

**Authority built through**: (a) **production traction** (concrete figures — P99 <40ms, thousands of agents), (b) **architectural depth** (six named components, exposed cryptographic mechanics), (c) **standards alignment** (SPIFFE/SPIRE CNCF graduated, RFC 8693, IETF WIMSE), (d) **team composition** (six co-authors on the post — a signal that this is a mature cross-cutting platform, not a POC), (e) **timing** (published while the industry conversation on agent security is still emerging — Uber stakes out a reference position).

**Audience and expected impact**: An article calibrated for **platform architects and security engineers** at large enterprises beginning to deploy AI agents internally. Secondary audience: the CNCF/SPIFFE community, contributors to the IETF WIMSE drafts, MCP/gateway vendors. Expected effect: becoming a **canonical reference** in 2026 agentic security doctrine, alongside Anthropic's MCP publications, Stripe's Toolshed, and Cloudflare's edge work.

## Pense-betes

- **Source**: Uber Engineering blog (uber.com/blog), official publication. Article dated **May 21, 2026** — 2 days before the consultation date 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.
- **Epistemological pivot 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 upends 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 the 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 infrastructure) |
- **End-to-end cryptographic mechanics**: 1. Workloads fetch **cryptographically signed SPIFFE 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 **on the order of minutes**). 5. The token carries the **full chain of participating actors** (the actor chain).
- **"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 cross-service bearer token** — sharp contrast with classic OAuth
- **Every hop requests a new token** — network overhead offset by <40ms latency
- **Canonical multi-hop walkthrough (article example — Figure 4)**: 1. **user1** (on-call engineer) starts a session with the **Oncall Agent** 2. The **Oncall Agent** contacts the STS, presents its SPIRE identity (Workload-1), and requests a JWT for the **Investigation Agent** 3. The Oncall Agent sends the JWT to the **Investigation Agent** (Workload-2) 4. The **Investigation Agent** performs a **token exchange** with the STS to obtain an **MCP Gateway** audience 5. The **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 — a **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 on agent identity | | **draft-klrc-aiagent-auth-01** | IETF draft *"AI Agent Authentication and Authorization"* | | **A2A Protocol** | Agent-to-Agent standard (GitHub reference) |
- **Production metrics (key takeaways)**:
- ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds"***
- **Thousands of internal agents** onboarded
- Real-time observability dashboard tracing multi-agent sessions
- Occasional spikes but consistently <40ms at P99
- **Derived security features**:
- **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 history of the request
- **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)**:
- **First reference publication from a non-AI-lab hyperscaler** (Uber = logistics/mobility) industrializing agent security at the infrastructure level.
- **Closes 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 previously lacked a 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.
- **Dossier articulation**:
- **Immediate family (enterprise agent infrastructure)**:
- **Stripe Minions (Gray 2026-02-09 and 2026-02-19)** — fiche [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 the **industrialization of 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, business 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.
- **MCP / tools family**:
- **Anthropic 2026 Agentic Coding Trends Report** (fiche [anthropic-agentic-coding-trends-report-2026-02]) — democratization and oversight.
- **Cloudflare Markdown for Agents** (fiche [martinho-allen-cloudflare-markdown-for-agents-2026-02-12]) — HTML-to-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 the forces. Uber's targeted engineer profile: Plan/Build/Review with agent security skills.
- **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: linear offensive capabilities."* Uber shows **how** to secure things operationally; Mensch shows **why** it matters strategically 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 runs 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 details on the cost** of the architecture (how many STS servers, how much QPS, how many JWTs issued per day).
- **No figures on developer productivity losses** from legacy agent migration (how many refactoring PRs? 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 identifiably traceable across all hops).
- **No discussion** of delegation-chain confusion attacks or fake-link injection.
- **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)*.
- **Useful for**:
- CISO executive presentations on enterprise agent security (canonical reference).
- Architecture doctrine for industrial clients deploying internal agents (≥100 agents in 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 Wescale's **Usine Logicielle Augmentée** doctrine and Thoughtworks' **AI/works™** on the need for a mature *"control plane."*

## RésuméDe400mots

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**. **Pivot 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.

**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)** (short scoped JWT issuance) + **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-lived 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.

**Long-term vision — three-layer framework**: (1) Identity & Trust Foundation, (2) Dynamic Access Control, (3) Unified Enforcement Plane.

**External standards**: SPIFFE/SPIRE (CNCF graduated), OAuth 2.0 Token Exchange (RFC 8693), IETF WIMSE working group, draft `draft-klrc-aiagent-auth-01`, A2A protocol.

**Significance**: the first reference publication from a non-AI-lab hyperscaler industrializing **agent security at the infrastructure level**, closing 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.

## GrapheDeConnaissance

- Uber Engineering —a_créé→ architecture identité agent IA (déployée en production) (TECHNOLOGIE, 0.98)
- Matt Mathew —travaille_chez→ Uber Engineering (ORGANISATION, 0.98)
- Prasad Borole —travaille_chez→ Uber Engineering (ORGANISATION, 0.98)
- Meng Huang —travaille_chez→ Uber Engineering (ORGANISATION, 0.98)
- Uber Engineering —affirme_que→ un agent = entité autorisée à agir pour ou à la place d'un autre (AFFIRMATION, 0.99)
- Uber Engineering —affirme_que→ le modèle d'identité classique ne décrit pas l'agency (AFFIRMATION, 0.98)
- workflows agentiques —est_instance_de→ processus compositionnels (agents appellent agents et tools) (CONCEPT, 0.97)
- comportement agentique —est_instance_de→ comportement dynamique (plans évoluent selon résultats intermédiaires) (CONCEPT, 0.97)
- Uber Engineering —affirme_que→ "Execution context (originating user, intermediate agents) is dropped across agent hops" (CITATION, 0.98)
- perte de provenance —réduit→ cohérence d'application des politiques fine-grained (CONCEPT, 0.96)
- architecture Uber —est_basé_sur→ Zero Trust Architecture (METHODOLOGIE, 0.97)
- Agent Registry —est_instance_de→ source of truth pour mappings agent↔workload (CONCEPT, 0.98)
- AI Agent Mesh —est_instance_de→ data plane pour communication inter-agents (CONCEPT, 0.97)
- STS (Security Token Service) —permet→ émission de JWT short-lived scopés single-hop (CONCEPT, 0.98)
- MCP Gateway —est_instance_de→ policy enforcement point pour invocation outils (CONCEPT, 0.97)
- AI Gateway —permet→ médiation des appels LLM externes avec guardrails (CONCEPT, 0.96)
- AI Gateway —utilise→ AI Guard (CONCEPT, 0.95)
- SPIRE —permet→ workload credentials signés cryptographiquement (CONCEPT, 0.97)
- SPIFFE Verifiable IDs (SVID) —fait_partie_de→ SPIFFE (TECHNOLOGIE, 0.97)
- workloads Uber —utilise→ SPIFFE Verifiable IDs (SVID) (CONCEPT, 0.97)
- SDK Uber —utilise→ STS (Security Token Service) (TECHNOLOGIE, 0.97)
- STS (Security Token Service) —utilise→ Agent Registry (TECHNOLOGIE, 0.97)
- JWT Uber —s_applique_à→ destination single-hop spécifique (claim Audience) (CONCEPT, 0.98)
- JWT Uber —utilise→ TTL court de l'ordre de minutes (short-lived) (CONCEPT, 0.97)
- actor chain —fait_partie_de→ JWT Uber (TECHNOLOGIE, 0.97)
- actor chain —permet→ décisions accès tool-level basées sur historique requête (CONCEPT, 0.97)
- Standardized A2A Client —permet→ STS (Security Token Service) (TECHNOLOGIE, 0.97)
- Standardized A2A Client —permet→ actor chain (CONCEPT, 0.97)
- Standardized A2A Client —utilise→ A2A protocol (TECHNOLOGIE, 0.95)
- Uber Engineering —recommande→ secure path = easiest path (METHODOLOGIE, 0.97)
- architecture Uber —est_basé_sur→ OAuth 2.0 Token Exchange (RFC 8693) (TECHNOLOGIE, 0.95)
- Uber Engineering —converge_avec→ draft-klrc-aiagent-auth-01 (DOCUMENT, 0.96)
- draft-klrc-aiagent-auth-01 —s_applique_à→ authentification et autorisation des agents IA (CONCEPT, 0.94)
- STS (Security Token Service) —mesure→ P99 latency <40 millisecondes (MESURE, 0.98)
- Uber Engineering —utilise→ milliers d'agents internes adoptés (CONCEPT, 0.95)
- Uber Engineering —utilise→ dashboard observabilité temps réel sessions multi-agents (TECHNOLOGIE, 0.94)
- Uber Engineering —recommande→ three-layer framework (Uber) (METHODOLOGIE, 0.95)
- Uber Engineering —utilise→ refactoring phasé pour migrer les agents legacy (METHODOLOGIE, 0.94)
- SPIRE —fait_partie_de→ CNCF (projet graduated) (ORGANISATION, 0.97)
- article Uber —est_instance_de→ première publication référence hyperscaler non-AI-lab sur identity agent (CONCEPT, 0.93)
- identity layer Uber —résout→ gap entre frameworks skills/harness et identity enterprise (CONCEPT, 0.92)
- Uber on-call engineer —utilise→ Oncall Agent (initiation de session) (TECHNOLOGIE, 0.96)
- Oncall Agent —utilise→ Investigation Agent (TECHNOLOGIE, 0.96)
- Investigation Agent —utilise→ MCP Gateway (TECHNOLOGIE, 0.96)
- MCP Gateway —utilise→ actor chain (CONCEPT, 0.97)

---
Canonical: https://www.thekb.eu/en/fiches/uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21/