I quattro vettori di attacco per i quali il vostro framework di sicurezza per l'IA non è stato progettato

Punti di forza

• L’IA agentica comporta nuovi rischi per la sicurezza poiché pianifica, memorizza e agisce su più sistemi, anziché limitarsi a un singolo ciclo di richiesta-risposta.
• I dati di addestramento “avvelenati” possono influenzare in modo impercettibile il comportamento del modello su larga scala, anche quando il modello sembra funzionare normalmente nei test standard.
• I database dei vettori compromessi possono influenzare le decisioni degli agenti alterando il contesto su cui si basa il modello, facendo apparire legittimo un comportamento scorretto.
• L’identità degli agenti non controllati crea un problema di controllo degli accessi alla velocità delle macchine che i tradizionali sistemi di identità incentrati sull’uomo non sono in grado di gestire.
• Le decisioni a cascata basate su uno stato errato possono diffondere errori in più agenti e flussi di lavoro, rendendo molto più difficili il rollback e il ripristino.

Gli strumenti, i controlli e le politiche di governance in uso nella maggior parte delle aziende sono stati progettati per sistemi che rispondono a domande: strumenti di recupero, copiloti, assistenti generativi. Sistemi che rispondono a un prompt e poi si fermano. Quando qualcosa andava storto, il guasto era isolato. Bastava correggere il prompt, regolare la configurazione e andare avanti.

L’IA agentica non funziona in questo modo. Questi sistemi pianificano, ricordano ed eseguono operazioni in tutta l’azienda senza istruzioni umane passo dopo passo. Mantengono lo stato. Si coordinano con altri agenti. Agiscono sui sistemi di produzione: scrivono nei database, attivano flussi di lavoro, prendono decisioni alla velocità delle macchine. Questo cambiamento architettonico introduce quattro vettori di minaccia che i sistemi di sicurezza esistenti non sono mai stati progettati per affrontare. Se la vostra strategia di governance dell’IA non ne tiene conto, è probabile che siate esposti a rischi di cui forse non vi rendete conto.

1. Dati di addestramento contaminati

Un sistema di IA è affidabile solo quanto i dati con cui è stato addestrato. Questa affermazione è sempre stata vera. Ciò che è cambiato è la superficie di attacco.

Nelle implementazioni di IA agentica, le pipeline di addestramento sono più ampie, più complesse e spesso assemblate da più fonti: dati interni, feed di terze parti, set di dati forniti dai fornitori. Ogni dipendenza in quella catena rappresenta un potenziale punto di iniezione. Un attore malintenzionato in grado di influenzare i dati di addestramento – attraverso la compromissione della catena di approvvigionamento, l’accesso da parte di personale interno o la contaminazione di una fonte di dati condivisa – può plasmare il comportamento del modello su larga scala. Ciò che rende questa situazione particolarmente pericolosa è che i modelli “avvelenati” spesso danno risultati normali nei benchmark standard. La manipolazione può essere «chirurgica»: progettata per produrre risultati specifici in contesti specifici, pur comportandosi correttamente in ogni altro caso.

Quando l’effetto si manifesta in produzione, il modello è già in uso da settimane o mesi, e risalire alla fonte della contaminazione richiede proprio quel tipo di tracciabilità relazionale dei dati di cui la maggior parte delle organizzazioni non dispone. La domanda da porsi è: siete in grado di fornire una documentazione completa e verificabile dei dati utilizzati per l’addestramento dei vostri modelli, in un determinato momento?

2. Banche dati vettoriali compromesse

I database vettoriali costituiscono il livello di memoria dei sistemi basati su agenti. Prima di agire, un agente interroga un database vettoriale per recuperare il contesto pertinente – interazioni passate, conoscenze di dominio, dati di riferimento – che determina la sua azione successiva. La maggior parte dei team di sicurezza non considera i database vettoriali alla stregua di altri archivi di dati sensibili. Eppure dovrebbero farlo. Un database vettoriale compromesso non si limita a restituire risposte errate. Influenza le decisioni che ne conseguono. Gli embedding iniettati – contenuti malevoli inseriti nell’archivio vettoriale – possono reindirizzare il comportamento dell’agente in modi che dall’esterno appaiono del tutto legittimi.

Un agente a cui viene chiesto di approvare una transazione recupera un contesto che riformula sottilmente i criteri di approvazione. Un agente che gestisce le comunicazioni con i clienti estrae un contesto che orienta le risposte nella direzione preferita dall’autore dell’attacco. L’azione sembra corretta. Il ragionamento sembra valido. Ma il contesto sottostante è stato manipolato.

Questo vettore di attacco è particolarmente difficile da rilevare perché opera al di sotto del livello del modello. Il monitoraggio standard del modello non lo individua. Il modello si comporta esattamente come addestrato: è il contesto su cui basa il proprio ragionamento ad essere stato corrotto. La domanda da porsi è: il vostro database vettoriale viene considerato una risorsa di dati sensibile e soggetta a regole di governance, con controlli di accesso, monitoraggio dell’integrità e registrazione degli audit paragonabili a quelli dei vostri database di produzione più critici?

3. Identità degli agenti non governati

In un’architettura multi-agente, gli agenti non si limitano a interagire con i dati, ma interagiscono anche tra loro. Generano subagenti, delegano compiti, richiedono output e sintetizzano i risultati provenienti da agenti con cui non sono mai stati esplicitamente collegati. Per farlo, effettuano l’autenticazione, presentano le credenziali e instaurano un rapporto di fiducia.

L’identità degli agenti costituisce il livello di controllo degli accessi per l’impresa autonoma – ed è una lacuna che i fornitori di soluzioni per la sicurezza delle identità e i provider di identità (IDP) non riescono a colmare. I loro modelli di governance sono concepiti per l’identità umana.

Le identità degli agenti create secondo quelle stesse regole appaiono del tutto legittime: sono state configurate correttamente e hanno rispettato la politica aziendale. L’IDP non sta fallendo: semplicemente non dispone di uno schema per determinare se un agente stia agendo al di fuori del contesto per cui è stato creato, se i suoi privilegi siano stati silenziosamente ampliati o se stia coordinando attività dove non dovrebbe.

Questa vulnerabilità è qualitativamente diversa dalla tradizionale compromissione delle credenziali. Quando le credenziali di un utente umano vengono rubate, l’autore dell’attacco agisce entro i limiti delle autorizzazioni di quell’utente, alla velocità di un essere umano. Quando l’identità di un agente viene compromessa, l’autore dell’attacco ottiene l’accesso al livello decisionale autonomo: la capacità di avviare flussi di lavoro, approvare azioni, coordinarsi con altri agenti ed esfiltrare dati alla velocità di una macchina, su larga scala, attraverso canali che appaiono del tutto normali.

Le violazioni a livello di identità sono anche tra le più difficili da rilevare a posteriori. Le azioni degli agenti intraprese con un’identità compromessa non appaiono anomale: sembrano comportamenti legittimi degli agenti. E poiché sono generate da un sistema anziché da un essere umano, il volume può diventare enorme prima che qualcuno se ne accorga.

Recovery aggrava il problema. La maggior parte delle procedure di Recovery dell’IA si concentra sul ripristino dei dati: set di addestramento, pesi dei modelli, configurazioni delle pipeline. L’identità è raramente inclusa nell’elenco. Un sistema ripristinato con dati puliti ma con configurazioni di identità non allineate non è in realtà ripristinato. Si tratta di un sistema pulito con un livello di accesso compromesso. La domanda da porsi è: l’identità degli agenti viene gestita con lo stesso rigore dell’identità umana, ovvero con la gestione del ciclo di vita, l’accesso con privilegi minimi e l’inclusione nei piani di ripristino?

4. Decisioni a cascata basate su una situazione errata

I primi tre vettori di attacco sono isolati. Questo invece è sistemico – e per molti versi può rivelarsi il più difficile da contenere. Le architetture multi-agente sono progettate per il coordinamento. Gli agenti condividono il contesto, si scambiano gli output e si basano sul lavoro reciproco. È proprio quel coordinamento a renderli potenti. Ed è anche ciò che fa propagare i guasti.

Un agente che opera su una memoria corrotta non fallisce in modo netto. Produce output – decisioni, azioni, dati – che vengono utilizzati da altri agenti. Questi agenti, a loro volta, producono i propri output. Quando la corruzione originale emerge come qualcosa di osservabile, lo stato errato potrebbe aver già interessato decine di processi a valle, su più agenti, senza un percorso di rollback netto.

È proprio questo che rende il divario contestuale così significativo. In ogni momento, il vostro sistema di IA è costituito da una versione del modello, un insieme di dati di addestramento, un archivio di artefatti, una configurazione della pipeline e un insieme di interazioni attive degli agenti – tutti elementi che devono riflettere lo stesso stato operativo per costituire un sistema affidabile e recuperabile. Quando ciò non avviene, non si tratta semplicemente di un errore. Si ha un sistema che è coerente nelle singole parti ma incoerente nel suo insieme. Ciascuno degli strumenti specifici può verificare la propria porzione di dati. Nessuno di essi è in grado di confermare che i vari elementi siano correlati tra loro. Non si tratta di un problema di monitoraggio risolvibile semplicemente aggiungendo un altro strumento. È una lacuna strutturale, e l’unico modo per colmarla è un sistema in grado di registrare lo stato dell’IA in modo relazionale: cosa era in esecuzione, su quali dati, con quale configurazione e in quale momento.

La domanda da porsi è questa: se oggi la vostra infrastruttura di intelligenza artificiale venisse compromessa, sareste in grado di identificare con esattezza lo stato in cui si trovava ogni componente prima dell’incidente – e di dimostrarlo?

Cosa significa questo per la vostra strategia di sicurezza

Ciascuno di questi quattro vettori richiede una risposta difensiva diversa. Tuttavia, essi condividono un’implicazione comune: i quadri di governance e resilienza concepiti per la precedente era dell’IA non coprono le modalità di fallimento dell’era degli agenti. Per garantire un’IA agentica è necessario estendere il proprio framework in tre direzioni:

• Più in profondità, nei livelli dei dati e dell’identità che si trovano al di sotto del modello.
• In senso più ampio, in modo da coprire le interazioni tra agenti che il monitoraggio attuale non rileva.
• Dal punto di vista relazionale, per cogliere non solo lo stato dei singoli componenti, ma anche il modo in cui questi si integrano tra loro in qualsiasi momento.

Quest’ultimo requisito è quello che la maggior parte delle organizzazioni non ha ancora affrontato. Ed è proprio questo che determinerà se, quando qualcosa andrà storto, si avrà a disposizione un sistema recuperabile o una serie di report apparentemente accurati che descrivono qualcosa che non esiste più. Leggi “The Agentic Blind Spot: Why AI Resilience Demands a System of Record” per scoprire perché è necessario un SOR per garantire la coerenza e l’accuratezza dei tuoi dati di IA.

Domande frequenti

D: Perché i sistemi di IA agentica sono più rischiosi rispetto ai tradizionali strumenti di IA generativa?

R: I sistemi agentici non si limitano a rispondere ai prompt. Gestiscono lo stato, si coordinano con altri agenti e intraprendono azioni negli ambienti di produzione, il che amplia la superficie di attacco ben oltre la semplice manipolazione dei prompt.

D: Perché è così difficile individuare i dati di addestramento contaminati?

R: La manipolazione può essere altamente mirata, influenzando solo situazioni specifiche senza alterare i normali valori di riferimento. Ciò significa che un modello può sembrare funzionante finché il comportamento dannoso non si manifesta nell’uso reale.

D: In che modo un database vettoriale può rappresentare un problema di sicurezza?

R: Un database vettoriale definisce il contesto su cui si basa un agente prima di agire. Se tale contesto viene alterato, l’agente potrebbe prendere decisioni che a prima vista sembrano ragionevoli, ma che in realtà sono influenzate da dati dannosi.

D: Perché l’identità di un agente è diversa dall’identità umana?

R: L’identità di un agente è legata alle azioni autonome, alla delega e all’esecuzione alla velocità di una macchina. La governance tradizionale dell’identità è concepita per le persone, quindi spesso non rileva se un agente stia agendo al di fuori del contesto previsto.

D: Perché la propagazione a cascata di stati anomali rappresenta un problema così grave nei sistemi multi-agente?

A: Quando un agente elabora un output corrotto, l’errore può propagarsi agli agenti e ai flussi di lavoro a valle. Il risultato non è solo una decisione errata, ma una catena di errori concatenati.

D: In che modo le organizzazioni possono migliorare la sicurezza dell’IA?

R: Estendendo la governance fino ai livelli dei dati e delle identità, monitorando le interazioni tra gli agenti e tenendo traccia dello stato dell’IA in modo relazionale, per consentire loro di ricostruire ciò che è accaduto durante un incidente.

Michael Thelander è direttore senior del marketing di prodotto presso Commvault.

Blog correlati

• • Garantire la sicurezza dell’IA grazie a una governance unificata dell’accesso ai dati
  • Dati più intelligenti, IA più sostenibile
  • Data Activate: Sfruttare il potenziale dei dati affidabili per l’innovazione nell’IA
  • Gli agenti di IA sono ovunque. Sai cosa stanno facendo?
  • Dalla sperimentazione alla pratica: creare agenti di intelligenza artificiale di cui ci si può davvero fidare