Gli agenti di IA si stanno diffondendo nelle aziende a un ritmo molto più rapido di quanto la maggior parte dei programmi di sicurezza sia stata progettata per gestire. Non si limitano più a rispondere a domande o a generare contenuti, sono in grado di leggere e-mail, accedere ad applicazioni SaaS, eseguire query su database, richiamare API, utilizzare strumenti MCP, modificare record ed eseguire flussi di lavoro aziendali. In altre parole, l’IA sta passando dalla generazione di risposte all’esecuzione di azioni. Per i CISO e i dirigenti aziendali ciò cambia il quadro della sicurezza. La domanda non è più se un’organizzazione stia utilizzando l’IA in modo sicuro, ma se si è in grado di identificare, gestire, monitorare e controllare con sicurezza ogni agente IA prima che diventi il prossimo insider privilegiato.

È fondamentale che i responsabili della sicurezza e i dirigenti aziendali tengano conto delle seguenti considerazioni:

1. Considerare un agente di IA un potenziale “insider privilegiato”

Proprio come un’identità umana con privilegi, un agente IA, per esempio connesso a Microsoft 365, Salesforce, ServiceNow, un ambiente cloud e database interni, potrebbe essere in grado di leggere informazioni, prendere decisioni, richiamare strumenti e modificare i sistemi, potenzialmente in pochi secondi e senza che qualcuno approvi ogni singola azione. L’agente non ha bisogno di intenzioni malevole per diventare pericoloso.

Troppo accesso, troppa autonomia e troppo poca supervisione possono creare un rischio simile a quello rappresentato da un insider. Gli agenti IA stanno diventando dipendenti aziendali: non si limitano a generare testo; recuperano dati, utilizzano credenziali, richiamano strumenti, interpellano API ed eseguono attività per conto degli utenti e dei flussi di lavoro.

Mazhar Hamayun, Evangelist & Regional Security Architect, Check Point Software Technologies

2. La gestione delle identità e degli accessi (IAM) e il principio del privilegio minimo non sono sufficienti per controllare gli agenti di IA, sono essenziali, ma da soli non bastano.

La gestione tradizionale delle identità e degli accessi (IAM) risponde alla domanda: A cosa è autorizzata ad accedere questa identità? Ma L’IA agentica ci costringe a porne un’altra: A questo agente dovrebbe essere consentito di eseguire questa particolare azione, in questo contesto, proprio ora?

Immaginiamo che un agente abbia legittimamente accesso a un database clienti. Potrebbe aver bisogno dell’accesso in LETTURA per svolgere il proprio lavoro. Ma questo dovrebbe significare automaticamente che può CANCELLARE i record dei clienti? Probabilmente no.

Questa è la differenza tra il controllo degli accessi e il controllo delle azioni, o dei risultati. Check Point fonda il proprio modello di sicurezza basato su agenti di IA proprio su questa distinzione. In un ambiente agentico, la sicurezza smette di essere una questione di chi ha accesso e diventa una questione di cosa è consentito fare all’IA. L’accesso può essere valido e il risultato comunque sbagliato. Un controllo delle autorizzazioni può andare a buon fine mentre l’azione che ne sta alla base è tale che nessun operatore ragionevole approverebbe.

3. Le organizzazioni dovrebbero stabilire limiti rigidi alle operazioni degli agenti

Un’azienda potrebbe, per esempio, adottare una policy chiara dove a nessun agente di IA autonomo è consentito eseguire un’operazione DELETE sui dati di produzione, lasciando libertà in altre operazioni come CREATE, READ o UPDATE.

Il controllo di sicurezza dovrebbe esistere al di fuori dell’agente ed essere applicato tecnicamente. Se l’agente decide che la cancellazione è il modo migliore per raggiungere il proprio obiettivo, la policy di sicurezza aziendale dovrebbe comunque avere l’ultima parola.

4. Le piattaforme di sicurezza devono applicare controlli a livello di azione sugli agenti di IA

La documentazione di Workforce AI Security di Check Point relativa alla gestione delle interazioni degli agenti descrive la visibilità sugli agenti di IA che operano tramite i server MCP e sugli strumenti a loro disposizione. Gli amministratori possono visualizzare le operazioni degli agenti classificate come Creazione, Lettura, Aggiornamento ed Eliminazione (CRUD), analizzare il rischio associato a tali funzionalità e limitare l’accesso agli strumenti a più alto rischio.

Ancora più importante, il framework delle policy degli agenti di Check Point affronta esplicitamente il controllo delle azioni automatizzate. Gli esempi di policy di controllo nella guida amministrativa di Workforce AI Security mostrano come le policy possano definire l’ambito dello strumento o dell’operazione CRUD e quindi applicare un’autorizzazione o un blocco. Ciò è importante perché il controllo degli accessi ha già approvato l’azione prima che avvenga la chiamata allo strumento. Gli agenti operano con token ereditati che in genere concedono l’ambito autorizzato completo. L’autenticazione verifica chi sta effettuando la richiesta, non il motivo. Poiché gli agenti possono agire su documenti, pagine web o output di strumenti non attendibili, la richiesta potrebbe non provenire dall’utente. Indipendentemente dal fattore scatenante, le misure di sicurezza operative rimangono in vigore. Una policy di eliminazione impedisce la cancellazione, indipendentemente da ciò che ha spinto l’agente a tentarla.

Si tratta di un’evoluzione importante nel campo della sicurezza informatica. Non ci limitiamo, infatti, a osservare ciò che un agente ha fatto ieri, ma stiamo procedendo verso la possibilità di decidere se un’azione debba essere consentita prima che avvenga.

5. L’applicazione in fase di esecuzione è molto importante per gli agenti di IA, dal momento che questi operano molto rapidamente.

Immaginiamo questa sequenza: Dipendente → Agente IA → Modello → Strumento MCP → API → DELETE. L’agente potrebbe essere autenticato, la chiamata API potrebbe essere tecnicamente valida e l’agente potrebbe persino ritenere che la cancellazione sia necessaria per soddisfare la richiesta dell’utente. Ma la policy aziendale stabilisce che gli agenti autonomi non possano cancellare i record di produzione. La sicurezza in fase di esecuzione fornisce un punto di controllo prima che venga eseguita l’azione finale.

Check Point descrive il proprio approccio alla sicurezza degli agenti IA come una valutazione in tempo reale di prompt, risposte del modello, contenuti esterni, chiamate agli strumenti e azioni dell’agente, consentendo alle policy di bloccare comportamenti non sicuri o non autorizzati prima dell’esecuzione.

Si tratta di una distinzione significativa: le autorizzazioni definiscono ciò che un agente può fare. La policy di runtime aiuta a determinare se debba farlo in quel momento.

6. Un essere umano dovrebbe essere responsabile di un agente di intelligenza artificiale

Ogni agente di produzione dovrebbe avere un responsabile chiaramente identificato. Per gli agenti a rischio più elevato, è fondamentale che ci sia un responsabile aziendale e un responsabile tecnico.

Gli agenti possono eseguire attività in modo autonomo, ma la responsabilità non può essere autonoma. Un agente senza un responsabile identificabile dovrebbe, alla fine, essere trattato alla stregua di un account privilegiato orfano.

7. L’iniezione di prompt compromette il modello di fiducia degli agenti di IA

Il problema dell’identità diventa particolarmente interessante. Supponiamo che un contenuto malevolo induca un agente a richiamare uno strumento legittimo. L’agente utilizza quindi credenziali valide per eseguire un’azione che i suoi progettisti non avevano mai previsto. L’autenticazione funziona, l’autorizzazione, tecnicamente, potrebbe aver funzionato, ma il comportamento era errato.

Le linee guida di Check Point sulla sicurezza degli agenti di IA evidenziano l’iniezione di prompt, gli attacchi indiretti, l’esposizione di dati sensibili e l’uso non autorizzato di strumenti come rischi che richiedono controlli contestuali in fase di esecuzione. Ecco perché l’autenticazione da sola non può stabilire una fiducia permanente per un’identità autonoma.

8. Il modello Zero Trust per gli agenti di IA deve evolvere attraverso decisioni di fiducia, che deve restare dinamica

I principi non cambiano sostanzialmente, è la loro applicazione a cambiare. Per un agente, la decisione si traduce sempre più in: Identità + Contesto + Dati + Strumento + Azione richiesta + Comportamento = Decisione di fiducia

Un agente delle risorse umane che consulta dieci schede dei dipendenti potrebbe essere perfettamente normale. Lo stesso agente che improvvisamente richiede 20.000 schede merita un’ulteriore valutazione. È prevedibile che un agente di sviluppo scriva codice.

Lo stesso agente che tenti di modificare le policy IAM non dovrebbe godere di fiducia semplicemente perché si è autenticato con successo. La fiducia deve rimanere dinamica.

9. Una buona governance del ciclo di vita degli agenti IA

Sappiamo già come gestire gran parte di questo processo grazie alla governance delle identità.

È opportuno applicare la stessa disciplina della governance delle identità agli agenti: Individuazione → Registrazione → Assegnazione del responsabile → Autenticazione → Autorizzazione → Monitoraggio → Revisione → Sospensione → Ritiro.

Quando viene creato un agente, si deve stabilire chi ne è il responsabile, quando gli viene concesso l’accesso, si applica il principio del privilegio minimo, quando il suo scopo cambia, si devono rivedere le sue autorizzazioni, quando il suo comportamento cambia, si rivaluta l’affidabilità. E quando l’agente viene ritirato, si revocano le sue credenziali, i token, le autorizzazioni API e l’accesso agli strumenti.

L’innocua prova di concetto di oggi non dovrebbe diventare l’identità privilegiata dimenticata di domani.

10. I CISO dovrebbero porre precise domande ai propri team riguardo agli agenti di IA

• Quanti agenti sono operativi nel nostro ambiente?
• Chi ne è responsabile?
• Quali agenti hanno accesso a sistemi sensibili o privilegiati?
• Quali strumenti e server MCP possono utilizzare?
• Quali operazioni possono eseguire?
• Quali azioni sono esplicitamente vietate?
• Siamo in grado di rilevare comportamenti anomali degli agenti?
• Possiamo impedire un’azione pericolosa prima che venga eseguita?
• Possiamo disabilitare immediatamente un agente?
• Possiamo ricostruire ciò che è accaduto in seguito?

La soluzione Workforce AI Security di Check Point segue un approccio simile basato su individuazione, governance e protezione, fornendo visibilità su tutte le applicazioni e gli agenti di IA, policy di governance granulari e controlli in fase di esecuzione per le azioni rischiose degli agenti.

11. L’IA agentica non dovrebbe essere vista solo come un altro problema di sicurezza delle applicazioni

Stiamo creando una nuova classe di identità non umane dotate di potere decisionale.

Per decenni, la sicurezza informatica ha operato secondo il principio del privilegio minimo: concedere a un’identità solo l’accesso necessario per svolgere il proprio compito. L’IA agentica potrebbe richiederci di fare un passo in più, verso ciò che si potrebbe definire «minima agenzia»: concedere a un agente IA solo l’autonomia necessaria per raggiungere il proprio scopo aziendale autorizzato, e nulla di più.

Alcune azioni possono essere consentite. Altre dovrebbero richiedere un contesto aggiuntivo o l’approvazione umana. E alcune azioni potrebbero semplicemente essere vietate. È così che si possono ottenere i vantaggi dell’IA autonoma senza cedere un’autorità illimitata. L’obiettivo non è rallentare l’adozione dell’IA, ma assicurarsi che la sicurezza evolva alla stessa velocità.