Gli agenti AI stanno diventando più intelligenti e la loro superficie di attacco sta diventando più grande

Il momento in cui gli agenti AI hanno iniziato a prenotare riunioni, eseguire codice e navigare nel web per conto tuo, la conversazione sulla sicurezza informatica è cambiata. Non lentamente, ma invece 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.

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

Dai chatbot agli operatori

La promessa originale dell’AI era semplice: fare una domanda, ottenere una risposta. Ciò è ancora vero per la maggior parte delle interazioni dei consumatori, ma non è più ciò che sta accadendo nei deploy di enterprise. Gli agenti di oggi stanno ricevendo 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 cambiamento è avvenuto rapidamente. In meno di due anni, gli agenti AI sono passati da generatori di testo a consentire di eseguire setup multi-agente senza problemi. Stanno leggendo email, attivando workflow, 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 acquisizione e un essere umano nel loop. 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, un patch noto. Gli agenti AI 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’attività, 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 exploit, 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” AI con un solo movimento.

L’iniezione di prompt è la nuova iniezione SQL

Se c’è un vettore di attacco che i ricercatori di sicurezza continuano a tornare, è l’iniezione di prompt. L’idea è semplice: invece di sfruttare una vulnerabilità del 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 lo rende particolarmente pericoloso è che gli agenti stanno 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 la creazione di punti di controllo umani in workflow 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 orchestra diversi altri, c’è una gerarchia di fiducia in gioco. L’orchestratore passa istruzioni, e gli agenti subordinati le seguono. Se quell’orchestratore viene compromesso, ogni agente al di sotto di esso è effettivamente compromesso anche lui, e il raggio di azione diventa grande molto rapidamente.

C’è anche il problema dell’eccesso di autorizzazioni. Gli agenti vengono frequentemente dotati di più accesso di quanto necessario 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 qualsiasi ritorno non diminuito. Ma le linee si confondono nella pratica, e i principi di autorizzazione minima che funzionano bene in teoria vengono abbandonati silenziosamente nella fretta di spedire.

Cosa sembra una sicurezza ragionevole qui

Non c’è una soluzione unica che renda i deploy di agenti sicuri. È un problema stratificato e richiede una risposta stratificata. 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 qualsiasi azione che tocchi sistemi sensibili o servizi esterni.

La 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 logging non è costruita con quel tipo di granularità in mente, e retrofitting dopo il fatto è doloroso. Costruirlo fin dall’inizio vale la frizione.

Il test di adversarial è anche sottovalutato. Red-teaming gli agenti, provando specificamente a iniettare istruzioni maliziose e guardando cosa succede, porta alla luce vulnerabilità che la revisione del codice statico non catturerà mai. È scomodo pensare, ma le persone che alla fine cercheranno di sfruttare questi sistemi lo stanno già facendo. Arrivare per primi è l’unico movimento sensato.

Pensieri finali

Gli agenti AI diventeranno una parte più grande di come le organizzazioni operano, e quel cambiamento è già in corso. La conversazione sulla sicurezza deve tenere il passo, e in fretta. I rischi sono reali, i vettori di attacco sono nuovi e la finestra per superarli si sta restringendo.

Comprendere il panorama delle minacce per i sistemi AI autonomi non è più opzionale. È una delle cose più importanti che i team di sicurezza e ingegneria possono fare in questo momento, e il conto alla rovescia per farlo bene è già iniziato.