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

## Veille

Articolo di engineering pubblicato sul blog Engineering di **Uber** da sei ingegneri (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) il **21 maggio 2026**, che espone la **dottrina di identità e controllo degli accessi per agenti IA** dispiegata in produzione in Uber per diverse migliaia di agenti interni. **Tesi cardine**: i modelli di identità esistenti (umani + workload) non riescono a descrivere l'**agency** — *"an agent is best defined as an entity that is authorized to act for or in the place of another"* — e perdono la **provenance** attraverso gli hop di un workflow agentico. **Due problemi operativi identificati**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — la delega è la modalità predefinita, i workflow sono composizionali (agenti che chiamano agenti che chiamano tool), il comportamento è dinamico (i piani evolvono in base ai risultati intermedi); (2) ***"Original Provenance Isn't Effectively Carried Forward Across Agents to Systems"*** — *"Execution context (originating user, intermediate agents) is dropped across agent hops."* **Architettura proposta** come estensione della Zero Trust Architecture di Uber: **Agent Registry** (fonte di verità per le mappature agente↔workload) + **AI Agent Mesh** (data plane inter-agente) + **STS (Security Token Service)** (emissione di JWT a scope ristretto) + **MCP Gateway** (punto di enforcement delle policy per l'invocazione dei tool) + **AI Gateway** (mediazione delle chiamate LLM esterne con guardrail) + **SPIRE** (fornitore di credenziali per i workload). **Meccanica crittografica**: i workload recuperano **SVID (SPIFFE Verifiable IDs)** firmati crittograficamente da SPIRE → l'SDK richiede un JWT all'STS tramite l'identità del workload → l'STS verifica l'autorizzazione dell'agente rispetto all'Agent Registry → viene emesso un token a breve durata (TTL dell'ordine di minuti) per una **destinazione specifica a singolo hop** (claim `Audience` mirato). **Dottrina cardine**: ***"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."*** **Preservazione della catena di attori**: un esempio multi-hop con l'ingegnere di guardia `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway; il JWT finale porta una **catena di attori verificabile `[user1, oncall-agent, investigation-agent]`**, che consente decisioni di accesso a livello di tool basate sulla **storia completa della richiesta**. **Standardizzazione**: un **Standardized A2A (Agent-to-Agent) Client** che automatizza gli scambi con l'STS e la propagazione della catena di attori — *"the secure path is also the easiest path for developers to implement A2A calls"* — con migrazione graduale degli agenti legacy. **Metriche di produzione**: ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds,"*** migliaia di agenti interni onboardati, una dashboard di osservabilità in tempo reale che traccia le sessioni multi-agente. **Visione a lungo termine — framework a tre livelli**: (1) Identity & Trust Foundation (identità verificabile dell'agente + catene di delega), (2) Dynamic Access Control (permessi basati sul contesto + human-in-the-loop), (3) Unified Enforcement Plane (policy centralizzata e osservabile). **Allineamento agli standard**: il working group IETF **WIMSE** + la draft `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, fondata concettualmente su **OAuth 2.0 Token Exchange (RFC 8693)** e **SPIFFE/SPIRE** (graduato CNCF). La prima pubblicazione di riferimento da parte di un hyperscaler non-AI-lab (logistica/mobilità) che industrializza la sicurezza degli agenti a livello infrastrutturale, che chiude il vuoto dottrinale tra i framework di skill/harness (Vincent, Lattice, PROJ-AI) e le questioni di identità enterprise-grade.

## 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, identità degli agenti IA, crisi di identità degli agenti, definizione di agency, agente-come-delegato, workflow multi-hop, actor chain, preservazione della provenance, Zero Trust Architecture, Agent Registry, AI Agent Mesh, Security Token Service STS, MCP Gateway, AI Gateway, invocazione di tool MCP, identità di workload SPIRE, SPIFFE Verifiable IDs SVID, token JWT a breve durata, audience claim, token single-hop, scambio di token per hop, OAuth 2.0 Token Exchange RFC 8693, protocollo A2A agent-to-agent, Standardized A2A Client, BaseAgentProtocolClient, IETF WIMSE working group, draft-klrc-aiagent-auth-01, AI Agent Authentication and Authorization, agente ingegnere di guardia, Oncall Agent, Investigation Agent, Monitoring Agent, audit trail, policy di accesso granulare, policy enforcement point, redazione dei dati AI Guard, secure-by-default, latenza P99 40ms, identity trust foundation, dynamic access control, unified enforcement plane, three-layer framework, osservabilità degli agenti, audit governance, provenance degli agenti, catena di delega, credenziali di workload firmate crittograficamente, SPIFFE graduato CNCF, mappatura agente-workload, agenti interni Uber, migliaia di agenti in produzione, sicurezza dell'infrastruttura degli agenti, agent mesh, secure path easiest path, migrazione graduale degli agenti legacy, limiti del modello di identità, policy dei sistemi downstream, attribuzione contestuale

## 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

**Profilo**: articolo di engineering corporate tecnico-esplicativo, nel registro di un *blog engineering di hyperscaler*. Formato canonico Uber Engineering: esposizione didattica di una soluzione dispiegata in produzione, narrazione *problem-first* (due problemi identificati e nominati), diagrammi architetturali (Figure 1-4 citate), un esempio concreto di percorso multi-hop, metriche di validazione, visione a lungo termine. Nessun marketing dissimulato, nessuna iperbole — un registro da **memo tecnico operativo** destinato a ingegneri di sicurezza, architetti di piattaforma e tech lead.

**Stile**: voce plurale ingegnere-architetto (sei co-autori), nel registro **corporate anglosassone preciso** caratteristico di Uber Eng:
1. **Definizioni assiomatiche brevi** — *"An agent is best defined as an entity that is authorized to act for or in the place of another."* Una definizione di 18 parole che struttura tutto il resto del documento. Modalità proposizionale.
2. **Enumerazione ortogonale dei vincoli** — *"Delegation is the default mode... Workflows are compositional... Behavior is dynamic"* — tre proprietà mutuamente esclusive e collettivamente esaustive che giustificano la necessità di un nuovo modello di identità.
3. **Schema problema → componente → meccanismo → esempio → metrica** — ogni livello viene introdotto dal problema che risolve, poi specificato dal suo ruolo, poi dettagliato nella sua meccanica (token, claim, audience), poi istanziato da un percorso, poi validato da una misurazione. Pedagogia controllata a *zoom-in zoom-out*.
4. **Precisione lessicale** — *"short-lived tokens," "single-hop," "specific Audience claim," "time-to-live in the order of minutes," "cryptographically signed"* — vocabolario denso di termini tecnici precisi, senza parafrasi.

**Metafore e formule chiave**:
- ***"An agent is best defined as an entity that is authorized to act for or in the place of another"*** — la **definizione fondativa di agency** di Uber, che pone la delega come proprietà assiomatica dell'agente.
- ***"Execution context (originating user, intermediate agents) is dropped across agent hops"*** — una formula breve e operativa per inquadrare il problema della provenance.
- ***"Single-hop, short-lived tokens"*** — la formula-slogan dottrinale della soluzione, l'equivalente funzionale del classico *"least privilege"* dello Zero Trust adattato al regime agentico.
- ***"The secure path is also the easiest path for developers to implement A2A calls"*** — la dottrina di adozione: sicurezza per impostazione predefinita senza attrito per lo sviluppatore (un parallelo diretto con la classica *"paved road"* SRE).
- ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds"*** — la formula-metrica che chiude il dibattito "quest'architettura è praticabile alla scala di Uber?" — risposta: sì, con margine.

**Posizione epistemica**: gli autori parlano come **operatori di produzione** (migliaia di agenti interni, P99 misurato, dashboard di osservabilità esistente). Non teorizzano — **documentano una soluzione dispiegata**. Il tono è sicuro ma non trionfalista, con un riconoscimento esplicito che il lavoro continua (*"long-term vision,"* refactoring *"graduale"* degli agenti legacy).

**Autorità costruita tramite**: (a) **trazione in produzione** (cifre concrete — P99 <40ms, migliaia di agenti), (b) **profondità architetturale** (sei componenti nominate, meccanica crittografica esposta), (c) **allineamento agli standard** (SPIFFE/SPIRE graduato CNCF, RFC 8693, IETF WIMSE), (d) **composizione del team** (sei co-autori sul post — un segnale che si tratta di una piattaforma trasversale matura, non di un POC), (e) **tempistica** (pubblicato mentre la conversazione di settore sulla sicurezza degli agenti è ancora emergente — Uber si posiziona come riferimento).

**Pubblico e impatto atteso**: un articolo calibrato per **architetti di piattaforma e ingegneri di sicurezza** in grandi imprese che iniziano a dispiegare agenti IA internamente. Pubblico secondario: la comunità CNCF/SPIFFE, i contributori alle draft IETF WIMSE, i vendor MCP/gateway. Effetto atteso: diventare un **riferimento canonico** nella dottrina di sicurezza agentica del 2026, insieme alle pubblicazioni MCP di Anthropic, al Toolshed di Stripe e al lavoro edge di Cloudflare.

## Pense-betes

- **Fonte**: blog Uber Engineering (uber.com/blog), pubblicazione ufficiale. Articolo datato **21 maggio 2026** — 2 giorni prima della data di consultazione 2026-05-23.
- **Autori (sei co-autori)**:
- **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
- Team Security/Identity infrastructure di Uber, responsabile dell'architettura di identità degli agenti in produzione.
- **Tesi cardine epistemologica**: ***"An agent is best defined as an entity that is authorized to act for or in the place of another."*** Questa definizione pone la **delega** come proprietà assiomatica dell'agente — il che ribalta il modello di identità classico (umano o workload, ma mai *per conto di qualcun altro*).
- **Due problemi operativi nominati**: 1. **Current Identity Model Doesn't Describe Agency** — i framework di identità esistenti coprono umani e workload ma non modellano l'**agire per conto di** come modalità predefinita. Conseguenze:
- **La delega è la modalità predefinita** — gli agenti operano per conto di altri
- **I workflow sono composizionali** — gli agenti chiamano altri agenti, tool e sistemi
- **Il comportamento è dinamico** — i piani evolvono in base ai risultati intermedi 2. **Original Provenance Isn't Effectively Carried Forward Across Agents to Systems** — *"Execution context (originating user, intermediate agents) is dropped across agent hops."* Conseguenze:
- **Audit trail incompleti**
- **Enforcement incoerente** delle policy di accesso granulari
- Impossibilità di ragionare sull'intera catena di attori che ha originato una richiesta
- **Architettura — sei componenti nominate**: | Componente | Ruolo | |-----------|------| | **Agent Registry** | Fonte di verità per le mappature agente↔workload | | **AI Agent Mesh** | Data plane per la comunicazione inter-agente | | **STS (Security Token Service)** | Emette JWT brevi e ristretti (specifici per audience) | | **MCP Gateway** | Punto di enforcement delle policy per l'invocazione dei tool (tool MCP) | | **AI Gateway** | Mediazione delle chiamate ai modelli IA esterni + guardrail di sicurezza (AI Guard per la redazione) | | **SPIRE** | Fornitore di credenziali per i workload (estensione dell'infrastruttura Zero Trust esistente di Uber) |
- **Meccanica crittografica end-to-end**: 1. I workload recuperano **SVID (SPIFFE Verifiable IDs)** firmati crittograficamente da SPIRE. 2. L'SDK richiede **JWT** all'STS utilizzando l'identità del workload (l'SVID). 3. L'STS **verifica l'autorizzazione dell'agente** rispetto all'Agent Registry. 4. Vengono emessi **token a breve durata** per una **destinazione specifica a singolo hop** (claim `Audience` mirato, TTL **dell'ordine di minuti**). 5. Il token porta la **catena completa degli attori partecipanti** (la actor chain).
- **Dottrina "Single-hop, short-lived" (formula canonica)**: > *"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."* Conseguenze operative:
- **Il furto di un token ha un raggio d'impatto minimo** (TTL in minuti, audience unica)
- **Nessun bearer token cross-service riutilizzabile** — netto contrasto con l'OAuth classico
- **Ogni hop richiede un nuovo token** — overhead di rete compensato da una latenza <40ms
- **Percorso multi-hop canonico (esempio dell'articolo — Figura 4)**: 1. **user1** (ingegnere di guardia) avvia una sessione con l'**Oncall Agent** 2. L'**Oncall Agent** contatta l'STS, presenta la propria identità SPIRE (Workload-1) e richiede un JWT per l'**Investigation Agent** 3. L'Oncall Agent invia il JWT all'**Investigation Agent** (Workload-2) 4. L'**Investigation Agent** effettua uno **scambio di token** con l'STS per ottenere un'audience **MCP Gateway** 5. Il **MCP Gateway** riceve il JWT con la **catena di attori `[user1, oncall-agent, investigation-agent]`** — decisione di accesso a livello di tool basata sulla storia completa
- **Standardized A2A Client (SDK)**:
- Implementazione del **protocollo A2A** (Agent-to-Agent, uno standard emergente referenziato su GitHub).
- **Automatizza** gli scambi con l'STS, la costruzione della catena di attori e la propagazione tra hop.
- Dottrina di adozione: ***"the secure path is also the easiest path for developers to implement A2A calls"*** — sicuro per impostazione predefinita.
- Codice mostrato: una classe `BaseAgentProtocolClient` con metodi async (costruzione del contesto di autenticazione + chiamata all'agente).
- Migrazione graduale degli agenti legacy tramite refactoring.
- **Standard esterni allineati (da conoscere)**: | Standard | Ruolo | |----------|------| | **SPIFFE / SPIRE** | Framework di identità per workload — progetto **graduato CNCF** | | **OAuth 2.0 Token Exchange (RFC 8693)** | Base concettuale per lo scambio di token per hop | | **IETF WIMSE working group** | Workload Identity in Multi-System Environments — draft sull'identità degli agenti | | **draft-klrc-aiagent-auth-01** | Draft IETF *"AI Agent Authentication and Authorization"* | | **A2A Protocol** | Standard Agent-to-Agent (riferimento GitHub) |
- **Metriche di produzione (punti chiave)**:
- ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds"***
- **Migliaia di agenti interni** onboardati
- Dashboard di osservabilità in tempo reale che traccia le sessioni multi-agente
- Picchi occasionali ma costantemente <40ms al P99
- **Funzionalità di sicurezza derivate**:
- **Scambio di token per hop** — token validi solo per una destinazione specifica
- **Preservazione della catena di attori** — visibilità completa della lineage attraverso tutti i sistemi
- **Enforcement delle policy a livello di tool** — decisioni basate sulla storia completa della richiesta
- **Redazione dei dati via AI Guard** — informazioni sensibili filtrate al passaggio attraverso l'AI Gateway
- **Visione a lungo termine — Three-Layer Framework** (architettura target): 1. **Identity & Trust Foundation** — identità verificabile dell'agente + catene di delega 2. **Dynamic Access Control** — permessi basati sul contesto + opzioni human-in-the-loop + autorizzazione del workflow 3. **Unified Enforcement Plane** — decisioni di policy unificate + osservabilità + audit + governance ***"Long-term vision is a cohesive architecture where identity, risk, and policy work together seamlessly."***
- **Perché questo articolo è rilevante (posizionamento)**:
- **Prima pubblicazione di riferimento da parte di un hyperscaler non-AI-lab** (Uber = logistica/mobilità) che industrializza la sicurezza degli agenti a livello infrastrutturale.
- **Chiude il vuoto dottrinale** tra i framework di skill/harness (Vincent *Superpowers*, Lattice, PROJ-AI, Wescale Usine Logicielle Augmentée) che parlano di produttività, e le **questioni di identità enterprise-grade** che finora mancavano di una dottrina pubblica.
- **Si allinea agli standard emergenti** (SPIFFE/SPIRE già adottati, IETF WIMSE in corso) invece di inventare un protocollo proprietario — il classico schema *cathedral and bazaar* di Uber Eng.
- **Diventa un riferimento per i CISO** che affrontano il dispiegamento interno di agenti.
- **Articolazione del dossier**:
- **Famiglia immediata (infrastruttura di agenti enterprise)**:
- **Stripe Minions (Gray 2026-02-09 e 2026-02-19)** — fiche [gray-stripe-minions-coding-agents-part1-2026-02-09] e [gray-stripe-minions-coding-agents-part2-2026-02-19]: 1000-1300+ PR autonome/settimana, **Toolshed ~500 tool MCP**, devbox isolate. Stripe e Uber convergono sull'**industrializzazione degli agenti interni** — Stripe si concentra sugli agenti di coding e sul toolshed MCP, Uber si concentra sul **livello di identità** che rende governabili questi dispiegamenti.
- **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 predice; Uber **realizza**.
- **Thoughtworks AI/works™** (fiche [thoughtworks-aiworks-agentic-development-platform-2026-05-12]) — un Control Plane con *"active guardrails + end-to-end lineage."* Uber è l'**implementazione in produzione** di ciò che Thoughtworks vende come prodotto.
- **Famiglia MCP / tool**:
- **Anthropic 2026 Agentic Coding Trends Report** (fiche [anthropic-agentic-coding-trends-report-2026-02]) — democratizzazione e supervisione.
- **Cloudflare Markdown for Agents** (fiche [martinho-allen-cloudflare-markdown-for-agents-2026-02-12]) — conversione HTML-to-Markdown all'edge. Cloudflare e Uber affrontano due dimensioni distinte dell'infrastruttura degli agenti: forma dei dati (Cloudflare) vs identità (Uber).
- **Famiglia harness / architettura degli agenti**:
- **Trivedy *Anatomy of an Agent Harness*** (fiche [trivedy-langchain-anatomy-agent-harness-2026-03-10]) — Agent = Model + Harness. Uber aggiunge: l'harness ora include un **livello di identità dedicato, consapevole degli hop**.
- **Osmani *Agent Harness Engineering*** (fiche [osmani-agent-harness-engineering-2026-04-19]) — Uber è un esempio operativo di ciò che Osmani teorizza.
- **Seale *Semantic Agent: (Model+Harness) + (Ontology+Data)*** (fiche [seale-semantic-agent-model-harness-ontology-data-2026-04-17]) — Uber aggiunge una terza dimensione: *(Identity + Provenance)*.
- **Famiglia zero trust / sicurezza della piattaforma**:
- **Sierra AI-native interview** (fiches [sierra-ai-native-interview-iyengar-asemanfar-wang-2026-04-22] e [taylor-sierra-ai-native-interview-engineering-hiring-2026-04-20]) — assunzioni per le forze. Il profilo di ingegnere ricercato da Uber: Plan/Build/Review con competenze di sicurezza degli agenti.
- **Famiglia sovranità / difesa / rischio**:
- **Mensch / Mistral davanti alla commissione d'inchiesta dell'Assemblea Nazionale francese** (fiche [mensch-mistral-commission-enquete-vulnerabilites-numeriques-souverainete-ia-2026-05-13]) — *"economic security"* + *"cyber: linear offensive capabilities."* Uber mostra **come** proteggere le cose operativamente; Mensch mostra **perché** ciò conta strategicamente per la sovranità.
- **AISI UK GPT-5.5 cyber capabilities** (fiche [aisi-uk-gpt55-cyber-capabilities-evaluation-2026-04-30]) — modelli capaci di scoprire vulnerabilità. La difesa passa attraverso architetture come quella di Uber.
- **Sun *Permanent Underclass*** (fiche [sun-nyt-silicon-valley-permanent-underclass-2026-04-30]) — spostamento da lavoro a capitale. Uber illustra lo strato infrastrutturale del *"capitale"* che rende possibile l'automazione a scala.
- **Punti debili / domande aperte**:
- **Nessun dettaglio sul costo** dell'architettura (quanti server STS, quale QPS, quanti JWT emessi al giorno).
- **Nessuna cifra sulle perdite di produttività degli sviluppatori** dovute alla migrazione degli agenti legacy (quante PR di refactoring? durata totale?).
- **Posizione rispetto alle soluzioni vendor** (Auth0, Okta, ForgeRock) non discussa — Uber ha scelto di costruire internamente su SPIRE piuttosto che acquistare, ma senza esplicitare il ragionamento build-vs-buy.
- **Nessuna discussione sui failure mode** — cosa succede se l'STS va down? Quale modalità degradata? Quale circuit breaker?
- **Privacy / GDPR / dati personali** nella catena di attori — non affrontata (un ingegnere di guardia può essere tracciabile in modo identificabile attraverso tutti gli hop).
- **Nessuna discussione** su attacchi di confusione della catena di delega o injection di link falsi.
- **Il protocollo A2A** è citato come dipendenza esterna — ma la draft IETF non è ancora uno standard. Rischio: adozione precoce di un protocollo che potrebbe ancora evolvere.
- **Vocabolario Uber-eng da ricordare**: *agency (definizione di Uber)*, *single-hop short-lived tokens*, *actor chain*, *agent registry*, *AI agent mesh*, *secure path = easiest path*, *per-hop token exchange*, *provenance preservation*, *MCP gateway come policy enforcement point*, *AI gateway come livello di redazione*, *three-layer framework (identity / access / enforcement)*.
- **Utile per**:
- Presentazioni executive ai CISO sulla sicurezza degli agenti enterprise (riferimento canonico).
- Dottrina architetturale per clienti industriali che dispiegano agenti interni (≥100 agenti in flotta).
- Confronto build-vs-buy per soluzioni IAM agentiche.
- Argomento a favore di SPIFFE/SPIRE come standard **de facto** per l'identità dei workload (graduato CNCF + adottato da Uber).
- Riferimento in qualsiasi documento di pianificazione di piattaforme di agenti enterprise (control plane, livello di identità, osservabilità).
- Convergenza con la dottrina **Usine Logicielle Augmentée** di Wescale e con **AI/works™** di Thoughtworks sulla necessità di un "control plane" maturo.

## RésuméDe400mots

Sei ingegneri di **Uber** (Matt Mathew e altri) hanno pubblicato un articolo sul blog Uber Engineering il 21 maggio 2026, esponendo l'**architettura di identità e controllo degli accessi per agenti IA** dispiegata in produzione in Uber per **migliaia di agenti interni**. **Tesi cardine**: ***"an agent is best defined as an entity that is authorized to act for or in the place of another,"*** il che rende obsoleto il modello classico di identità umano+workload.

**Due problemi nominati**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — la delega è la modalità predefinita, i workflow sono composizionali, il comportamento è dinamico; (2) ***"Original Provenance Isn't Effectively Carried Forward Across Agents to Systems"*** — *"Execution context is dropped across agent hops"* — che crea lacune nell'audit e impedisce l'applicazione coerente di policy di accesso granulari.

**Architettura** come estensione della Zero Trust Architecture di Uber: **Agent Registry** (fonte di verità agente↔workload) + **AI Agent Mesh** (data plane inter-agente) + **STS (Security Token Service)** (emissione di JWT a scope ristretto) + **MCP Gateway** (enforcement delle policy per i tool) + **AI Gateway** (mediazione LLM + redazione via AI Guard) + **SPIRE** (fornitore di credenziali per i workload).

**Meccanica**: i workload recuperano **SPIFFE Verifiable IDs (SVID)** firmati crittograficamente da SPIRE → l'SDK richiede un JWT all'STS → l'STS verifica l'autorizzazione rispetto all'Agent Registry → viene emesso un **token a breve durata (TTL dell'ordine di minuti) per una destinazione specifica a singolo hop** (claim `Audience`). **Dottrina canonica**: ***"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."***

**Percorso multi-hop**: un ingegnere di guardia `user1` → Oncall Agent → Investigation Agent → MCP Gateway. Il JWT finale porta una **catena di attori verificabile `[user1, oncall-agent, investigation-agent]`** — decisioni di accesso a livello di tool basate sulla **storia completa** della richiesta.

**Standardizzazione**: un SDK **Standardized A2A (Agent-to-Agent) Client** automatizza gli scambi con l'STS e la propagazione della catena di attori — ***"the secure path is also the easiest path for developers to implement A2A calls."*** Migrazione graduale degli agenti legacy.

**Metriche di produzione**: ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds,"*** migliaia di agenti interni onboardati, osservabilità in tempo reale.

**Visione a lungo termine — framework a tre livelli**: (1) Identity & Trust Foundation, (2) Dynamic Access Control, (3) Unified Enforcement Plane.

**Standard esterni**: SPIFFE/SPIRE (graduato CNCF), OAuth 2.0 Token Exchange (RFC 8693), working group IETF WIMSE, draft `draft-klrc-aiagent-auth-01`, protocollo A2A.

**Rilevanza**: la prima pubblicazione di riferimento da parte di un hyperscaler non-AI-lab che industrializza la **sicurezza degli agenti a livello infrastrutturale**, che chiude il vuoto dottrinale tra i framework di skill/harness (produttività) e le questioni di **identità enterprise-grade** (governabilità). Diventa un riferimento canonico per architetti di piattaforma, ingegneri di sicurezza e CISO che affrontano il dispiegamento interno di agenti.

## 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/it/fiches/uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21/