Controlli di sicurezza per l'AI agentica — il playbook per CISO

Usa questo playbook quando distribuisci un sistema AI che può compiere azioni, non solo generare testo: un coding agent che apre pull request, un copilot SOC che può isolare un host, un agent customer-facing che emette rimborsi, un flusso RPA con un LLM nel loop, o qualsiasi cosa collegata ai tool tramite il Model Context Protocol o un livello di function-calling equivalente. La proprietà che definisce il perimetro è l'agency: è il sistema stesso a scegliere quale tool invocare e con quali argomenti.

Nel perimetro: identità e credenziali degli agent, autorizzazione all'uso dei tool, governance dei server MCP, fiducia inter-agent nelle catene multi-agent e l'osservabilità necessaria a provare cosa un agent ha davvero fatto.

Fuori perimetro: un chatbot puro senza accesso ai tool e senza autonomia (è un problema di data governance e di prompt injection con un set di controlli più leggero) e le pipeline di inferenza batch che producono testo su cui poi agisce una persona. Se il modello non può raggiungere da solo un tool o un'API, questo playbook è più pesante di quanto ti serva.

La sicurezza applicativa classica assume che i percorsi di codice siano fissi e che gli input siano dati. Un agent rompe entrambe le assunzioni: decide a runtime quale tool chiamare, tratta il contenuto recuperato e la conversazione precedente come istruzioni e, nei design multi-agent, si fida dell'output di altri agent come se fosse un servizio attendibile.

Il catalogo delle minacce è ormai ben mappato:

• Excessive agency — LLM06 nella Top 10 for LLM Applications 2025 di OWASP: l'agent detiene più permessi, autonomia o accesso ai tool di quanto il compito richieda, così una singola istruzione malevola ha una portata sproporzionata.
• Prompt injection (LLM01) — istruzioni ostili veicolate da un documento, una pagina web, un'email o l'output di un altro agent. Spesso non puoi impedirla; puoi limitare ciò che raggiunge.
• Tool misuse, memory poisoning, privilege compromise, identity spoofing e cascading failure multi-agent — le minacce catalogate dall'OWASP Agentic Security Initiative e mappate, per le notifiche al regolatore, su MITRE ATLAS.

Non è teoria. Le prime operazioni ransomware guidate end-to-end da un agent LLM — recon, furto di credenziali, movimento laterale e cifratura senza nessuno alla tastiera — hanno compresso una catena che prima richiedeva giorni in una che si auto-corregge in secondi (vedi il playbook di contenimento del ransomware ad AI agentica). Un containment disegnato sul dwell time umano non regge. I controlli seguenti assumono che l'avversario, o il tuo stesso agent compromesso, si muova alla velocità della macchina.

Obiettivo: ogni agent è un principal least-privilege con nome proprio e senza accesso permanente a nulla che conti.

• Assegna a ogni agent la propria identità. Non far mai girare un agent come utente umano né condividere un service account tra più agent — perdi insieme attribuzione e controllo del blast radius.
• Concedi credenziali just-in-time e time-bound, limitate alla risorsa specifica richiesta dal compito corrente. Tra un compito e l'altro un agent non deve detenere alcun accesso permanente alla produzione.
• Valuta l'autorizzazione a ogni hop e all'ultimo miglio, non solo su un gateway perimetrale. Il server MCP, l'API gateway e ogni servizio a valle devono terminare il token dell'agent, verificare la policy a ogni richiesta e inoltrare solo credenziali on-behalf-of limitate.
• Applica la guidance su AI data security di CISA, NSA e FBI ai dati che l'agent può leggere e scrivere: classificali, e lascia che sia l'identità dell'agent — non il prompt — a decidere cosa può toccare.

Checklist del dominio:

• [ ] Ogni agent ha un'identità distinta e inventariata.
• [ ] Le credenziali sono short-lived e limitate per compito; nessun accesso permanente alla produzione.
• [ ] La policy è applicata a ogni richiesta e a ogni hop, non solo al perimetro.
• [ ] L'accesso ai dati è legato all'identità dell'agent e alla classificazione, non al contenuto del prompt.

Obiettivo: l'agent può invocare solo i tool che hai sanzionato, e le azioni che possono farti male richiedono una persona.

• Mantieni una allowlist dei tool che ciascun agent può chiamare. Default-deny su tutto il resto. Un tool nuovo è un change che passa per una review, non una capacità che il modello scopre a runtime.
• Classifica le azioni per conseguenza. Il retrieval in sola lettura è a bassa conseguenza; scrivere su un database, muovere denaro, cancellare dati, fare deploy o cambiare accessi sono ad alta conseguenza. Metti ogni azione ad alta conseguenza dietro un passo esplicito di approvazione umana.
• Tratta ogni server MCP come un trust boundary, non come tubature interne. Autentica il server, fissa la sua identità, dai a ogni tool esposto un contratto esplicito e minimo, e valida sia gli argomenti in ingresso sia il contenuto in ritorno (si applica direttamente LLM05, improper output handling: l'output di un tool è input non attendibile per il passo successivo).
• Isola i server MCP di terze parti e remoti da quelli first-party. Un server remoto che non controlli è una dipendenza supply-chain con reach diretta nel tuo ambiente: mettilo in sandbox, applica rate-limit e loggalo separatamente.

Checklist del dominio:

• [ ] Ogni agent ha una allowlist di tool revisionata; tutto il resto è negato di default.
• [ ] Le azioni ad alta conseguenza richiedono approvazione umana, non il giudizio del modello.
• [ ] Ogni server MCP è autenticato, i suoi tool limitati singolarmente, input e output validati.
• [ ] I server MCP di terze parti sono in sandbox e isolati dalla capacità first-party.

Obiettivo: puoi ricostruire cosa ha fatto qualsiasi agent, e puoi vederlo in tempo per intervenire.

• Logga ogni invocazione di tool — quale agent, quale tool, quali argomenti, quale risultato, con quale approvazione — su uno store append-only che l'agent non può modificare. È insieme la tua timeline d'incidente e la tua evidenza d'audit.
• Cattura il decision trace dell'agent dove il framework lo consente, così un revisore vede perché un tool è stato chiamato, non solo che lo è stato.
• Stabilisci una baseline di egress per ogni agent: quali endpoint, quali volumi, quale cadenza sono normali. Senza baseline, beaconing ed esfiltrazione anomali sono invisibili.
• Guarda la rete, non solo i log applicativi. La policy a livello applicativo ti dice cosa ha chiesto un agent ben educato; non ti dice cosa fa uno compromesso o colpito da injection una volta che ha un tool e una via d'uscita.

Checklist del dominio:

• [ ] Ogni chiamata a tool è loggata in modo immutabile con agent, argomenti, risultato e approvatore.
• [ ] Esiste una baseline di egress per agent con alert sulle deviazioni.
• [ ] Il monitoraggio di rete copre il traffico degli agent e dei server MCP, non solo i log applicativi.
• [ ] I log d'audit sono conservati per la più lunga retention regolatoria applicabile.

Ordinate per il gate che le consuma, tieni pronte:

• L'inventario degli agent: ogni agent, il suo owner, la sua allowlist di tool, le sue classi di dati, la sua identità.
• Il registro delle identità: tipo di credenziale, scope, durata e percorso di emissione per ogni agent.
• La policy di tool e azioni: la allowlist più la classificazione per conseguenza e le regole di approvazione.
• Il registro dei server MCP: ogni server, first- o third-party, la sua autenticazione, i suoi contratti di tool.
• Il log immutabile delle invocazioni e la baseline di egress con i relativi alert di deviazione.
• I risultati del red team: la prova di aver esercitato la superficie agentica, con finding e fix.

Il punto in cui questi controlli cedono è lo scarto tra policy e realtà. I gate dei domini A e B sono indicativi: limitano ciò che un agent ben educato chiede, non ciò che fa uno compromesso o colpito da prompt injection una volta che ha un tool e una via di rete. L'ultima difesa è sul filo. Un'appliance on-premise che esegue AI Traffic Analysis con quattro inference head paralleli — traffico sospetto, classificazione malware, identificazione del tipo di attacco, application fingerprinting — a velocità di linea multi-gigabit vede un agent che fa beaconing verso un endpoint mai visto o esfiltra attraverso una chiamata a tool come comportamento, a prescindere da ciò che la policy MCP ha permesso; e poiché gira localmente sulla GPU dell'appliance senza chiamate a modelli esterni, il tuo layer di detection non è a sua volta un altro agent che telefona a un LLM in cloud. Lo stesso red team di AI autonomo che valida gli altri percorsi d'attacco può esercitare direttamente la superficie agentica — concatenando una prompt injection in un percorso di tool abuse, con un umano nel loop — così l'excessive agency diventa un finding chiuso in un'esercitazione invece di un incidente da notificare.

1. L'agent gira come un umano — o come root. Il modo più rapido per perdere il controllo è dare all'agent le credenziali di un utente privilegiato o un service account admin condiviso perché era comodo nel prototipo. Erediti ogni permesso che quell'account ha accumulato e perdi l'attribuzione. Dai all'agent la sua identità minima prima che esca dal prototipo.

2. Fidarsi delle guardrail lato modello come controllo di sicurezza. Un system prompt che dice non cancellare i dati di produzione è una guida, non un'enforcement. La prompt injection (OWASP LLM01) esiste proprio perché istruzioni e dati condividono lo stesso canale. Applica le conseguenze nel layer dei tool e in quello dell'identità, dove il modello non può aggirarle a parole.

3. Trattare i server MCP come tubature interne. Saltare autenticazione e logging su un server MCP perché è sullo stesso cluster è la versione agentica della rete piatta. La guidance NSA di maggio 2026 esiste perché MCP è arrivato più in fretta del suo modello di sicurezza: autentica e logga ogni server.

4. Human-in-the-loop come timbro. Se ogni azione apre un dialog di approvazione, i revisori approvano tutto nel giro di un giorno. Riserva le approvazioni alle azioni davvero ad alta conseguenza, così l'attenzione umana si spende dove cambia l'esito.

5. Puntare i propri strumenti di sicurezza su un modello in cloud. Se il tuo copilot SOC o il tuo monitor di agent chiama a sua volta un'API LLM esterna, hai aggiunto un altro canale da cui i dati interni escono. Tieni il layer di detection e analisi su infrastruttura che controlli.

6. Nessuna baseline di egress. Senza un modello del traffico normale di un agent, l'unica metrica che distingue in modo affidabile un agent funzionante da uno compromesso — dove parla e quanto — manca proprio quando serve.

I controlli sull'AI agentica non vivono in un vuoto regolatorio, e la mappatura è ciò che ti permette di difendere il programma davanti a un board o a un auditor.

• NIST AI RMF. L'AI Risk Management Framework e il suo Generative AI Profile (NIST-AI-600-1) ti danno la struttura Govern / Map / Measure / Manage per organizzare i controlli qui sopra e il lessico per rendicontarli.
• AI Act UE. Dove un agent opera dentro un caso d'uso ad alto rischio, gli obblighi dell'Act su risk management, logging, sorveglianza umana e robustezza si mappano quasi uno-a-uno sui domini da A a C. Gli obblighi sui modelli general-purpose valgono a monte.
• NIS2 e doveri settoriali di risk management. L'articolo 21 della NIS2 richiede misure tecniche adeguate e proporzionate su tutti i tuoi sistemi; un agent autonomo con reach in produzione rientra pienamente nel perimetro, e le autorità chiedono sempre più come è governato il tooling AI.
• OWASP e MITRE ATLAS sono rispettivamente il tuo catalogo tecnico dei controlli e il tuo linguaggio di mappatura delle minacce: cita gli ID di rischio LLM e agentici specifici e le tecniche ATLAS nelle valutazioni di rischio interne e in qualsiasi notifica al regolatore, esattamente come citeresti ATT&CK per un incidente convenzionale.

Il filo comune: la stessa evidenza di controllo — inventario, registro identità, policy dei tool, log delle invocazioni, risultati del red team — risponde a ciascuno di questi regimi. Costruiscila una volta, esportala per framework.