La sicurezza degli agenti AI parte da una regola: il tuo agente AI non dovrebbe mai detenere le tue credenziali. Ecco il pattern del broker, vecchio di 38 anni, che la fa rispettare.
Gli agenti AI sono dei vice confusi. È un pattern di sicurezza vecchio di 38 anni, e la risposta è altrettanto antica: metti un broker — un livello intermedio fidato, osservabile, deterministico, verificabile, non falsificabile, a portata ristretta, guidato da policy e non basato su AI — tra l'agente e le API SaaS che deve chiamare, facendogli detenere le credenziali che il tuo agente non dovrebbe avere.
Nel 1988, Norm Hardy pubblicò un breve paper che descriveva un incidente reale dei suoi tempi alla Tymshare. Un compilatore Fortran chiamato FORT risiedeva in una directory di sistema chiamata SYSX. Per raccogliere statistiche d'uso, il compilatore aveva bisogno di scrivere su (SYSX)STAT, quindi il sistema operativo aveva concesso a FORT una "home files license", autorizzandolo a scrivere qualsiasi file all'interno di SYSX. Anche il file di fatturazione del sistema, (SYSX)BILL, risiedeva lì. Un utente che invocava il compilatore poteva fornire un nome di file per ricevere un output di debug opzionale. Un giorno un utente fornì (SYSX)BILL. Il compilatore chiese al sistema operativo di aprire quel file in scrittura; il sistema operativo, osservando la home files license, lo permise. I dati di fatturazione vennero sovrascritti. Il compilatore fece esattamente ciò per cui era stato progettato. Il difetto era architetturale.
Hardy lo chiamò il problema del vice confuso (confused deputy problem): un programma privilegiato (il vice) detiene un'autorità propria; un chiamante meno privilegiato gli chiede di fare qualcosa; il vice si confonde su per conto di chi sta agendo e usa la propria autorità. La soluzione è togliere del tutto quell'autorità al vice e metterla dietro un livello separato che media la chiamata su richiesta. Quel livello è il broker.
Trentotto anni dopo, ogni agente AI che la tua azienda esegue è un vice confuso. E la maggior parte di essi gira senza un broker.
Perché gli agenti AI peggiorano il problema di sicurezza
Il FORT di Hardy aveva un solo canale di input: la riga di comando. Un agente AI moderno ne ha decine: corpi di email, pagine web recuperate, PDF caricati, output di strumenti da server MCP, messaggi da agenti peer in un sistema multi-agente. Qualsiasi cosa che finisce nella finestra di contesto può impartire istruzioni, e per progettazione l'agente le tratta tutte come legittime.
Questo rompe un'assunzione da cui dipende il controllo degli accessi tradizionale: il chiamante controlla l'input. In un'app web, il chiamante (la sessione autenticata) e l'input (il corpo della richiesta HTTP) provengono dallo stesso posto. Per un agente, il chiamante è chiunque dia forma al prompt, il che significa che un aggressore in grado di scrivere un'email o di seminare un risultato di ricerca è anch'esso un chiamante.
Nel novembre 2025, i ricercatori di sicurezza di PromptArmor hanno mostrato come appare questo in produzione. Hanno nascosto istruzioni malevole in font da 1 pixel in una guida di integrazione. Quando uno sviluppatore ha puntato l'IDE Antigravity di Google su di essa, l'agente ha aggirato la propria protezione dei file basata su .gitignore invocando cat da shell. Poi ha trafugato il contenuto dei file .env verso un URL webhook.site controllato dall'aggressore tramite il subagente browser di Antigravity stesso. L'utente aveva impostato tutto correttamente. La sandbox ha retto. L'agente semplicemente non riusciva a distinguere ciò che l'utente aveva chiesto da ciò che l'input gli diceva di fare.
Stessa forma del FORT di Hardy, decenni dopo: autorità ampia, input non fidato, nessun modo per separare i due.
La community ha le risposte. Sono solo sparse.
Questo non è un problema nuovo. La community della sicurezza scrive risposte da decenni:
Capability-based security (Dennis & Van Horn, 1966; più tardi il linguaggio E e il lavoro su Caja di Mark Miller in Google). Il principio: non concedere autorità ambientale in base a identità o posizione; passa capability esplicite e non falsificabili per ogni risorsa che il programma può toccare. Una capability lega ciò che puoi fare a ciò su cui puoi farlo, e non può essere confusa con nient'altro.
Brokered Credentials (codificate dalla OWASP LLM Top 10). Non mettere i token API nel contesto dell'LLM. Un livello intermedio fidato effettua la chiamata per conto dell'agente; il modello decide cosa fare, il broker gestisce il come. Una prompt injection che chiede al modello di stampare le sue credenziali non ottiene nulla di utile. Le credenziali non sono lì.
Il Phantom Token Pattern (Curity, originariamente per OAuth nei microservizi). L'agente detiene un handle di sessione opaco, non il vero bearer token. Un proxy convalida l'handle, sostituisce la credenziale reale al confine di rete e inoltra a monte. Se l'agente fa trapelare il suo ambiente, l'aggressore ottiene una stringa che scade alla fine della sessione.
Just-in-time credential injection (sistemi di workload identity come Aembit). Coniare una credenziale a vita breve e a portata ristretta per ogni chiamata, invece di emettere token a vita lunga.
Nulla di tutto questo manca nella letteratura. Manca nei default. La maggior parte delle piattaforme di agenti consegna ancora al modello un token OAuth, senza alcun broker in mezzo, sperando che vada bene.
Come funziona il broker di Zero
Non abbiamo inventato nessuno dei pattern qui sopra. Li abbiamo collegati in un unico broker che gira per impostazione predefinita per ogni agente su Zero. È il livello intermedio fidato che quei pattern descrivono, costruito per una piattaforma di agenti AI. Ogni chiamata che un agente fa a un connettore passa attraverso di esso. Ogni connettore è un singolo SaaS esterno (Slack, GitHub, Notion e così via).
Il broker si trova tra ogni agente e ogni connettore. Le credenziali reali vivono solo dal lato broker della linea tratteggiata.
Pensalo come tre livelli.
1. Isolamento delle credenziali
La sandbox dell'agente non detiene mai una credenziale reale di un connettore. Quando colleghi un SaaS a Zero, il token OAuth o la chiave API vivono dal lato del broker. La sandbox riceve una stringa segnaposto che assomiglia abbastanza a un secret d'ambiente da far continuare a funzionare gli strumenti esistenti, ma che nessun SaaS a monte accetterebbe.
Quando l'agente effettua una richiesta a un host di connettore registrato, il broker abbina la richiesta, risolve il template di autenticazione del connettore e inietta la credenziale reale al confine di rete. La richiesta va a monte con un'autenticazione valida; l'agente non ha mai detenuto nulla di utile. Un agente vittima di prompt injection che svuota le sue variabili d'ambiente consegna all'aggressore un segnaposto, non il token del SaaS.
Questo è il phantom token pattern, applicato agli agenti AI.
2. Gate delle policy del connettore
Un connettore in Zero dovrebbe essere più di un semplice interruttore on/off. Ogni connettore descrive le basi API che copre e come dovrebbe essere iniettata l'autenticazione. Dove il servizio a monte pubblica una mappatura stabile da scope a endpoint, può anche descrivere quale permesso nominato copre ciascun metodo e percorso. La slack-api-ref di Slack è un buon esempio.
Così quando un agente collegato a Slack chiama chat.postMessage, il broker può mappare quella richiesta su chat:write. Quando legge i log di audit, è admin.analytics:read. Per ogni agente, permission_policies definisce come si comportano quei permessi nominati: consenti, nega o chiedi. La policy viene applicata al broker prima dell'iniezione dell'autenticazione, non come suggerimento al modello. Se l'agente tenta di effettuare una chiamata coperta da un permesso negato, magari perché è stato vittima di prompt injection, la chiamata non raggiunge mai la rete a monte.
Non tutti i connettori ottengono oggi quella risoluzione. Alcune API a monte non pubblicano una mappatura stabile da scope a endpoint. La superficie GraphQL di GitHub è il caso emblematico: il lato REST può essere mappato, ma il lato GraphQL non ancora. Per quei connettori, il broker controlla comunque l'iniezione delle credenziali e il percorso di rete, mentre il gate dei permessi ripiega sulla policy più grossolana a livello di connettore o host che la piattaforma può effettivamente applicare. Li completiamo man mano che i dati a monte diventano disponibili. Non rivendichiamo una copertura che non abbiamo costruito.
I token non portano autorità ambientale. L'autorità è brokerata per ogni agente, alla risoluzione che il monte supporta. Questa è la metà capability-based della risposta.
3. Loop operativo e audit
Il privilegio minimo funziona solo se la modalità di errore è utilizzabile. Gli agenti crescono. Dopo sei settimane, un agente di ricerca che ha iniziato leggendo da Notion potrebbe aver bisogno di riscriverci un riepilogo. Le modalità di errore comuni altrove: l'agente gira silenziosamente senza il nuovo permesso e si rompe, oppure l'operatore concede troppo nel panico e non lo revoca mai.
Una richiesta di connettore negata restituisce un 403 strutturato: connettore, metodo, percorso, URL base e i nomi dei permessi corrispondenti quando il broker riesce a identificarli. Il system prompt dell'agente gli dice come diagnosticare il diniego e come chiedere esattamente il permesso che ha appena incontrato, producendo un URL di concessione con un clic per l'utente o l'amministratore. Questo mantiene il percorso di escalation legato all'esatto permesso richiesto, invece di trasformarsi in "concedi tutto e basta".
Le richieste di modifica dei permessi restano in coda. Proprietari e amministratori possono approvarle o rifiutarle dalla dashboard; le richieste approvate aggiornano la policy dell'agente, e il successivo tentativo va a buon fine. La maggior parte delle piattaforme salta questo loop. Senza di esso, il "privilegio minimo" resta sulla slide invece di girare in produzione.
Lo stesso percorso del broker alimenta l'audit. I log di rete per esecuzione registrano l'attività di rete della sandbox su HTTP, TCP, DNS e osservazioni di pacchetti di livello più basso per il traffico non-TCP. Le richieste abbinate a un connettore includono metadati strutturati del broker: connettore, permesso corrispondente quando disponibile, esito consenti/nega, metadati di risoluzione dell'autenticazione e flag di fatturabilità. Se qualcuno più tardi chiede "cosa ha fatto questo agente martedì alle 15?", ricostruisci la risposta da quei record. La prevenzione si lascia sfuggire delle cose. La traccia di audit è il modo in cui scopri cosa.
Cosa non abbiamo risolto
Anche con tutto quanto sopra, un agente con un legittimo chat:write può comunque essere convinto a pubblicare un messaggio imbarazzante in un canale a cui ha già accesso. Il broker restringe il raggio d'impatto; non lo elimina.
L'altra metà della risposta è l'approvazione delle azioni ad alto rischio, la validazione dell'output e il trattare per impostazione predefinita i ritorni degli strumenti come non fidati. Quel lavoro è nella roadmap, non ancora nel prodotto. Chiunque affermi di aver risolto il vice confuso end-to-end ti sta vendendo qualcosa.
Questo dovrebbe essere la base, non una funzionalità
La capability-based security esiste dagli anni '70. Le brokered credentials sono nella OWASP LLM Top 10. I phantom token precedono l'era degli LLM. Nulla di tutto questo manca perché nessuno conosceva la risposta. Manca perché le prime piattaforme di agenti hanno ottimizzato per "far funzionare la demo" e hanno rimandato la sicurezza a una release successiva, che spesso non è mai arrivata.
La prossima generazione di piattaforme dovrebbe puntare più in alto. I token non dovrebbero entrare nel contesto del modello. L'autorità dovrebbe essere enumerata per ogni agente. L'escalation dei privilegi dovrebbe passare per un essere umano. Ogni azione dovrebbe essere verificabile end-to-end. Nulla di tutto questo è inedito. Tutto dovrebbe essere il punto di partenza.
Quando scegli una piattaforma di agenti, "è sicura?" non ti porta da nessuna parte. Ogni fornitore dice di sì. Una domanda migliore: mostrami il tuo broker e spiegami passo per passo cosa succede quando un agente chiede uno scope che non ha.
Il broker si trova davanti a ogni agente su Zero per impostazione predefinita. L'inventario dei connettori, le mappature degli scope, le policy dei permessi e la logica del broker vivono tutti nel repository sorgente di Zero. Hai trovato un connettore che non abbiamo coperto? Apri una issue.
Riferimenti
Fondamentali
- Norm Hardy, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review 22(4), 1988. DOI 10.1145/54289.871709
- Dennis & Van Horn, Programming Semantics for Multiprogrammed Computations, CACM 1966 (il paper fondativo dei sistemi a capability)
- Mark Miller et al., Caja: capability-based security per il web, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
Incidenti reali citati
- PromptArmor, Google Antigravity Exfiltrates Data, novembre 2025
- Simon Willison, copertura e analisi, 25 novembre 2025
