Soluzione · AI Operations
Il tuo agente di IA non ha bisogno di sbagliare per fare danni. Basta che qualcuno da fuori gli parli.
La governance degli agenti decide cosa il tuo ha il permesso di fare. La sicurezza decide cosa può fargli fare qualcuno che qui non ci lavora: un'istruzione nascosta in un'e-mail che l'agente legge, uno strumento che nessuno ha verificato, un segreto che viaggia nel contesto. Montiamo quello strato —isolamento, identità, filtro e traccia forense— e lo gestiamo.
Il problema
Un agente con permessi è una superficie d'attacco nuova. Non la copre il tuo fornitore di sicurezza e non la copre il tuo strato di governance.
- Il tuo agente legge e-mail, ticket, documenti o pagine web. Tutto questo è testo scritto da qualcuno di fuori, e il modello non distingue fra ciò che gli hai chiesto e ciò che arriva dentro al contenuto.
- Le credenziali dell'agente non sono sue: sono quelle di un utente tecnico con più permessi di chiunque nel team, e stanno in una variabile d'ambiente che nessuno ha ruotato dal primo giorno.
- Ogni strumento che gli colleghi allarga quello che può fare e, nella stessa misura, quello che gli possono far fare. Nessuno controlla chi ha pubblicato quel connettore, cosa chiede a ogni chiamata, né cosa è cambiato nell'ultima versione.
- Il contesto si trascina dati da un caso al successivo perché la sessione non viene mai pulita, o perché l'indice da cui recupera informazioni non filtra per i permessi di chi sta chiedendo.
- Se domani qualcuno chiede cosa ha fatto l'agente, con quali dati e sotto quale versione, la risposta è sparsa fra i registri di tre sistemi che non condividono un identificativo.
Il costo di lasciare tutto com’è
La lista di riferimento del settore non lascia più spazio ai dubbi: nell'OWASP Top 10 for LLM Applications, edizione 2025, l'iniezione di istruzioni occupa il primo posto per la seconda edizione consecutiva, l'esposizione di informazioni sensibili il secondo, la catena di fornitura il terzo e l'agentività eccessiva —dare all'agente più capacità di quella che il suo compito richiede— il sesto. Non è un rischio futuro: è esattamente il copione con cui ti guarderà chiunque verifichi il tuo sistema, sia il tuo cliente grande, il tuo assicuratore o il tuo regolatore. E il costo di non avere risposta non si paga in ticket aperti: si paga in un dato uscito, un'azione eseguita e una spiegazione che non puoi dare perché non c'è traccia.
La soluzione
Montiamo lo strato di sicurezza dell'agente —isolamento, identità, filtro e traccia forense— e lo gestiamo come funzione continua
- 1Modelliamo la minaccia agente per agente, il passaggio che quasi nessuno fa: da dove arriva il testo che legge, quali dati raggiunge, quali azioni può eseguire e cosa succede se un terzo controlla una di queste tre cose. Da lì esce la lista di cosa blindare, in ordine — e non il contrario.
- 2Separiamo istruzione e dato. Ciò che arriva da fuori entra come contenuto, mai come ordine: modelli di prompt che il contenuto non può riscrivere, filtro in ingresso e validazione dell'uscita prima che tocchi un sistema reale. Che il modello si lasci convincere è gestibile; che la sua uscita si esegua senza controllo, no.
- 3Diamo a ogni agente un'identità propria invece di una chiave maestra condivisa: credenziali a vita breve, privilegio minimo per strumento e per dato, e azioni sensibili sostenute da un'autorizzazione circoscritta invece che da un token eterno in un file d'ambiente.
- 4Isoliamo l'esecuzione degli strumenti: ambiente delimitato, lista bianca di destinazioni e domini, e revisione vera di ogni connettore installato —chi lo pubblica, quali permessi chiede, cosa cambia a ogni versione. La catena di fornitura è il terzo rischio della lista ed è anche il più facile da infilare.
- 5Tagliamo la fuga dal contesto: il recupero delle informazioni filtra per i permessi di chi chiede, la sessione si pulisce fra un caso e l'altro, e segreti e dati personali vengono mascherati prima di uscire verso qualunque modello esterno.
- 6Chiudiamo con traccia forense e risposta: un identificativo di caso che attraversa modello, strumenti e sistemi, una conservazione pensata per poter indagare, un freno per agente e una procedura di risposta scritta. E lo gestiamo: prove avversarie periodiche contro gli agenti vivi, non un audit una tantum che invecchia in tre mesi.
Cosa cambia
Quello che smetti di perdere
L'iniezione di istruzioni smette di essere teorica: si prova contro i tuoi agenti vivi, con casi reali del tuo business, prima che la provi qualcuno da fuori.
Meccanismo
L'agente smette di condividere la chiave maestra: ognuno ha identità propria, privilegio minimo e credenziale a vita breve, così un agente compromesso non apre tutta la casa.
Meccanismo
La fuga dal contesto smette di dipendere dal fatto che nessuno chieda ciò che non deve: si filtra per i permessi di chi chiede e si pulisce fra i casi, per progetto e non per fiducia.
Meccanismo
Cosa misuriamo: quota di agenti con modello di minaccia vivo, % di azioni sensibili coperte da credenziale circoscritta o autorizzazione, riscontri delle prove avversarie aperti e chiusi, e tempo per ricostruire un caso completo da capo a fondo.
Cosa misuriamo
Scheda tecnica
- Lavoro che elimina
- scoprire a posteriori che un agente si è fatto convincere, che si portava dietro permessi in eccesso o che il suo contesto ha fatto uscire dati —e ricostruire il caso a mano fra registri che non combaciano
- Implementazione tipica
- 3–6 settimane
- Ingresso
- gli agenti che hai già in produzione, i loro strumenti collegati, le loro credenziali e le fonti di testo che leggono
- Uscita
- ogni agente con modello di minaccia, identità propria e privilegio minimo, strumenti isolati e in lista bianca, contesto filtrato per permessi e una traccia da capo a fondo con cui si può davvero indagare
- Compatibile con
- OpenAIAnthropicAzure OpenAILangChainLlamaIndexn8nServidores MCP
- Può collegarsi con
- Tu gestor de secretos y tu proveedor de identidadTu SIEM o tu stack de observabilidadTu capa de gobierno de agentes, si ya la tienes montada
- Cosa misuriamo
- quota di agenti con modello di minaccia vivo% di azioni sensibili con credenziale circoscritta o autorizzazioneriscontri delle prove avversarie aperti e chiusitempo per ricostruire un caso completo
- Adatto per
- aziende con agenti già in produzione che leggono testo di terzi o agiscono su sistemi reali, e che devono rispondere a un cliente, a un audit o a un regolatore
- Non adatto per
- chi è ancora alla prova di concetto senza dati reali né permessi di scrittura: lì serve progettare bene, non blindare
Domande frequenti
Nell'avversario. Governare risponde a «cosa ha il permesso di fare il mio agente e chi risponde se sbaglia»: politiche, approvazioni, audit, conformità. È lo strato che evita l'errore proprio, ed è sviluppato in governare gli agenti di IA della tua azienda. La sicurezza risponde a un'altra domanda: «cosa può fargli fare qualcuno che qui non ci lavora». Lì nessuna politica serve, perché l'attaccante non legge le tue politiche: bisogna separare istruzione e dato, isolare gli strumenti, circoscrivere le identità e lasciare una traccia con cui indagare. Si completano a vicenda e l'ordine conta poco; quello che non funziona è averne una e credere di averle entrambe.
Per il perimetro, gli accessi e le postazioni sì, e non lo tocchiamo. Dove finisce la strada è sulla superficie nuova: un agente che esegue azioni a partire da testo scritto da un terzo non assomiglia a niente che copra un firewall. L'iniezione di istruzioni non è un exploit di rete, è il modello che obbedisce alla persona sbagliata. L'isolamento degli strumenti non è segmentare la rete, è decidere cosa può invocare un processo che improvvisa a runtime. E rivedere un connettore non è una scansione di vulnerabilità, è leggere quali permessi chiede e chi l'ha pubblicato. Quello strato sta in una terra di nessuno fra il tuo fornitore di sicurezza e la tua consulenza di IA: per questo lo montiamo noi, e per questo il servizio dietro è sicurezza completa, classica e di IA.
No, e diffida di chi ti dice di sì. Finché il modello elabora istruzioni e dati sullo stesso canale, esisterà sempre un testo capace di convincerlo; per questo quel rischio tiene il primo posto della lista OWASP per due edizioni di fila. Quello che si può fare —e che cambia davvero il risultato— è fare in modo che farsi convincere non basti a causare danno: privilegio minimo perché l'azione pericolosa non sia disponibile, validazione dell'uscita prima che tocchi un sistema, autorizzazione umana su ciò che costa soldi o tocca persone, e traccia per accorgersene presto. La difesa non è un muro: sono strati che impediscono a un errore del modello di diventare un incidente di business.
Lo montiamo nella tua azienda?
Hai individuato il problema. Noi consegniamo la soluzione e la lasciamo misurata.