Sconfiggere la letale tripletta: come Asana pensa alla sicurezza dell'IA agentica
L'IA agentica introduce una classe di rischi per la sicurezza che il settore non ha risolto. Ecco cosa pensiamo in Asana e le invarianti di sicurezza che applichiamo a tutte le nostre funzionalità di IA.
Il problema
I sistemi di IA agentica non si limitano a rispondere alle domande. Leggono documenti, eseguono azioni e coordinano gli strumenti. Più cose possono fare, più ampia è la loro superficie di attacco.
A differenza del codice convenzionale, gli LLM hanno una proprietà che rende questo aspetto fondamentalmente difficile: non sono in grado di distinguere in modo affidabile le istruzioni dai dati. Tutto ciò che viene fornito a un LLM finisce nello stesso flusso, quindi un dato creato con cura può dirottare il modello nello stesso modo in cui farebbe un'istruzione legittima. Questa è la base della prompt injection, ciò che Simon Willison chiama "il peccato originale" delle applicazioni basate su LLM.
Non è una cosa teorica. I ricercatori hanno dimostrato questa classe di attacco contro Microsoft 365 Copilot, il server MCP di GitHub, Slack AI e molti altri. Bruce Schneier l'ha detto senza mezzi termini: il settore non dispone ancora di solide difese contro questa classe di attacchi.
Quindi, come si fa a costruire un'IA agentica in modo responsabile quando il settore non ha ancora capito i fondamenti?
La tripletta letale
Willison sintetizza il rischio principale in tre capacità che, combinate, creano le condizioni per il danno:
Accesso ai dati sensibili. L'agente può leggere informazioni riservate o private.
Esposizione a contenuti non attendibili. L'operatore elabora input che possono contenere istruzioni ostili nascoste.
La capacità di comunicare esternamente. L'agente può inviare informazioni al di fuori del sistema.
Un'utile precisazione sulla terza condizione: si tratta in realtà della capacità di creare effetti collaterali, non solo di comunicazione in uscita. L'esfiltrazione di dati verso il server di un utente malintenzionato è l'esempio classico, ma un'istruzione dannosa che rinomina silenziosamente ogni progetto in uno spazio di lavoro o invia contenuti sensibili al canale interno sbagliato rappresenta lo stesso tipo di problema. Usiamo "comunicazione esterna" come abbreviazione, ma in realtà ci difendiamo da una versione più ampia.
Qualsiasi elemento del trio è gestibile. Di solito lo sono anche due insieme. Ma quando tutte e tre convergono, hai un percorso di attacco praticabile.
L'approfondimento importante: interrompere una qualsiasi delle fasi riduce sostanzialmente il rischio complessivo. Non è necessario risolvere perfettamente il problema del prompt injection. Nessuno ci è riuscito. Dobbiamo assicurarci che tutte e tre le condizioni non possano coesistere facilmente.
Korny Sietsma parte da questo presupposto, mappando la trifecta a misure di mitigazione come il sandboxing, la scomposizione delle attività, i privilegi minimi e l'human-in-the-loop. Questi sono gli elementi costitutivi. La domanda è come renderli operativi.
Contesto, check point e controlli
Organizziamo il nostro pensiero attorno a tre pilastri che corrispondono direttamente alla tripletta letale. Ognuno di essi limita una gamba.
Asana ha diverse interfacce IA. Gli AI Teammates sono partecipanti agentici con il proprio stato di appartenenza e le proprie autorizzazioni nello spazio di lavoro. Altre funzionalità di IA operano come l'utente, con il limite rappresentato da ciò a cui quell'utente può già accedere. Le invarianti riportate di seguito si concentrano sul caso agentico, in cui la superficie è più ampia, e indicheremo dove l'implementazione differisce in base alla superficie.
Contesto: gestire ciò che l'IA può vedere
Parte della trifecta: accesso ai dati sensibili
Affinché l'IA agentica sia utile, ha bisogno di contesto. La sfida è darle abbastanza informazioni da essere utile senza consegnarle un passepartout.
Il nostro invariante fondamentale è il principio dei privilegi minimi, la cui espressione esatta dipende dalla superficie. Per gli AI Teammates, che hanno la propria appartenenza separata da qualsiasi singolo utente, il limite è l'intersezione tra le autorizzazioni del collega del team e quelle dell'utente. Per le funzionalità di IA che operano come l'utente, il limite è semplicemente l'accesso di quell'utente. In ogni caso, lo stesso livello di autorizzazione lato server che regola tutte le altre interazioni su Asana regola l'accesso dell'IA. Le funzionalità di IA non ottengono autorizzazioni elevate. Operano all'interno del sistema di controllo degli accessi di Asana, non al di fuori di esso.
Definire il contesto non significa solo regolare l'accesso ai dati interni all'interno di Asana; comprende anche le integrazioni esterne con cui un agente può interagire. Sebbene le integrazioni attualmente richiedano l'autorizzazione esplicita dell'utente, stiamo sviluppando percorsi di controllo granulari e specifici per l'agente. Ciò consente alle organizzazioni di limitare i privilegi di integrazione per gli AI Teammate che gestiscono input ad alto rischio. Il nostro invariante architettonico principale è chiaro: il limite di ciò che un'IA può vedere deve essere dinamico e guidato dai proprietari dei dati, piuttosto che essere un'impostazione predefinita del prodotto codificata.
Anche se un utente malintenzionato introduce istruzioni dannose nel contesto dell'IA, ciò che l'IA può effettivamente vedere è limitato dallo stesso modello di autorizzazione di tutto il resto.
Check point: filtra ciò che l'IA ascolta
Tappa della trifecta: esposizione a contenuti non attendibili
Questa è la tappa più difficile. In una piattaforma di gestione del lavoro, la maggior parte di ciò che l'IA legge è contenuto generato dagli utenti: attività, commenti, documenti allegati. Una parte proviene dall'esterno dell'organizzazione. Non puoi rifiutarti di leggerlo.
Stabiliamo invece dei check point: punti in cui distinguiamo l'intento affidabile dal contenuto arbitrario e in cui gli esseri umani possono intervenire se qualcosa sembra sbagliato.
Gestione delle istruzioni basata sulla fonte. Le funzionalità di IA etichettano il contenuto in base all'affidabilità dell'autore e alla fonte, in modo che il modello possa dare più peso alle istruzioni provenienti da utenti autorizzati rispetto a quelle presenti in contenuti arbitrari lungo il percorso. Questo riduce la superficie di attacco per l'iniezione di prompt, ma non la chiude; il modello legge comunque tutto nel suo contesto e la garanzia di sicurezza è parziale piuttosto che assoluta. Di seguito, discutiamo i limiti di questo approccio.
Registrazione e indagine forense. Ogni chiamata al modello viene registrata con i relativi input, output, attore, contesto della funzionalità ed eventi a valle, compresi gli oggetti del work-graph toccati da un'automazione e gli URL apparsi nell'output. Avvisiamo automaticamente in caso di segnali operativi come tassi di errore e picchi di costi. Per le anomalie rilevanti per la sicurezza, quegli stessi registri supportano le indagini post-hoc da parte di esseri umani. Come osserva Willison, anche il rilevamento basato su modelli che intercetta la maggior parte degli attacchi sarebbe di per sé un insuccesso; la visibilità e la capacità di indagare sono le fondamenta solide su cui costruiamo, non il muro.
Progettazione Human-in-the-loop. Le funzionalità di intelligenza artificiale mostrano il loro lavoro per la revisione umana, invece di intraprendere azioni irreversibili in modo silenzioso.
Scomposizione delle attività e azioni limitate. I flussi di lavoro complessi sono suddivisi in fasi più brevi e le azioni disponibili per le funzionalità di IA sono intenzionalmente limitate piuttosto che aperte.
Nessuna di queste opzioni è infallibile se presa singolarmente. Insieme, formano una difesa in profondità.
Controlli: limitare ciò su cui l'IA può intervenire
Terza tappa: la capacità di creare effetti collaterali
La terza gamba è il punto in cui si verifica la maggior parte degli attacchi nel mondo reale. Se un utente malintenzionato convince un'IA a incorporare dati sensibili in un URL, a inviarli tramite un'integrazione o a modificare un record su cui fanno affidamento altre persone, l'attacco ha successo.
In questo caso, investiamo in diverse categorie di controllo:
Trattare l'output dell'LLM come non attendibile. Il contenuto generato non riceve un aumento di affidabilità perché è stato prodotto da Asana AI. Segue gli stessi percorsi di convalida e rendering di qualsiasi altro contenuto generato dagli utenti.
Approvazione umana obbligatoria per le azioni di grande impatto. Alcune categorie di azioni richiedono sempre un'approvazione umana esplicita, indipendentemente dal livello di sicurezza dell'IA o da quanto la richiesta sembri di routine. Per gli AI Teammate, ciò include le azioni che aumentano il livello di accesso (modifica delle autorizzazioni, aggiunta di membri) e le azioni che distruggono i dati (eliminazioni). L'IA può proporle, ma non può eseguirle autonomamente.
Misure di sicurezza per la gestione dei link. Gli URL esterni nel contenuto generato dall'IA vengono elaborati prima di raggiungere un utente. I nuovi URL che non apparivano nell'input vengono sottoposti a un ulteriore controllo e vengono visualizzati nella loro forma completa e non oscurata, piuttosto che come testo di collegamento rietichettato, in modo che l'IA non possa essere utilizzata come arma per mascherare un endpoint di esfiltrazione con un amichevole "clicca qui per il riepilogo".
Nessun HTTP in uscita generico. Le funzionalità di IA non dispongono di una primitiva aperta del tipo "invia una richiesta a qualsiasi URL". Le integrazioni esterne passano attraverso canali delimitati con la propria autorizzazione.
Audit trail delle azioni. Ogni scrittura, modifica e azione in uscita eseguita da una funzionalità di IA viene registrata insieme alla chiamata del modello che l'ha generata, in modo che un investigatore possa ricostruire ciò che un'IA ha fatto, non solo ciò che le è stato chiesto.
L'obiettivo non è rendere impossibile la comunicazione esterna. Le funzionalità di IA devono fare riferimento a collegamenti, aggiornare attività e produrre output utili. L'obiettivo è assicurarsi che non possano farlo di nascosto in un modo che l'utente non intendeva.
Un pattern per i valori emessi dall'IA
All'interno di questo quadro, continua a presentarsi lo stesso sotto-problema concreto: una funzionalità di IA produce qualcosa (un identificativo di oggetto, un destinatario, un URL) e il codice a valle agisce su di esso, spesso con autorizzazioni più ampie rispetto alla stessa IA. Le allucinazioni e le iniezioni di prompt finiscono nello stesso posto: un valore emesso dal modello viene considerato attendibile.
Utilizziamo un modello in quattro parti come checklist di revisione della progettazione per questi valori:
Limitare ciò che l'IA è autorizzata a produrre in primo luogo, prima che la convalida debba essere eseguita.
Convalida ogni valore prodotto dall'IA sul lato server rispetto allo stesso livello di autorizzazione di tutto il resto. Il modello è trattato come un client non attendibile.
Giustificare la scelta mantenendo un contesto strutturato sufficiente a spiegare perché l'IA ha scelto ciò che ha scelto. È ciò che rende possibili in seguito le indagini, le valutazioni e la risposta agli incidenti.
Effettuare l'escalation con attrito, fallback o revisione umana quando un valore è ad alto rischio o al di fuori dell'ambito previsto.
Il filo conduttore: il comportamento del modello non dovrebbe essere il controllo di sicurezza principale. Prompt migliori e “abbiamo detto al modello di non farlo” sono utili difese in profondità, ma i controlli duraturi si trovano nel sistema intorno al modello.
Basato su principi
Queste scelte non sono ad hoc. Derivano dai principi sull'IA pubblicati da Asana.
Le persone sono responsabili delle decisioni che guidano la progettazione orientata ai checkpoint. L'IA aiuta, ma gli esseri umani restano aggiornati e sono responsabili.
Ci impegniamo per la sicurezza, il che giustifica l'investimento in controlli a più livelli anche quando aggiungono attrito. L'alternativa aumenta il rischio man mano che le funzionalità di IA si occupano di attività più complesse.
Promuoviamo la trasparenza, motivo per cui stiamo scrivendo questo post. Non abbiamo risolto il problema della sicurezza dell'IA agentica. Ma essere aperti su come ragioniamo su questi rischi e sulle misure di mitigazione che adottiamo aiuta la comunità più ampia a fare progressi in una sfida condivisa e invita all'esame che ci rende migliori.
I limiti onesti
La prompt injection è ancora fondamentalmente irrisolta e la prompt injection indiretta (le istruzioni ostili arrivano incorporate nel contenuto che l'IA recupera durante il suo lavoro, piuttosto che nel contenuto che un utente le fornisce direttamente) è la variante che ha colpito più duramente il settore nel 2026. L'etichettatura basata sulla fonte è utile, ma non colma completamente questa lacuna, perché il modello deve comunque scegliere di rispettare le etichette. I nostri check point riducono significativamente il rischio, ma non lo eliminano. Finché le istruzioni e i dati condividono una finestra di contesto, gli input ostili recuperati tramite ricerca, moduli pubblici o integrazioni a volte riusciranno a passare inosservati. Consideriamo questo aspetto come un'area di investimento attiva e continua, con un esame più approfondito di qualsiasi percorso che consenta al contenuto creato esternamente di raggiungere una funzionalità agentica. Il lavoro sui modelli di progettazione per la protezione degli agenti LLM indica direzioni promettenti, ma il consenso del settore è ancora in fase di definizione.
Il panorama delle minacce si evolve rapidamente. Continuano a comparire nuovi vettori, dall' iniezione invisibile di prompt basati su immagini alle catene di esfiltrazione in più fasi. Progettiamo i controlli in modo che siano stratificati e componibili, così da poter aggiungere nuove misure di mitigazione man mano che emergono nuove minacce. È una corsa agli armamenti, non un problema che si risolve una volta per tutte. I 10 principali rischi OWASP per le applicazioni LLM sono un utile riferimento costante.
Non vediamo queste lacune come motivi per rallentare. Le consideriamo motivi per agire in modo consapevole. La tripletta letale ci dice qual è la posta in gioco. Contesto, check point e controlli ci forniscono un framework per l'azione. E poiché nessun team risolve questo problema da solo, stiamo investendo attivamente insieme ai nostri partner di ricerca e ai nostri clienti per rafforzare queste superfici man mano che il panorama delle minacce si evolve.
Riferimenti
Simon Willison, “The lethal trifecta for AI agents”, giugno 2025
Korny Sietsma, “Agentic AI and Security”, Martin Fowler, ottobre 2025
Bruce Schneier, “We Are Still Unable to Secure LLMs from Malicious Inputs”, agosto 2025
