Sicurezza degli agenti AI: dove si inserisce nello stack

Che cos’è la sicurezza degli agenti AI?

La sicurezza degli agenti AI è l’insieme di controlli che limitano ciò a cui un agente AI può accedere e ciò che può fare, e che lo bloccano quando viene compromesso. Copre il modello, gli strumenti e i server MCP che l’agente richiama, l’identità con cui opera e l’host su cui viene eseguito.

La Campaign C0062 di MITRE ATT&CK documenta un probabile attore di spionaggio legato alla Cina che utilizza agenti Claude Code e strumenti MCP per ricognizione, sfruttamento, raccolta di credenziali ed esfiltrazione contro circa 30 organizzazioni, con un coinvolgimento umano minimo. Se i tuoi sviluppatori eseguono agenti di coding o i tuoi team collegano agenti a Salesforce, questi controlli determinano fino a che punto può arrivare un agente compromesso. Se sono implementati correttamente, il suo margine d’azione si esaurisce rapidamente.

Quali sono i principali rischi per la sicurezza degli agenti AI?

I principali rischi per la sicurezza degli agenti AI sono la compromissione dell’obiettivo, l’uso improprio degli strumenti, l’abuso di identità e privilegi, compromissione della supply chain e agenti rogue, tutte voci della OWASP Top 10 for Agentic Applications 2026.

EchoLeak (ASI01) mostra il dirottamento dell'obiettivo senza un solo clic: il record del National Vulnerability Database (NVD) per CVE-2025-32711 descrive un'iniezione di comandi AI che ha consentito a un attaccante non autorizzato di divulgare informazioni da un assistente AI aziendale attraverso una rete, senza richiedere alcuna interazione dell'utente. L'assistente deteneva dati privati, leggeva contenuti non attendibili e poteva inviare dati all'esterno. Rimuovi anche solo una di queste capacità e il percorso di esfiltrazione si chiude.

Nella violazione di Salesloft Drift, un esempio di abuso di identità e privilegi (ASI03) su larga scala, l'FBI ha riferito che UNC6395 ha utilizzato token OAuth compromessi per Salesloft applicazione Drift per raggiungere le istanze Salesforce delle vittime ed esfiltrare dati. La Financial Industry Regulatory Authority (FINRA) ha confermato che la violazione ha colpito più di 700 organizzazioni, e i token rubati hanno consentito agli attaccanti di impersonare Drift all'interno di Salesforce e Google Workspace.

Qualsiasi agente che detenga token OAuth per app SaaS affronta la stessa esposizione, perché gli attaccanti hanno utilizzato token rubati, non prompt injection. Questa distinzione determina dove, nello stack di sicurezza degli agenti AI, collocare controlli applicabili.

Dove deve trovarsi la sicurezza nello stack degli agenti AI?

La sicurezza appartiene a due tipi di controlli nello stack di sicurezza degli agenti AI: i controlli comportamentali modellano ciò che il tuo agente tenta di fare, mentre i controlli dell'infrastruttura impongono ciò che può fare. Costruisci il livello dell'infrastruttura come il confine che regge quando la guida comportamentale fallisce.

La regola è la stessa a ogni livello: il controllo deve trovarsi in un punto che l'agente non possa raggiungere o riscrivere, nemmeno con le proprie credenziali.

Il post del NIST su identità agentica spiega perché un solo livello non può sostenere il carico. I guardrail basati solo sul modello non sono ancora attrezzati per le sfide di sicurezza agentica, e un agente che persegue un obiettivo può esplorare più percorsi, raggiungere strumenti o dati imprevisti, o trovare credenziali orfane per aumentare i privilegi.

I controlli comportamentali guidano ciò che un agente tenta di fare

I controlli comportamentali riducono la frequenza con cui il tuo agente tenta qualcosa di dannoso. Le opzioni includono prompt di sistema rafforzati, filtraggio della prompt injection al confine di ingestione, gate di approvazione per azioni ad alto impatto e policy di governance scritte. Non possono garantire un comportamento sicuro perché il modello legge istruzioni e dati come un unico flusso di token. 

L’indagine OpenClaw di MITRE ATLAS mostra il costo di un gate mancante: operazioni distruttive, incluso l’uso di credenziali e la trasmissione di dati esterni, non richiedevano alcuna approvazione anche quando una memoria vecchia e non attendibile influenzava l’agente. Mantieni l’approvazione umana per tali azioni, ma vincola l’identità dell’approvatore a quella dell’agente, un problema aperto che il concept paper del National Cybersecurity Center of Excellence (NCCoE) solleva.

I controlli dell’infrastruttura decidono cosa può fare un agente

I controlli dell’infrastruttura definiscono la portata effettiva dell’agente nell’intero stack infrastrutturale degli agenti AI. Assegna a ogni agente una identità non umana univoca con credenziali a breve durata e con ambito definito. Limitane l’uso a strumenti e API in allowlist. Confinalo a un’esecuzione in sandbox con rete in uscita negata per impostazione predefinita. Richiedi ai server MCP di convalidare il pubblico del token e conserva log delle azioni firmati e collegati all’identità. Anche un agente completamente compromesso non può superare questi limiti.

La bozza del Cyber AI Profile del NIST, NIST IR 8596, fornisce al tuo team la regola sull’identità: “Assegna a ogni agente AI un’identità e credenziali univoche e trattali con le stesse precauzioni di sicurezza riservate agli utenti privilegiati.” NIST IR 8587 applica le sue linee guida sulla protezione dei token ogni volta che gli agenti usano token firmati per raggiungere sistemi, dati, strumenti o API.

A livello di strumento, la sicurezza MCP inizia con la specifica di autorizzazione MCP, che richiede a ogni server MCP di convalidare che i token di accesso siano stati emessi specificamente per esso come destinatario previsto. Saltare questo controllo espone il server agli attacchi del deputy confuso coperti dai requisiti di sicurezza della specifica.

Anche i gate di approvazione necessitano della stessa protezione contro le manomissioni: in CVE-2026-25253, documentata nell’indagine OpenClaw, una cross-site request forgery contro il gateway locale dell’agente ha portato a una modifica della configurazione che ha disabilitato la conferma dell’utente. I gate di approvazione contano come infrastruttura solo quando l’agente, e chiunque lo comprometta, non può raggiungere l’interruttore. Mappa questi confini sulla tua architettura degli agenti AI prima di decidere come proteggere singolarmente gli agenti AI. Ogni agente eredita il confine più debole tra i livelli che tocca.

Come si proteggono gli agenti AI?

Proteggi i tuoi agenti AI inventariandoli, definendo l’ambito di ogni identità, mettendo in allowlist gli strumenti, isolando l’esecuzione in sandbox, registrando le azioni e inserendo gate per i passaggi irreversibili. Queste best practice di sicurezza per gli agenti AI sono allineate con la guida di maggio 2026 della CISA, scritta con l’Australian Cyber Security Centre (ACSC) dell’Australian Signals Directorate (ASD) e partner internazionali: “Inizia con casi d’uso di AI agentica a basso rischio e non sensibili” e “Evita di concedere accessi ampi o illimitati, soprattutto a dati sensibili o sistemi critici.”

1. Inventaria e identifica: Inizia con il rilevamento, perché gli agenti distribuiti localmente o al di fuori della revisione IT raramente compaiono in un repository centrale delle identità. Includi le workstation degli sviluppatori i cui file di configurazione MCP concedono accesso ai servizi interni, quindi assegna un’identità per agente con token a breve durata e con ambito definito.
2. Limita l’esecuzione: Metti in allowlist gli strumenti e le API richiesti, rimuovi le capacità non necessarie prima della produzione, isola l’esecuzione in sandbox, nega per impostazione predefinita il traffico in uscita e inietta le credenziali solo per la sessione.
3. Registra e inserisci gate per le azioni: Attiva log firmati e collegati all’identità di prompt, contesto recuperato, chiamate agli strumenti e output prima di concedere l’accesso in scrittura. Richiedi una conferma esplicita per azioni distruttive o irreversibili e usa eliminazioni graduali o reversibili.
4. Ripeti prima di ampliare l’ambito: Esegui nuovamente le azioni registrate in un clone isolato della produzione e aumenta l’autorità di un agente solo dopo che i primi tre passaggi sono in atto e la ripetizione resta entro i limiti del blast radius.

Non tutti gli agenti necessitano di questi controlli alla massima intensità. La profondità corretta dipende dall’autorità detenuta da ciascun agente.

Scala i controlli in base all’autorità di ciascun agente

Abbina la profondità dei controlli all’autorità associata a ciascuna classe di azione. La Agentic AI Security Scoping Matrix di AWS, come la Cloud Security Alliance (CSA) l’ha estesa nel dicembre 2025, classifica gli agenti in base ad agency e autonomia.

L'estensione di CSA assegna a ciascun agente un punteggio in base al livello di autorizzazione e all'esposizione al rischio, da sola lettura e basso rischio a lettura-scrittura e alto rischio. Un agente di sola lettura che agisce autonomamente comporta rischi diversi rispetto a un agente con capacità di scrittura che richiede approvazione. 

Applica il modello per classe di azione in tutta la tua architettura di agenti AI, in modo che un agente possa leggere i log in modo indipendente e che ogni operazione di scrittura, invio, spesa o eliminazione attenda una persona. Il contenimento dipende dal sapere esattamente a cosa potrebbe accedere un agente compromesso, quindi registra ora l'ambito di ciascun agente.

Come si individua e si contiene un agente AI compromesso?

Individua gli agenti compromessi tramite indicatori semantici, infrastrutturali e di identità, quindi contienili in un ordine che preservi le evidenze. Smantellare il pod prima dell'acquisizione fa perdere il resto della catena.

Gli indicatori semantici includono discrepanze tra la richiesta originale e i parametri della chiamata allo strumento o tra una chiamata allo strumento dichiarata e ciò che è stato eseguito. Un'attività di riepilogo che termina con una chiamata in uscita è un altro indicatore. Gli indicatori di infrastruttura provengono dallo stack infrastrutturale dell'agente AI: un container di inferenza che avvia una shell, installa un pacchetto, scrive in percorsi non familiari o apre connessioni in uscita inattese. Gli indicatori di identità includono credenziali generate al di fuori della lineage approvata, chiamate bloccate ritentate tramite un altro connettore, logging disabilitato o approvazioni che arrivano in blocco.

Una volta che un indicatore si attiva, esegui le fasi di risposta agli incidenti in questo ordine:

1. Blocca e acquisisci: Revoca le autorizzazioni dell'agente e arresta l'esecuzione contemporaneamente. Prima dello smantellamento, acquisisci la cronologia dei prompt con i timestamp, il contesto recuperato con la provenienza, la sequenza delle chiamate agli strumenti, le assunzioni di identità, le invocazioni degli agenti downstream e la traccia di output del large language model (LLM). Mantieni attiva l'acquisizione a livello kernel.
2. Revoca e isola: Revoca token, chiavi API e certificati per l'intera identità perché le sessioni concorrenti e le connessioni MCP richiedono un'interruzione simultanea. Isola l'host, il container o il workload e definisci il raggio d'impatto tramite il grafo delle identità. 
3. Metti in quarantena la fiducia: Rimuovi l'accesso dell'agente a strumenti e protocolli preservando il record di identità. Notifica i sistemi downstream che mantengono relazioni di fiducia con esso.
4. Eradica e riprovisiona: Ripristina versioni e configurazioni note come affidabili del modello, correggi il confine che ha fallito ed emetti nuove credenziali solo dopo aver verificato che l'ambiente sia pulito. Richiedi la convalida umana per i casi ad alta gravità.

Esercita il contenimento prima che sia necessario: le linee guida di emergenza della CSA CISO Community raccomandano esercitazioni tabletop sull'AI agentica, incluso un agente rogue che attacca una terza parte. Mappa ogni passaggio a uno dei framework seguenti in modo che un incidente che coinvolge un agente venga gestito sempre allo stesso modo.

Quali framework di sicurezza per agenti AI si applicano?

Associa ogni framework alla domanda a cui risponde: l'OWASP Top 10 for Agentic Applications 2026 indica cosa può andare storto, MITRE ATLAS mostra come lo fanno gli attaccanti, CSA MAESTRO struttura il modello di minaccia, NIST IR 8596 e IR 8587 definiscono le regole per identità e token e le linee guida di maggio 2026 di CISA delimitano il rischio di adozione. Per proteggere l'AI agentica all'interno di un programma di conformità, ISO/IEC 42001 e l'EU AI Act forniscono il quadro di governance.

OWASP Top 10 for Agentic Applications e Agent Control Standard

L'OWASP Top 10 for Agentic Applications 2026, pubblicato il 9 dicembre 2025, fornisce ai team di security engineering e delle piattaforme AI un vocabolario condiviso per i dieci rischi degli agenti mappati in precedenza, dal goal hijack agli agenti rogue. A settembre 2026, l'OWASP GenAI Security Project ha aggiunto l' Agent Control Standard, che estende tali linee guida verso l'applicazione in fase di runtime.

MITRE ATLAS

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) è la knowledge base di tattiche, tecniche e casi di studio degli avversari contro i sistemi AI, strutturata come ATT&CK e ora comprensiva di tecniche specifiche per gli agenti come l'avvelenamento del contesto degli agenti AI e il furto di credenziali tramite strumenti degli agenti. I threat hunter la usano per mappare gli incidenti che coinvolgono agenti a tecniche denominate. MITRE pubblica rilasci mensili dei contenuti e v2026.09 è la versione corrente a settembre 2026.

CSA MAESTRO e l'AI Controls Matrix

Pubblicato dalla Cloud Security Alliance il 6 febbraio 2025, CSA MAESTRO è un framework di threat modeling creato per l’AI agentica che suddivide un sistema di agenti in sette livelli, dai foundation model all’ecosistema degli agenti. Gli architetti della sicurezza lo abbinano alla AI Controls Matrix v1.1, rilasciata il 22 giugno 2026, e ai suoi 247 obiettivi di controllo in 18 domini per la mappatura di governance, rischio e compliance (GRC).

NIST IR 8596 and IR 8587

Le linee guida di NIST sugli agenti si concentrano su identità e token, e i due documenti si trovano in fasi diverse. IR 8596, il Cyber AI Profile alla base della regola di identità sopra riportata, rimane una bozza preliminare iniziale del dicembre 2025. IR 8587 sulla protezione dei token è diventato definitivo a settembre 2026. Il NCCoE ha proposto un progetto su identità e autorizzazione degli agenti che applica IR 8587 insieme a NIST SP 800-207 e SP 800-63-4.

Linee guida CISA sull’AI agentica

La guida di CISA Careful Adoption of Agentic Artificial Intelligence (AI) Services, pubblicata il 1 maggio 2026 con l’ACSC di ASD e altri partner, fornisce a sviluppatori, vendor e operatori best practice per l’adozione di sistemi agentici. Indica privilege creep, disallineamento comportamentale e registrazioni degli eventi poco chiare come i rischi aggiunti dai sistemi agentici e chiede alle organizzazioni di tenere conto dell’AI agentica nel proprio modello di sicurezza e nella propria postura di rischio.

ISO/IEC 42001

ISO/IEC 42001 è uno standard certificabile per i sistemi di gestione dell’AI, pubblicato per la prima volta nel dicembre 2023, che fornisce ai team GRC e ai CISO la struttura di governance entro cui opera un programma di agenti. Non contiene controlli specifici per gli agenti, quindi abbinalo a uno dei framework tecnici sopra indicati.

EU AI Act

Il EU AI Act, Regolamento (UE) 2024/1689, è obbligatorio per i fornitori e gli utilizzatori di sistemi di AI che rientrano nel suo ambito, ma non definisce alcuna categoria di agente AI. Un agente rientra nell’Act come sistema di AI. Il Digital Omnibus 2026 ha spostato al 2 dicembre 2027 gli obblighi ad alto rischio per i sistemi stand-alone. Scegli un framework di sicurezza per agenti AI come baseline dei controlli, mappa su di esso gli obblighi dell’Act e collega entrambi agli strumenti che governano prompt, identità, asset cloud, indagini e risposta.

Proteggi gli agenti AI con SentinelOne

Gli agenti agiscono alla velocità della macchina. I controlli che li circondano devono tenere il passo, da un luogo che l’agente non può raggiungere. SentinelOne Prompt Security governa agenti, server MCP e prompt, mentre Singularity™ Identity blocca il furto di credenziali e l’escalation dei privilegi in fase di runtime. Singularity Endpoint protegge gli host su cui vengono eseguiti gli agenti e Purple AI con Singularity Hyperautomation accelera indagine e risposta.

Prompt Security trova ogni agente AI e server MCP nel tuo ambiente tramite un MCP Gateway, un’estensione del browser, plugin di sicurezza e integrazioni API, quindi mappa ogni connettore, strumento e plugin con cui ciascun agente interagisce. Assegna un punteggio di rischio a ciascun agente e server MCP, protegge dai tentativi di jailbreak, applica policy su ciò a cui gli agenti possono accedere e ciò che possono fare, e mantiene un log ricercabile con timestamp di ogni sessione, azione e strumento. Singularity Identity blocca il movimento laterale, automatizza la remediation che disabilita le identità compromesse e analizza continuamente credenziali deboli, esposte o compromesse in Active Directory e nei provider di identità cloud, inclusi Entra ID, Okta, Ping, Duo e SecureAuth.

Singularity Endpoint applica Behavioral AI sulle workstation e sui workload cloud in cui vengono eseguiti agenti desktop e di coding. Blocca malware fileless, attacchi alla supply chain e exploit zero-day in tempo reale, online o offline. Può contenere autonomamente un host compromesso, senza attendere un passaggio manuale di isolamento, e il rollback con 1 clic annulla le modifiche non autorizzate. AI Security Posture Management in Singularity Cloud Security rileva pipeline e modelli AI negli account cloud.

Purple AI™ Agentic Investigation esegue l’analisi degli avvisi, mette in evidenza le prove e indica al tuo security operations center (SOC) cosa fare dopo. Lo studio Business Value di IDC ha rilevato che i clienti hanno identificato le minacce il 63% più velocemente e le hanno corrette il 55% più velocemente. Singularity Hyperautomation, integrato nella Singularity Platform, esegue workflow di risposta no-code, inclusi i passaggi di contenimento sopra indicati.

Richiedi una demo di SentinelOne per vedere come il tuo team può dare a ogni agente AI un confine che non può oltrepassare.

Liberate la cybersicurezza alimentata dall'intelligenza artificiale

Elevate la vostra posizione di sicurezza con il rilevamento in tempo reale, la risposta automatica e la visibilità totale dell'intero ambiente digitale.

Richiedi una demo

Conclusione

Ogni controllo di sicurezza per agenti AI segue una regola: deve trovarsi da qualche parte che l’agente non possa raggiungere o riscrivere, nemmeno con le proprie credenziali. I controlli comportamentali riducono la frequenza con cui un agente tenta qualcosa di dannoso. I controlli infrastrutturali fissano il limite rigido di ciò che un agente compromesso può fare. Inizia dall’inventario, perché non puoi definire l’ambito, limitare o contenere un agente di cui non sai l’esistenza.

Da lì, abbina i controlli di ciascun agente all’autorità che detiene, registra il suo ambito prima ancora di doverlo contenere e prova la risposta prima che un incidente la renda necessaria. I framework indicano già i rischi e i controlli che li contengono esistono già. Costruisci ora i confini e un agente compromesso si scontrerà con limiti che il tuo team ha definito in anticipo.