Lezioni di Cyber Immunity per gli agenti di IA

Proteggere i sistemi di IA è molto più difficile che proteggere i sistemi IT tradizionali (che si tratti di errori degli operatori, interferenze dolose o semplicemente comportamenti instabili). I motivi principali sono due. Innanzitutto, gli output dell’IA sono probabilistici, quindi lo stesso prompt può generare risposte diverse a ogni esecuzione. In secondo luogo, gli attuali LLM non sono in grado di distinguere in modo affidabile i comandi dai dati. Nonostante i comprovati problemi di sicurezza dei sistemi di IA che abbiamo trattato più volte, è impossibile ignorare i potenziali vantaggi economici derivanti dalla loro adozione. Ecco perché molte aziende stanno passando dai semplici assistenti di IA agli agenti di IA. Questi agenti svolgono le attività in autonomia e hanno accesso diretto agli stessi strumenti delle persone: dalla lettura dei database alla modifica delle impostazioni nei processi di produzione. Nel loro nuovo studio, i nostri esperti esaminano come definire chiaramente e ridurre i rischi che ne derivano, per limitare al minimo i potenziali problemi. L’approccio riprende e adatta i principi di Cyber Immunity e Security by Design.

I principi di base di Security by Design

Tutti i principi di questa disciplina sono universalmente applicabili alla progettazione di qualsiasi sistema informatico, inclusi gli agenti di IA. Ciò che cambia è il grado di adattamento e rielaborazione necessario per ciascun principio negli scenari di IA.

1. La sicurezza è un fattore distinto e importante fin dalla fase di progettazione. Gli obiettivi e i presupposti di sicurezza vengono definiti fin dal primo giorno e rispettati in ogni fase dello sviluppo. Per gli agenti di IA, questi presupposti dovrebbero includere tre punti chiave: (i) il modello linguistico viene trattato come non attendibile, (ii) i dati esterni di qualsiasi tipo sono considerati potenzialmente dannosi e (iii) le azioni irreversibili non possono essere eseguite in autonomia senza l’approvazione obbligatoria di una persona.
2. Il sistema è progettato partendo dal presupposto che subirà attacchi.
3. La base di calcolo attendibile e la superficie di attacco sono ridotte al minimo. Agli agenti vengono forniti solo gli strumenti di cui hanno effettivamente bisogno, autorizzazioni limitate e la quantità minima possibile di contesto. L’applicazione dei criteri di sicurezza è gestita interamente da componenti deterministici: il modulo di controllo dei criteri, il framework di esecuzione dell’agente e i meccanismi di isolamento (sandbox).
4. Si applica il principio del privilegio minimo. Ogni agente dispone di un proprio insieme di credenziali e privilegi di accesso (identità), limitati allo stretto necessario per svolgere il proprio compito. Se un agente necessita temporaneamente di privilegi elevati, li ottiene solo previa approvazione esterna e solo per la durata dell’attività che li richiede.
5. I componenti sono isolati. Nei sistemi basati su agenti, questo è uno dei problemi architetturali più complessi e articolati su più livelli. Il framework di esecuzione dell’agente deve essere eseguito in un ambiente isolato (sandbox o macchina virtuale) e gli agenti devono essere mantenuti il più possibile isolati gli uni dagli altri. Anche l’elaborazione dei dati in contesti attendibili e non attendibili viene mantenuta separata. Ad esempio, un agente legge una richiesta pull e scrive una bozza del codice, mentre un altro esamina il lavoro svolto senza mai vedere il testo potenzialmente dannoso della richiesta.
6. Si applica il principio di negazione predefinita. I criteri di sicurezza seguono questa regola: tutto ciò che non è esplicitamente consentito è vietato. Questo vale anche per le chiamate agli strumenti, le interazioni tra gli agenti e il traffico di rete.
7. È implementata una difesa in profondità. Misure diverse devono operare contemporaneamente e rafforzarsi a vicenda. Le difese probabilistiche, come i guardrail dell’IA (un “firewall” per i modelli linguistici) o l’allineamento (la percezione del modello stesso di ciò che è accettabile e di ciò che non lo è) non possono offrire alcuna garanzia formale di sicurezza. Tuttavia, rendono il sistema complessivamente più sicuro e costituiscono una preziosa fonte di telemetria.
8. La catena di fornitura è protetta. Alcuni agenti possono installare autonomamente funzionalità, librerie e altri componenti software, pertanto queste capacità devono essere soggette a regole rigorose. Occorre bloccare completamente queste capacità oppure limitarle a un elenco chiuso e preapprovato di versioni specifiche di determinati componenti. I sistemi basati su LLM nel cloud sono esposti a un rischio aggiuntivo: gli aggiornamenti dei modelli. Un giorno, la stessa richiesta API potrebbe ricevere una risposta da un modello linguistico diverso, con caratteristiche di sicurezza differenti.

Le insidie della sicurezza dell’IA

I principi generali della Security by Design sono ben noti e sembrano semplici sulla carta. Ma applicarli ai sistemi di IA è complicato, perché gli agenti sono incredibilmente flessibili. Ad esempio, un team di sicurezza potrebbe ritenere che un agente sul computer di uno sviluppatore venga eseguito in una sandbox e non possa modificare nulla al di fuori di essa. Ma un utente malintenzionato, o persino l’agente stesso, può escogitare decine di modi per aggirare questa protezione apparentemente solida: dall’esecuzione di comandi tramite un server MCP locale non soggetto alle restrizioni della sandbox alla riconfigurazione di un altro agente IA installato sul sistema. A complicare ulteriormente le cose, la gamma di vettori di attacco è vastissima: da campi arbitrari nella configurazione dell’agente a stringhe di testo apparentemente innocue in un file di skill.

Un problema serio che i progettisti spesso sottovalutano è la user fatigue. Un agente molto attivo può generare decine di richieste al minuto, chiedendo all’utente di confermare azioni potenzialmente pericolose. Nel giro di un’ora, l’utente finisce per fare clic su Approva con il pilota automatico, senza leggere ciò che sta approvando. Ecco perché è importante calibrare con attenzione sia la frequenza con cui compaiono queste richieste sia il modo in cui sono formulate. Nessuno leggerà la descrizione di una richiesta se è troppo lunga. Una descrizione troppo breve, invece, può nascondere i dettagli essenziali di cui l’utente ha bisogno per prendere la decisione giusta.

Le vulnerabilità degli agenti e degli strumenti correlati sono un problema urgente, aggravato dalla rapidità con cui queste categorie di software si evolvono e ricevono aggiornamenti. Piattaforme e app di riferimento del settore, come LangGraph, MS Semantic Kernel e Claude Code, hanno richiesto più volte la correzione di vulnerabilità critiche. Gli architetti dovrebbero sempre valutare la possibilità di sostituire un framework ampio e tuttofare con un sistema compatto ed essenziale, dotato solo delle funzionalità effettivamente necessarie a uno specifico agente.

Inoltre, implementare con cura misure di sicurezza standard e consolidate negli strumenti disponibili riduce notevolmente i danni nel caso in cui un agente venga attaccato o si comporti in modo imprevisto. Un esempio è un rigoroso elenco di domini consentiti che lo strumento di recupero dei contenuti Web può aprire su richiesta dell’agente. Tuttavia, i progettisti raramente tengono conto dei problemi nascosti e dell’onere di mantenere aggiornato l’elenco. Di conseguenza, l’elenco diventa gradualmente obsoleto e lascia falle che gli autori degli attacchi possono sfruttare. L’esempio più eclatante è l’attacco EchoLeak. Microsoft 365 Copilot disponeva di un elenco di domini consentiti per l’accesso ai siti esterni, implementato correttamente e piuttosto efficace, ma gli autori degli attacchi lo hanno aggirato sfruttando una funzionalità di uno strumento secondario e il dominio di MS Teams.

Consigli pratici per architetti e team di sicurezza

Gli architetti di sistemi di IA e i responsabili dei team di ingegneria e sicurezza dovrebbero integrare la sicurezza degli agenti fin dalla fase di progettazione. Dovrebbero basarsi principalmente su meccanismi verificabili e deterministici: isolare i componenti, controllare le interazioni e ridurre al minimo la base di calcolo attendibile.

Le decisioni architetturali fondamentali includono la definizione di un livello di autonomia accettabile per gli agenti, la limitazione dell’accesso ai dati riservati e delle combinazioni pericolose di funzionalità, nonché l’uso di sandbox, ruoli separati per i diversi modelli e gateway di controllo degli accessi. Le restrizioni aggiunte in un secondo momento riducono i rischi, ma non sostituiscono un’architettura sicura.

A livello organizzativo e operativo, le aziende devono mantenere un inventario dei propri agenti, coordinare gli sforzi dei team di sicurezza e distribuzione, proteggere gli ambienti basati su contenitori, gestire la supply chain (AIBOM) e integrare una difesa a più livelli.

L’osservabilità richiede particolare attenzione. Per i sistemi di IA, ciò dovrebbe includere la registrazione delle richieste, delle risposte e dei ragionamenti dell’LLM, nonché dati di telemetria dettagliati provenienti dagli host e dagli ambienti cloud in cui viene eseguito il framework di esecuzione dell’agente.

La parte più difficile della progettazione degli agenti è trovare un equilibrio tra sicurezza, prestazioni e utilità. Per scoprire come raggiungere questo equilibrio attraverso la modellazione delle minacce e obiettivi di sicurezza chiaramente definiti, leggi la versione completa dello studio.