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.
#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
Riassunto
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.
Punti chiave
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)
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.
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.
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.