La lethal trifecta: il triangolo del fuoco degli agenti AI
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.
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.
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 →