La lethal trifecta: il triangolo del fuoco degli agenti AI
Ogni corso antincendio comincia dal triangolo del fuoco: combustibile, comburente, innesco. Servono tutti e tre — togli un lato qualsiasi e l'incendio non parte. Per gli agenti AI esiste l'equivalente esatto: Simon Willison l'ha chiamata lethal trifecta, ed è la griglia più utile che abbiamo per valutare la sicurezza di qualunque deployment agentico.
I tre lati del triangolo
La trifecta è la compresenza, nello stesso agente, di tre capacità:
- Accesso a dati privati — l'agente può leggere informazioni riservate: email, documenti, repository, database, CRM.
- Esposizione a contenuti non fidati — nel contesto dell'agente arrivano testi che non controlli: una email in ingresso, una pagina web, una issue su GitHub, un allegato.
- Comunicazione verso l'esterno — l'agente può far uscire informazioni: inviare email, fare richieste HTTP, pubblicare, committare.
Prese una per una, sono capacità normali — anzi, sono esattamente ciò che rende utile un agente. Il problema è la combinazione, e la ragione è strutturale: un modello linguistico esegue le istruzioni che trova nel contenuto che legge, e non sa distinguere in modo affidabile fra le istruzioni del suo operatore e quelle che un attaccante ha nascosto in un testo qualsiasi. È la prompt injection indiretta— parente dell'SQL injection: mescolare contenuto fidato e non fidato nello stesso canale. Se l'agente legge dati riservati, incontra un contenuto ostile e può scrivere fuori, l'attaccante ha tutto quello che gli serve: le sue istruzioni diventano ordini, e il canale di uscita diventa il tubo di esfiltrazione.
Non è teoria: il caso GitHub MCP
Nel maggio 2025 i ricercatori di Invariant Labs hanno mostrato l'attacco completo contro uno degli strumenti agentici più diffusi, il server MCP di GitHub. Il setup è quello di migliaia di sviluppatori reali: un repository pubblico dove chiunque può aprire issue, un repository privato con il codice proprietario, e un agente che accede a entrambi con lo stesso token.
L'attaccante apre nel repo pubblico una issue apparentemente innocua ("About The Author") che contiene istruzioni nascoste. Lo sviluppatore, ignaro, chiede al suo assistente: "dai un'occhiata alle issue aperte". L'agente legge la issue, viene iniettato, pesca dati dal repository privato — nella dimostrazione: informazioni personali, piani riservati, perfino lo stipendio dell'utente — e li pubblica in una pull request sul repo pubblico, dove l'attaccante li legge comodamente.
Il punto cruciale: non c'era nessun bug da patchare. Il server MCP ha funzionato esattamente come progettato; ogni singola azione era legittima e autorizzata dal token. Era l'architettura a essere sbagliata: dati privati, contenuto ostile e canale di uscita nella stessa sessione. Triangolo completo, incendio garantito. E GitHub MCP è solo il caso più didattico di una lista lunga: vulnerabilità della stessa classe sono state documentate in Microsoft 365 Copilot, GitLab Duo, ChatGPT, Slack, Amazon Q.
Perché i guardrail non bastano
La risposta istintiva del mercato è "mettiamo un filtro che riconosce le prompt injection". Willison è tranchant su questo punto, e ha ragione: i vendor che promettono di bloccare "il 95% degli attacchi" stanno dichiarando un fallimento, non un successo. In sicurezza applicativa un filtro che lascia passare un attacco su venti non è una difesa: è una lotteria. Nessuno accetterebbe un firewall così. La prompt injection non è un input malformato da riconoscere: è linguaggio naturale, infinitamente riformulabile, indistinguibile per costruzione dal contenuto legittimo.
La difesa robusta non è probabilistica ma strutturale: come per il triangolo del fuoco, non serve spegnere l'incendio — serve togliere un lato.
Spezzare il triangolo
Un lato qualsiasi. Quale togliere dipende dal caso d'uso:
- Togliere i dati privati — l'agente che processa contenuti esterni (email in ingresso, web, documenti di terzi) lavora con il minimo indispensabile: privilegio minimo per strumento, come abbiamo visto parlando di identità agentiche. Il token che legge le issue pubbliche non deve poter aprire il repository privato: la mitigazione proposta da Invariant — un solo repository per sessione — è esattamente questo.
- Togliere il contenuto non fidato — l'agente che lavora su dati riservati non legge input arbitrari dall'esterno. Se deve farlo, il contenuto ostile va trattato come tale: quarantena, contesti separati, un agente "sporco" che legge e un agente "pulito" che agisce, senza che le istruzioni del primo raggiungano il secondo.
- Togliere l'uscita autonoma — le azioni verso l'esterno (inviare, pubblicare, committare) richiedono approvazione umana o passano da una allow-list di destinazioni. L'esfiltrazione fallisce se il tubo di uscita ha un rubinetto che l'agente non controlla.
La regola operativa che ne discende è una sola: mai i tre lati completi nella stessa sessione. È una proprietà architetturale, verificabile a tavolino — non una speranza sul comportamento del modello.
La griglia da applicare lunedì mattina
Il valore pratico della trifecta è che trasforma una valutazione di sicurezza complessa in tre domande che chiunque può porre, per ogni agente in azienda:
- A quali dati riservati accede?
- Può leggere contenuti che non controlliamo?
- Può scrivere, inviare o pubblicare verso l'esterno?
Tre sì = triangolo completo = riprogettare, prima che l'innesco arrivi. Due sì o meno = il rischio è gestibile con i controlli ordinari. Non serve un red team per fare questo screening: serve farlo, su ogni agente, ogni volta che gli si aggiunge uno strumento.
Secondo articolo della serie sulla sicurezza agentica. Il primo: l'agente AI come utenza privilegiata. Il prossimo e ultimo: se il perimetro non regge a livello di agente, l'autorizzazione deve spostarsi sul dato — data-centric security nell'era agentica.
Fonti
Quanti triangoli completi ci sono nei tuoi agenti?
Tomato applica la griglia della trifecta ai deployment agentici delle PMI: mappatura di dati, input e canali di uscita per ogni agente, e riprogettazione dei flussi dove il triangolo si chiude.
Parla con noi →