Check Point Research (CPR), la divisione di Threat Intelligence di Check Point Software Technologies Ltd. (NASDAQ : CHKP), pioniere e leader globale nelle soluzioni di sicurezza informatica, ha rilevato alcuni difetti critici nel codice di Claude e vulnerabilità negli strumenti di sviluppo dell’IA, tra cui il command injection in OpenAI Codex CLI, che potrebbero esporre le chiavi API e reindirizzare il traffico autenticato. I ricercatori hanno anche documentato come le istruzioni nascoste nei flussi di lavoro dell’IA possano manipolare gli agenti perché rivelino segreti o intraprendano azioni controllate dagli attaccanti.
L’IA non ha introdotto una nuova categoria di rischio ben definita. Il vero cambiamento è che l’IA attraversa le categorie già esistenti. I dipendenti utilizzano, infatti, gli strumenti di IA per riassumere, analizzare, codificare, creare e prendere decisioni più rapidamente. Gli sviluppatori incorporano modelli nelle applicazioni collegate a clienti, documenti, database e sistemi interni. Gli agenti recuperano informazioni, richiamano strumenti, invocano API e agiscono attraverso i flussi di lavoro. Oggi l’IA non rimane più diligentemente all’interno dei confini di una singola applicazione. Sta diventando un nuovo livello di esecuzione in tutta l’azienda: un prompt inserito in un browser può influenzare una decisione aziendale. Un documento recuperato può modificare la risposta di un’applicazione. L’output di un modello può innescare l’azione di un agente. Una chiamata a uno strumento può spostare dati, modificare un record o avviare un flusso di lavoro prima che un essere umano abbia il tempo di rendersi conto di ciò che è successo.
Ecco perché le aziende hanno bisogno di un piano di difesa basato sull’intelligenza artificiale.
“La lacuna nella sicurezza dell’IA è di natura architettonica, afferma Pierluigi Torriani, Security Engineering Manager per Check Point. “La maggior parte delle aziende comprende che l’IA modifica il modello di rischio. La domanda più complessa è se dispongano dell’architettura necessaria per controllarla”.
Secondo il Cloud Security Report 2026 di Check Point, il 77% delle organizzazioni ha modificato la propria strategia di sicurezza in risposta all’IA, ma solo il 26% dichiara di disporre dell’architettura necessaria per attuarla. Questo crea un modello aziendale di tipo familiare: la strategia è andata avanti, ma l’architettura sta ancora cercando di mettersi al passo.
Vengono redatte le policy, costituiti comitati di governance, pubblicate le regole di utilizzo accettabile. I team implementano filtri, misure di protezione dei modelli, controlli dei dati o processi di test. Tutto questo è importante. Ma non crea automaticamente un modello di controllo coerente. Il rischio legato all’IA non rimane confinato a un unico livello. Si muove tra dipendenti, applicazioni, modelli, dati, strumenti, API e agenti. Si manifesta attraverso l’interazione, il contesto, l’intento e il comportamento.
Controlli puntuali possono risolvere problemi circoscritti, esaminare un percorso di traffico, filtrare un input, monitorare uno strumento o testare un modello in un momento specifico, ma non vedono l’intero percorso.
Un singolo flusso di lavoro di IA può iniziare con una richiesta dell’utente, recuperare il contesto, passare attraverso un modello, generare un output e attivare un’azione tramite un agente o uno strumento. Ogni fase può sembrare legittima se considerata isolatamente. Il rischio spesso emerge successivamente. La frammentazione diventa un problema. Un team può gestire l’utilizzo dell’IA da parte dei dipendenti, un altro può occuparsi della sicurezza delle applicazioni di IA, un altro ancora può revisionare i modelli, mentre qualcun altro gestisce l’identità e l’accesso e altri si occupano della protezione dei dati. Ciascuno vede solo una parte del quadro. Nessuno vede l’intero percorso di esecuzione.
AI Defense Plane è un’architettura di sicurezza unificata per individuare, proteggere, governare e convalidare il comportamento dell’IA in tutta l’azienda. Non si tratta di un unico punto di controllo. È un modello di controllo coordinato su tre piani collegati:
- i dipendenti che utilizzano strumenti di IA,
- le applicazioni che integrano l’IA nei flussi di lavoro
- gli agenti che accedono ai dati.
Attraverso questi piani, l’AI Defense Plane riunisce quattro funzionalità che operano in sinergia:
- Discovery: mostra dove viene utilizzata l’IA, quali dati la attraversano e dove può intervenire,
- Protection: previene attacchi basati sui prompt, l’esposizione dei dati, output non sicuri, l’uso improprio degli strumenti e comportamenti non conformi alle policy durante l’esecuzione
- Governance: applica le policy in modo coerente tra utenti, applicazioni, agenti e ambienti
- Assurance: verifica continuamente che i sistemi e i controlli di IA funzionino in modo sicuro man mano che cambiano modelli, prompt, strumenti, autorizzazioni e flussi di lavoro.
I tre livelli di rischio dell’IA aziendale mostrano dove l’IA entra, dove opera e dove agisce. Non essendo compartimenti stagni possono far crescere il problema. Un flusso di lavoro basato su un copilot creato da un dipendente può iniziare ad assomigliare molto a un’applicazione di IA sviluppata da un team di sviluppo. Può accedere ai dati aziendali, combinare il contesto proveniente da più sistemi e attivare azioni su diversi strumenti aziendali. Il proprietario può essere diverso. Il modello di rischio no.
Immagine 1 – i tre livelli di rischio dell’Intelligenza Artificiale
- Dipendenti: l’IA entra nel flusso di lavoro quotidiano
Per molte organizzazioni, è proprio nell’uso dell’IA da parte dei dipendenti che il rischio si manifesta per primo. Le persone utilizzano strumenti di IA per sintetizzare documenti, scrivere codice, analizzare dati, redigere risposte ai clienti e risolvere problemi. Gran parte di questo utilizzo avviene tramite browser, strumenti SaaS, account personali, copiloti e applicazioni di produttività.
Spesso, il problema più grave è che le normali attività lavorative procedono a un ritmo troppo veloce perché i controlli esistenti possano stare al passo. Solo il 5% delle organizzazioni dichiara di avere piena visibilità sull’utilizzo degli strumenti di IA, sull’accesso ai dati e sul loro movimento.
La sicurezza dell’IA per la forza lavoro deve operare dove i dipendenti utilizzano effettivamente l’IA: su strumenti autorizzati e non autorizzati, upload e download, sessioni del browser, applicazioni SaaS e flussi di lavoro in cui si spostano dati sensibili.
- Applicazioni: l’IA cambia il comportamento del software
Le applicazioni di IA sono diverse dalle applicazioni tradizionali perché il loro comportamento viene modellato dinamicamente durante l’esecuzione. La stessa applicazione può comportarsi in modo diverso a seconda del prompt, dei dati recuperati, delle istruzioni di sistema, degli strumenti e dello stato. È qui che la sicurezza delle applicazioni tradizionali inizia ad essere fallace. La richiesta può essere sintatticamente valida e tuttavia non sicura. La risposta può sembrare utile mentre in realtà divulga informazioni sensibili. I contenuti recuperati possono manipolare il modello senza che l’utente veda mai l’istruzione. Garantire la sicurezza delle applicazioni di IA richiede una protezione in fase di esecuzione lungo il percorso in cui vengono valutati prompt, contesto, output e azioni.
- Agenti: l’IA diventa un attore all’interno dell’azienda.
Gli agenti rappresentano la versione più marcata del passaggio dalla risposta all’azione. Non si limitano a generare testo. Recuperano dati, prendono decisioni, richiamano strumenti, utilizzano credenziali, chiamano API ed eseguono attività per conto di utenti, team, applicazioni o flussi di lavoro.
Il Cloud Security Report 2026 ha rilevato che il 64% delle organizzazioni dispone già di agenti IA in fase pilota o di produzione, e il 12% ha concesso agli agenti un accesso privilegiato ai sistemi core.
Il principio del privilegio minimo rimane essenziale, ma non è sufficiente. A un agente può essere consentito l’accesso a uno strumento, ma potrebbe comunque utilizzarlo nel momento sbagliato, per il motivo sbagliato o nel contesto sbagliato. La sicurezza degli agenti IA deve controllare il livello di esecuzione: prompt, flussi di dati, output, chiamate agli strumenti e azioni.
La sicurezza dell’IA deve operare in fase di runtime, in altre parole Il comportamento dell’IA dipende dall’interazione in tempo reale: il prompt dell’utente, il contesto recuperato, i dati disponibili, gli strumenti collegati, le istruzioni dell’agente, le autorizzazioni e lo stato dell’ambiente. Il runtime è il momento in cui il rischio legato all’IA diventa reale.
Solo il 17% delle organizzazioni ha ampiamente implementato controlli LLM in fase di esecuzione, anche se i carichi di lavoro GenAI e i sistemi agent stanno entrando in produzione.
La protezione runtime estende i controlli esistenti al livello semantico in cui si definisce il comportamento dell’IA. Pone domande a cui i controlli tradizionali non sono stati progettati per rispondere: cosa sta cercando di far fare l’utente o il sistema all’IA? I dati sensibili vengono esposti? L’azione dell’agente è in linea con l’intento dell’utente e la policy aziendale? La chiamata allo strumento è appropriata dato il contesto?
“La sicurezza dell’IA non può essere considerata come un semplice filtro di implementazione una tantum”, afferma Pierluigi Torriani, Security Engineering Manager di Check Point. “I modelli cambiano, così come i prompt e le autorizzazioni. Le applicazioni cambiano e gli agenti acquisiscono nuovi strumenti. Le tecniche di attacco si evolvono e un sistema che il mese scorso funzionava in modo sicuro potrebbe comportarsi diversamente dopo un aggiornamento del modello, una nuova integrazione o una modifica del flusso di lavoro”.
Il 56% delle organizzazioni non dispone di un processo formale di test di sicurezza GenAI o esegue test solo in modo ad hoc.
L’IA è passata dalle parole ai fatti e la sicurezza deve ora passare da controlli frammentati a un piano di difesa IA unificato.
