Perché la sicurezza dell’IA è più complessa dei tradizionali sistemi informatici
I sistemi di IA risultano molto più difficili da proteggere rispetto ai tradizionali sistemi informatici, sia per errori degli operatori, interferenze malintenzionate o semplicemente per comportamenti instabili. Due sono le ragioni principali.
In primo luogo, i risultati dell’IA sono probabilistici: la stessa istruzione può generare risposte differenti ad ogni esecuzione.
In secondo luogo, gli attuali large language model (LLM) non sono in grado di distinguere in modo affidabile tra ordini e dati.
Nonostante i numerosi problemi di sicurezza dimostrati nei sistemi di IA, è impossibile ignorare i potenziali benefici economici derivanti dalla loro adozione. Per questo molte aziende stanno passando da semplici assistenti IA ad agenti IA autonomi, capaci di accedere a strumenti come database o configurazioni di processi di produzione.
Principi di “secure by design” applicati agli agenti IA
Obiettivi e assunzioni di sicurezza fin dalla fase di progettazione
Tutti i principi di questa disciplina sono universalmente applicabili alla progettazione di qualsiasi sistema informatico, compresi gli agenti IA. La differenza sta nel grado di adattamento e revisione richiesto per gli scenari IA.
Nel caso degli agenti IA, gli assunti di sicurezza devono includere tre punti chiave:
- Il modello di linguaggio è considerato non affidabile.
- I dati esterni di qualsiasi tipo sono potenzialmente malevoli.
- Non è possibile eseguire azioni irreversibili in modo autonomo senza l’approvazione obbligatoria di un essere umano.
Il sistema viene progettato partendo dal presupposto che subirà attacchi.
Riduzione della superficie di attacco e principio del privilegio minimo
La base informatica di fiducia e la superficie di attacco sono ridotte al minimo. Gli agenti dispongono solo degli strumenti strettamente necessari, con permessi limitati e il minor contesto possibile. La politica di sicurezza è gestita interamente da componenti deterministici: supervisore di policy, arnesi dell’agente e meccanismi di isolamento (ambienti isolati).
Si applica il principio del privilegio minimo. Ogni agente ha un proprio set di credenziali e privilegi (identità), limitati al necessario per svolgere il proprio lavoro. Se un agente necessita temporaneamente di privilegi elevati, li ottiene solo dopo una autorizzazione esterna e durano esattamente quanto la task richiede.
Isolamento e regola del “default deny”
I componenti sono isolati. Nei sistemi basati su agenti, questo è uno dei problemi architetturali più complessi e multilivello. L’ambiente di esecuzione dell’agente deve operare in un contesto isolato (sandbox o VM) e gli agenti devono rimanere il più possibile separati tra loro. Anche il processing di dati in contesti di fiducia e non fiducia deve essere separato. Per esempio, un agente legge una richiesta di modifica e genera una bozza di codice, mentre un altro agente revisiona il lavoro senza vedere il testo potenzialmente malevolo della richiesta.
La regola predefinita è la negazione: tutto ciò che non è esplicitamente permesso è proibito, incluse le chiamate a strumenti, le interazioni tra agenti e il traffico di rete.
Difesa in profondità e protezione della catena di fornitura
Si applica la difesa in profondità. Le misure devono operare contemporaneamente e rafforzarsi a vicenda. Le difese probabilistiche, come i firewall per i modelli di linguaggio o l’allineamento (criterio interno del modello su ciò che è accettabile), non offrono garanzie formali, ma aumentano la sicurezza complessiva e forniscono telemetria preziosa.
La catena di fornitura deve essere protetta. Alcuni agenti possono installare skill, librerie o altri componenti software autonomamente; queste capacità devono essere regolate da norme severe: blocco totale o limitazione a una lista chiusa e pre-approvata di versioni specifiche. I LLM basati su cloud affrontano un rischio aggiuntivo legato agli aggiornamenti dei modelli: la stessa chiamata API potrebbe rispondere con un modello diverso, con proprietà di sicurezza differenti.
Le trappole della sicurezza dell’IA
Flessibilità degli agenti e vettori di attacco
I principi generali della sicurezza dalla progettazione sono noti, ma applicarli ai sistemi di IA è complesso perché gli agenti sono incredibilmente flessibili. Un team di sicurezza potrebbe ritenere che un agente sul computer di uno sviluppatore sia isolato e non possa modificare nulla al di fuori del suo sandbox. Un attaccante, o lo stesso agente, può eludere questa protezione in decine di modi: ad esempio eseguendo comandi attraverso un server MCP locale non soggetto alle restrizioni, oppure reconfigurando un altro agente IA installato nel sistema.
La varietà di vettori di attacco è enorme: da campi arbitrari nella configurazione dell’agente a catene di testo apparentemente innocue in un file di skill.
Fatica dell’utente e richieste di approvazione
Un problema grave spesso sottovalutato è la fatica dell’utente. Un agente molto attivo può generare decine di richieste al minuto, chiedendo all’utente di confermare azioni potenzialmente pericolose. In meno di un’ora la persona può cliccare “Approva” in modo automatico senza leggere cosa sta approvando.
È fondamentale regolare attentamente sia la frequenza delle richieste sia la loro formulazione. Una descrizione troppo lunga non verrà letta; una troppo breve può nascondere dettagli chiave necessari per una decisione informata.
Vulnerabilità nei framework e manutenzione delle liste di dominio
Le vulnerabilità negli agenti e negli strumenti correlati sono preoccupanti, soprattutto per la rapidità con cui questi software evolvono e ricevono aggiornamenti. In piattaforme comuni come LangGraph, MS Semantic Kernel e Claude Code sono state corrette vulnerabilità critiche più volte.
Gli architetti dovrebbero valutare la sostituzione di un framework grande e polivalente con un sistema più compatto e semplificato, contenente solo le funzioni realmente necessarie all’agente.
L’adozione attenta di misure di sicurezza standard nei tool disponibili riduce drasticamente il danno in caso di attacco o comportamento anomalo. Un esempio è una lista di domini permessi strettamente controllata che lo strumento di recupero web può aprire su richiesta dell’agente. Tuttavia, i designer spesso trascurano i costi nascosti e l’onere di mantenere tale lista aggiornata; col tempo diventa obsoleta e apre brecce agli attaccanti.
Il caso più eclatante è l’attacco EchoLeak. Microsoft 365 Copilot disponeva di una lista di siti permessi efficace, ma gli aggressori l’hanno aggirata tramite una funzione di una headless browser che ha permesso l’esfiltrazione di dati non autorizzati.
Linee guida operative per una ciberimmunità efficace
Implementazione pratica dei principi “secure by design”
- Definire fin dall’inizio modelli di fiducia minimi e considerare il modello di linguaggio non affidabile.
- Applicare il principio del privilegio minimo a credenziali, accessi e risorse di rete.
- Isolare ogni agente in ambienti sandbox o VM separati, mantenendo separati i flussi di dati di fiducia e non fiducia.
- Adottare una politica “default deny” per ogni chiamata a tool, interazione tra agenti e traffico esterno.
- Implementare meccanismi di supervisione delle policy deterministici, con audit continui.
Gestione delle richieste di approvazione e riduzione della fatica
- Aggregare le richieste simili in batch con chiara sintesi dei rischi.
- Utilizzare messaggi brevi ma informativi, evidenziando gli elementi critici.
- Introdurre soglie di approvazione basate sul livello di rischio, richiedendo conferma solo per operazioni ad alto impatto.
- Registrare tutte le approvazioni per audit e revisione post‑evento.
Manutenzione continua della catena di fornitura e delle liste di dominio
- Stabilire un processo di revisione periodica delle skill, librerie e dipendenze installate dagli agenti.
- Limitare le installazioni a versioni firmate e pre‑approvate.
- Automatizzare la verifica di integrità delle componenti tramite firme crittografiche.
- Aggiornare regolarmente le whitelist di domini, integrando feed di threat intelligence per identificare rapidamente nuovi rischi.
Monitoraggio, telemetria e risposta agli incidenti
La telemetria deve raccogliere dati su:
- Comportamenti anomali dell’agente (es. numero insolito di richieste di approvazione).
- Accessi a risorse non autorizzate o tentativi di elusione delle sandbox.
- Modifiche alle policy di sicurezza o ai privilegi.
Questi dati alimentano sistemi di rilevamento basati su intelligenza artificiale, consentendo una risposta rapida e automatizzata o l’allerta a un operatore umano.
Conclusioni
Proteggere i sistemi di IA richiede un approccio olistico che combini i principi tradizionali di “secure by design” con la filosofia di ciberimmunità: anticipare, limitare e mitigare le minacce prima che si concretizzino. La flessibilità intrinseca degli agenti IA introduce nuove superfici di attacco, ma l’adozione di isolamento rigoroso, privilegio minimo, regole di default deny e difesa in profondità può ridurre drasticamente il rischio.
Le organizzazioni devono inoltre investire nella riduzione della fatica dell’utente, nella manutenzione proattiva di whitelist e dipendenze, e nel monitoraggio continuo con telemetria avanzata. Solo così sarà possibile sfruttare i vantaggi economici dell’IA senza compromettere la sicurezza dei sistemi e dei dati aziendali.