Un agente di intelligenza artificiale in grado di leggere la tua casella di posta, aggiornare i dati dei clienti o eseguire codice non ha bisogno solo di una serie di istruzioni ben scritte. Ha bisogno di limiti chiari su ciò a cui può accedere, cosa può modificare e cosa può condividere.

Collegare l’IA ai sistemi aziendali offre l’opportunità di ridurre il lavoro manuale e accelerare il processo decisionale. Tuttavia, crea anche vie d’accesso che consentono agli aggressori di manipolare tali decisioni, rubare informazioni o innescare azioni tramite strumenti legittimi.

La classifica OWASP Top 10 per le applicazioni basate su agenti fornisce un quadro di riferimento per comprendere e valutare i rischi di sicurezza legati agli agenti di IA. Basandoci su queste linee guida, analizziamo dieci minacce chiave e le misure concrete che le organizzazioni possono adottare per affrontarle.

Punti chiave

• Gli agenti di IA possono agire sui sistemi aziendali, rendendo le istruzioni compromesse o le decisioni errate un rischio per i dati, le finanze e le operazioni.
• Le principali minacce includono l’iniezione di prompt, autorizzazioni eccessive, abuso di identità, fuga di dati, integrazioni compromesse, memoria avvelenata, esecuzione di codice non sicuro, guasti a cascata, esaurimento delle risorse e supervisione inadeguata.
• Una sicurezza efficace richiede controlli su identità, dati, strumenti e ambienti operativi, con un accesso limitato a ciò di cui ogni agente ha bisogno.
• L’approvazione umana, il monitoraggio e procedure di risposta collaudate aiutano le organizzazioni a controllare le azioni sensibili, a rilevare gli abusi e a bloccare gli agenti quando qualcosa va storto.

Che cos’è un agente IA?

Un agente IA è un sistema software che utilizza l’intelligenza artificiale per svolgere attività per conto di un utente o di un’organizzazione. È in grado di interpretare un obiettivo, decidere quali passaggi intraprendere e utilizzare gli strumenti collegati per portarli a termine, con livelli variabili di supervisione umana.

Un agente collegato alla vostra casella di posta, al database dei clienti o all’ambiente cloud necessita di limiti chiari su ciò a cui può accedere, modificare e condividere. Senza tali controlli, un’istruzione dannosa o una decisione errata potrebbero comportare la divulgazione di dati, transazioni non autorizzate o interruzioni delle operazioni.

Che cos’è la sicurezza degli agenti di IA?

La sicurezza degli agenti IA consiste nel proteggere i sistemi di intelligenza artificiale in grado di pianificare attività, utilizzare strumenti e intraprendere azioni per conto di utenti o organizzazioni. Essa riguarda l’agente stesso, le applicazioni a cui è collegato, le sue autorizzazioni di accesso e le informazioni che elabora.

Un chatbot limitato a rispondere alle domande presenta un profilo di rischio diverso rispetto a un agente autorizzato a inviare e-mail, modificare configurazioni o approvare transazioni. Quando l’IA è in grado di agire, una risposta errata o manipolata può trasformarsi in un incidente aziendale.

1. Iniezione di prompt e dirottamento degli obiettivi

L’iniezione di prompt si verifica quando istruzioni dannose influenzano il comportamento di un sistema di IA. Nel caso degli agenti, tali istruzioni possono arrivare indirettamente tramite una pagina web, un’e-mail, un documento o la risposta di uno strumento incontrati durante l’esecuzione di un’attività legittima.

Ad esempio, un agente che esamina un documento di un fornitore potrebbe imbattersi in istruzioni che gli intimano di recuperare informazioni riservate e di inviarle altrove. L’autore dell’attacco sta tentando di trasformare il materiale che l’agente dovrebbe analizzare in comandi che questi è tenuto a seguire.

Si tratta di una sfida di sicurezza costante e le misure di protezione dei modelli da sole non eliminano il rischio.

Come ridurre il rischio: considerare i contenuti esterni come non attendibili. Limitare gli strumenti e le destinazioni che l’agente può utilizzare, vagliare gli input sospetti e richiedere l’approvazione per le azioni sensibili. Applicare restrizioni di accesso al di fuori del modello linguistico in modo che le istruzioni manipolate non possano semplicemente scavalcarle.

2. Autorizzazioni e autonomia eccessive

Un agente diventa più pericoloso quando le sue autorizzazioni superano il suo scopo. Un assistente addetto alla rendicontazione potrebbe aver bisogno di leggere i registri finanziari, ma non ha alcun motivo di modificarli o di avviare pagamenti.

Lo stesso principio vale per l’autonomia. Anche un’azione autorizzata potrebbe richiedere l’approvazione umana se comporta la cancellazione di dati, la modifica delle impostazioni di sicurezza o l’assunzione di un impegno esterno.

OWASP identifica l’eccesso di funzionalità, autorizzazioni e autonomia come cause alla base di un’eccessiva autonomia dell’agente.

Come ridurre il rischio: definire l’accesso minimo necessario per ogni attività. Separare le capacità di lettura e scrittura, limitare le funzioni disponibili e introdurre livelli di approvazione proporzionati al potenziale impatto. Rivedere le autorizzazioni ogni volta che cambiano le responsabilità di un agente.

3. Abuso dell’identità dell’agente e furto delle credenziali

Un agente di IA può operare tramite account di servizio, chiavi API, token di accesso o autorizzazioni delegate da un utente. Se queste credenziali vengono rubate o utilizzate in modo improprio, un aggressore potrebbe ottenere l’accesso agli stessi sistemi collegati.

Le identità condivise indeboliscono inoltre la responsabilità. Se diversi agenti utilizzano un unico account con ampi privilegi, diventa più difficile identificare quale agente abbia eseguito un’azione, chi l’abbia autorizzata e quale accesso debba essere revocato.

Il lavoro del NIST sull’identità e l’autorizzazione degli agenti di IA riflette l’importanza di applicare controlli di identità a questi sistemi.

Come ridurre il rischio: assegnare agli agenti identità distinte e tracciabili, ove supportato, con proprietari identificati e cicli di vita definiti. Utilizzare credenziali di breve durata e con ambito ristretto, nonché una gestione sicura dei segreti. Mantenere il collegamento tra le azioni di un agente e l’utente o il processo che le ha autorizzate.

4. Fuga di dati sensibili

Gli agenti possono raccogliere informazioni da più sistemi aziendali. Senza adeguate restrizioni, potrebbero divulgare dati personali, documenti riservati o informazioni commercialmente sensibili tramite risposte, messaggi, registri o servizi collegati.

Si pensi, ad esempio, a un addetto al servizio clienti che recupera una nota interna relativa a un account e la include in una risposta esterna. La divulgazione potrebbe derivare da controlli di accesso inadeguati o da una decisione errata, senza che vi sia il coinvolgimento di un malintenzionato. La divulgazione di informazioni sensibili è un rischio riconosciuto nelle applicazioni LLM.

Come ridurre il rischio: applicare la classificazione dei dati e i controlli di accesso prima che le informazioni raggiungano l’operatore. Limitare il recupero alle informazioni pertinenti per l’utente, il cliente e l’attività. Utilizzare controlli di prevenzione della perdita di dati, limitare le destinazioni in uscita e verificare come i fornitori e le integrazioni gestiscono la conservazione e la registrazione.

5. Strumenti compromessi e dipendenze della catena di fornitura

Gli agenti dipendono da componenti che vanno oltre il modello sottostante, tra cui librerie software, plugin, connettori e servizi esterni. Una dipendenza vulnerabile o compromessa può compromettere un’implementazione altrimenti ben controllata.

Anche i server Model Context Protocol (MCP), utilizzati per connettere gli agenti a strumenti e dati, rientrano in questa valutazione. Anche un’integrazione comoda richiede comunque un’attenta analisi delle autorizzazioni, del comportamento e della manutenzione.

La sicurezza della catena di fornitura dell’IA deve quindi coprire sia i componenti che circondano il modello sia il modello stesso.

Come ridurre il rischio: mantenere un inventario delle dipendenze e delle integrazioni approvate. Verificarne l’origine, valutare le autorizzazioni richieste, monitorare le vulnerabilità ed esaminare gli aggiornamenti. Testare le modifiche prima della distribuzione, in particolare quando un’integrazione può eseguire comandi o accedere a informazioni sensibili.

6. Conoscenze compromesse e memoria persistente

Le decisioni di un agente dipendono dalle informazioni che riceve e conserva. Gli aggressori possono manomettere le fonti di conoscenza o la memoria memorizzata in modo che contenuti fuorvianti influenzino le attività successive.

Ad esempio, una falsa istruzione salvata come preferenza attendibile potrebbe reindirizzare ripetutamente il comportamento di un agente. A differenza di un singolo prompt dannoso, la contaminazione persistente può influenzare le sessioni successive. L’OWASP include l’avvelenamento della memoria e del contesto tra i rischi di sicurezza legati agli agenti.

Come ridurre il rischio: controllare chi può aggiornare le fonti di conoscenza e la memoria dell’agente. Registrare la provenienza delle informazioni, conservare la cronologia delle versioni e richiedere una convalida prima che contenuti non attendibili diventino linee guida persistenti. Rendere possibile la rimozione dei record contaminati e il ripristino di uno stato noto come corretto.

7. Esecuzione di codice non sicuro e output degli strumenti

Gli agenti che generano codice, query di database o comandi introducono un rischio quando i loro output vengono eseguiti direttamente.

Una richiesta apparentemente ragionevole può produrre un comando non sicuro o una query con un ambito errato. Gli input dannosi possono inoltre sfruttare una convalida debole per raggiungere i sistemi a valle. Le linee guida di OWASP sulla gestione impropria degli output descrivono come un controllo insufficiente possa consentire attacchi di tipo «injection» e l’esecuzione di codice.

Come ridurre il rischio: trattare l’output generato come un input non attendibile. Convalidare gli argomenti degli strumenti, utilizzare query di database parametrizzate e limitare l’esecuzione ad ambienti isolati. Preferire operazioni strettamente definite rispetto all’accesso illimitato alla shell e mantenere i segreti di produzione al di fuori degli ambienti di esecuzione, a meno che non sia esplicitamente richiesto.

8. Guasti a cascata tra agenti

Quando diversi agenti collaborano, un errore o una compromissione in uno di essi può influenzare gli altri. Un agente di ricerca potrebbe fornire una conclusione errata che un altro agente accetta come autorità per aggiornare un sistema.

Ciò crea il rischio che gli errori si diffondano lungo un flusso di lavoro, in particolare quando gli agenti condividono memoria, strumenti o autorizzazioni estese. Un passaggio di consegne riuscito non garantisce che le informazioni sottostanti o l’azione richiesta siano affidabili.

Come ridurre il rischio: autenticare le comunicazioni tra gli agenti e convalidare le richieste ad ogni passaggio di consegne. Conservare le informazioni relative alle fonti e alle autorizzazioni. Concedere a ciascun agente solo l’accesso necessario per il proprio ruolo e introdurre punti di controllo prima che una catena di decisioni raggiunga un’azione ad alto impatto.

9. Esaurimento delle risorse e spesa incontrollata

I flussi di lavoro degli agenti possono richiamare ripetutamente modelli, interrogare servizi o creare attività aggiuntive. Condizioni di arresto inadeguate, input imprevisti o abusi deliberati possono portare a un consumo eccessivo.

Il risultato può includere un aumento dei costi, l’esaurimento delle quote API e una ridotta disponibilità per gli altri utenti. L’OWASP descrive il rischio più ampio di un uso incontrollato delle risorse dei modelli come “consumo illimitato”.

Come ridurre il rischio: impostare limiti applicabili alla spesa, al tempo di esecuzione, ai tentativi di ripetizione, alle attività simultanee e alle chiamate agli strumenti. Generare avvisi in caso di attività insolite e interrompere i flussi di lavoro che superano le soglie concordate. Testare le condizioni di errore, inclusi i servizi non disponibili e le azioni ripetute senza esito, prima di espandere l’implementazione.

10. Azioni non controllate e scarsa visibilità sugli incidenti

Un agente può causare danni senza essere stato compromesso. Potrebbe fraintendere una richiesta, operare sulla base di informazioni incomplete o scegliere un’azione inappropriata. Un’eccessiva fiducia trasforma tali errori in rischio operativo.

L’approvazione umana è utile solo quando il revisore può vedere cosa accadrà. Un messaggio di conferma vago è inadeguato per un pagamento, una modifica dell’accesso o un’eliminazione in blocco. Il monitoraggio è altrettanto importante: i team devono stabilire cosa abbia effettivamente fatto l’agente.

Come ridurre il rischio: mostrare ai revisori l’azione proposta, i sistemi interessati e le prove rilevanti. Registrare le chiamate agli strumenti, le approvazioni e i risultati, proteggendo al contempo i contenuti sensibili dei log. Fornire agli addetti alle emergenze procedure collaudate per sospendere gli agenti, revocare le credenziali, conservare le prove e annullare le modifiche ove possibile.

In che modo le aziende dovrebbero dare priorità alla sicurezza degli agenti di IA?

Iniziare dagli agenti che combinano l’accesso a dati sensibili, strumenti potenti e la capacità di agire senza approvazione. Un assistente che risponde a domande basate su documenti pubblici presenta un livello di esposizione diverso rispetto a un agente che modifica i sistemi di produzione.

Per ogni implementazione, stabilire:

• Responsabilità: chi è responsabile dell’agente e del suo scopo approvato?
• Accesso: quali identità, set di dati e sistemi può utilizzare?
• Autorità: quali azioni può intraprendere in modo autonomo?
• Visibilità: i team di sicurezza sono in grado di rilevare attività insolite e ricostruire gli eventi?
• Ripristino: l’azienda è in grado di arrestare l’agente e contenerne le conseguenze?

Utilizzate queste risposte per stabilire le priorità nei test e nelle misure correttive. Rivalutate la situazione ogni volta che cambiano modelli, strumenti, autorizzazioni o flussi di lavoro, poiché l’ambito di accesso di un agente può espandersi molto tempo dopo la sua approvazione iniziale.

Proteggete gli agenti di IA prima di ampliarne la portata

Ogni nuova connessione amplia le capacità di un agente. Può anche aumentare le conseguenze di un errore o di una compromissione. Le decisioni in materia di sicurezza devono stare al passo con tale espansione degli accessi.

Per le aziende che adottano l’IA agentica, le priorità sono chiare: gestire le identità degli agenti, proteggere i dati sensibili, limitare le azioni e rendere visibili le attività alle persone responsabili della difesa dell’organizzazione.

Rivolgetevi a Integrity360 per garantire l’adozione sicura dell’IA a livello di identità, dati e operazioni aziendali.

Domande frequenti

Qual è la differenza tra sicurezza dell'IA e sicurezza degli agenti di IA?

La sicurezza dell’IA riguarda la protezione dei modelli, dei dati e delle applicazioni di IA. La sicurezza degli agenti di IA pone particolare enfasi sui sistemi che utilizzano strumenti e compiono azioni, inclusi i relativi permessi, l’autorità delegata, le connessioni e la capacità di influenzare altri sistemi.

È possibile prevenire completamente l’iniezione di prompt?

Le aziende non dovrebbero dare per scontato che l’iniezione di prompt possa essere eliminata. Le difese possono ridurre il numero di attacchi riusciti, ma le implementazioni dovrebbero anche limitare ciò che un agente può fare nel caso in cui la manipolazione abbia successo. Limitare l’accesso e controllare le azioni sensibili aiuta a contenere il potenziale danno.

Perché la gestione delle identità è importante per gli agenti di IA?

La gestione delle identità aiuta a stabilire quale agente sta agendo, a cosa può accedere e chi ne è responsabile. Identità distinte, autorizzazioni limitate e credenziali revocabili favoriscono la responsabilità e rendono più facile contenere gli agenti compromessi o malfunzionanti.

Gli agenti di IA necessitano dell’approvazione umana per ogni azione?

L’approvazione dovrebbe riflettere le conseguenze di un’azione. Le attività di routine e a basso impatto possono essere eseguite entro limiti predefiniti. Pagamenti, divulgazioni sensibili, modifiche distruttive e operazioni privilegiate richiedono controlli più rigorosi. Tali controlli dovrebbero essere applicati dall’applicazione o dal sistema collegato.

Cosa dovrebbero fare le aziende prima di implementare un agente di IA?

Definire il suo scopo, assegnare un responsabile, mappare i suoi dati e l’accesso al sistema e impostare i limiti di autorizzazione. Testare l’intero flusso di lavoro rispetto a scenari di uso improprio e di malfunzionamento. Stabilire i requisiti di monitoraggio e approvazione e un modo pratico per arrestare l’agente prima di concedergli l’accesso ai sistemi aziendali operativi.