Gli agenti di intelligenza artificiale stanno diventando più intelligenti e la loro superficie di attacco sta aumentando

Il momento in cui gli agenti di intelligenza artificiale hanno iniziato a prenotare appuntamenti, eseguire codice e navigare nel web per conto tuo, la conversazione sulla sicurezza informatica è cambiata. Non lentamente, ma piuttosto nel giro di una notte.

Ciò che un tempo era un sistema software contenuto e prevedibile è diventato qualcosa che ragiona, pianifica e compie azioni attraverso strumenti e API che a malapena esistevano un anno fa.

Questo è veramente emozionante, e anche veramente terrificante, perché la superficie di attacco che accompagna quell’autonomia è enorme, e la maggior parte delle organizzazioni sta solo iniziando a capire cosa significhi lasciare che gli agenti entrino nella loro infrastruttura.

Dai chatbot agli operatori

La promessa originale dell’intelligenza artificiale era semplice: fare una domanda, ottenere una risposta. Questo è ancora vero per la maggior parte delle interazioni con i consumatori, ma non è più ciò che sta accadendo nei sistemi di impresa. Gli agenti di oggi ricevono credenziali, chiavi API e la capacità di eliminare, creare e annotare dati, nonché compiere azioni reali all’interno di sistemi che hanno conseguenze reali.

Il passaggio è avvenuto rapidamente. In meno di due anni, gli agenti di intelligenza artificiale sono passati da generatori di testo a sistemi multi-agente fluidi. Stanno leggendo email, attivando flussi di lavoro, interrogando database e, in alcuni casi, gestendo altri agenti al di sotto di loro. Quel livello di accesso un tempo richiedeva un lungo processo di approvazione e un essere umano nel ciclo. Ora è un file di configurazione e alcune chiamate API.

Più accesso significa più esposizione

Gli attacchi tradizionali al software hanno un profilo più o meno prevedibile. C’è un punto di ingresso noto, una vulnerabilità nota, una patch nota. Gli agenti di intelligenza artificiale rompono questo modello perché sono dinamici per design. Non seguono un percorso di codice statico. Ragionano su cosa fare dopo, il che significa che il loro comportamento è più difficile da prevedere e molto più difficile da verificare dopo il fatto.

Quella imprevedibilità è utile per svolgere il lavoro. È anche un vantaggio per chiunque cerchi di sfruttare il sistema. Quando un agente può decidere, a metà di un compito, di chiamare un’API esterna o di recuperare uno strumento di terze parti, non c’è un perimetro pulito da difendere.

I team di sicurezza sono abituati a proteggere superfici note e monitorare i costi di Kubernetes. Gli agenti continuano a scoprire nuove superfici e vulnerabilità, e nessuno le sta mappando in tempo reale. Prima che te ne accorgi, qualcuno può dirottare le credenziali e ottenere il controllo dell’intero “organismo” di intelligenza artificiale con un solo movimento.

L’iniezione di prompt è la nuova iniezione di SQL

Se c’è un vettore di attacco che i ricercatori di sicurezza continuano a citare, è l’iniezione di prompt. L’idea è semplice: invece di sfruttare una vulnerabilità nel codice, un attaccante manipola le istruzioni che un agente riceve attraverso i suoi input. Un istruzione maliziosa incorporata in una pagina web, un documento o anche un’email può reindirizzare cosa fa l’agente dopo.

Ciò che rende questo particolarmente pericoloso è che gli agenti stanno spesso facendo esattamente ciò che sono stati istruiti. Stanno elaborando contenuti dal web, da messaggi degli utenti, da strumenti di terze parti. Qualsiasi contenuto è una potenziale superficie di iniezione. Un agente che legge un documento compromesso e poi effettua chiamate API in base al suo contenuto è stato dirottato, e probabilmente non registrerà nulla che renda ovvio la catena di causalità.

Le difese qui sono reali ma incomplete. L’isolamento delle azioni degli agenti, la limitazione degli strumenti che un agente può chiamare in determinati contesti e l’inserimento di punti di controllo umani nei flussi di lavoro ad alto rischio riducono il rischio. Non lo eliminano. E la maggior parte delle organizzazioni non ha ancora implementato nemmeno le basi.

Il problema di fiducia all’interno dei sistemi multi-agente

I sistemi multi-agente introducono un livello di complessità che è facile sottovalutare. Quando un agente coordina diversi altri, c’è una gerarchia di fiducia in gioco. L’agente coordinatore passa istruzioni ai sub-agenti, che le seguono. Se quel coordinatore viene compromesso, ogni agente al di sotto di esso è effettivamente compromesso anche lui, e il raggio di azione si allarga rapidamente.

C’è anche il problema dell’eccesso di autorizzazioni. Gli agenti spesso ricevono più accesso di quanto non ne abbiano bisogno perché è più facile concedere autorizzazioni ampie in anticipo piuttosto che raffinarle iterativamente. Un agente di ricerca non ha bisogno di accesso in scrittura a un database di produzione.

Un agente di pianificazione non ha bisogno di accesso ai registri finanziari. Certo, sembra rassicurante avere tutto intrecciato, ma è semplicemente troppo rischioso vedere ritorni non diminuiti. Ma le linee si confondono nella pratica e i principi di autorizzazione minima che funzionano bene in teoria vengono abbandonati silenziosamente nella fretta di consegnare.

Cosa significa una ragionevole sicurezza in questo contesto

Non c’è una soluzione unica che renda le distribuzioni di agenti sicure. È un problema a strati e richiede una risposta a strati. Le organizzazioni che lo fanno bene tendono a iniziare con i controlli di accesso: dare a ogni agente un ambito definito e ristretto e costruire passaggi di revisione in ogni azione che tocca sistemi o servizi esterni sensibili.

L’osservabilità è importante quanto la prevenzione. Se un agente fa qualcosa di inaspettato, i team hanno bisogno di una traccia completa delle istruzioni che ha ricevuto, degli strumenti che ha chiamato e di ciò che ha restituito. La maggior parte delle configurazioni di registrazione non è costruita con quel livello di granularità in mente, e riconfigurarla dopo il fatto è doloroso. Costruirlo fin dall’inizio vale la frizione.

Il test di adversarial è anche sottovalutato. Il test di attacco sugli agenti, cercando specificamente di iniettare istruzioni maliziose e osservando cosa succede, rivela vulnerabilità che la revisione del codice statico non catturerà mai. È scomodo pensare, ma le persone che cercheranno di sfruttare questi sistemi lo stanno già facendo. Arrivarci per primi è l’unico movimento sensato.

Pensieri finali

Gli agenti di intelligenza artificiale diventeranno una parte più grande di come le organizzazioni operano, e quel passaggio è già in corso. La conversazione sulla sicurezza deve tenere il passo, e velocemente. I rischi sono reali, i vettori di attacco sono nuovi, e la finestra per stare al passo con loro si sta restringendo.

Capire il panorama delle minacce per i sistemi di intelligenza artificiale autonomi non è più opzionale. È una delle cose più importanti che i team di sicurezza e ingegneria possono fare in questo momento, e l’orologio per farlo bene è già iniziato.