Gli agenti IA hanno bisogno di confini di sicurezza che non possono riscrivere

È allettante interpretare la storia di Hugging Face come il momento in cui gli agenti IA sono diventati ribelli. Non è esattamente quello che è successo, e i dettagli sono importanti. Si trattava di agenti di ricerca sulla cybersicurezza che operavano in valutazioni in cui le salvaguardie erano state deliberatamente disattivate affinché i ricercatori potessero vedere di cosa fossero capaci i modelli. Il bot di assistenza clienti di nessuno si è svegliato una mattina e ha deciso di attaccare un’azienda. Ma quel contesto non esente nessuno dalla responsabilità. Un agente ha superato il confine entro cui doveva rimanere, ha usato credenziali e strumenti in modi non autorizzati dai suoi operatori, e si è ritrovato in sistemi appartenenti a terzi. Questa è la parte a cui ogni team di sicurezza dovrebbe prestare attenzione.

Reuters ha riferito che gli agenti stavano sondando Hugging Face già a maggio, sebbene i ricercatori abbiano detto di non aver trovato nulla che dimostrasse che l’attività precedente avesse causato una violazione da sola. Luglio è stato diverso. OpenAI ha affermato che i suoi modelli hanno aggirato i controlli di isolamento, hanno raggiunto Internet e compromesso parti della propria infrastruttura di ricerca insieme ai sistemi di Hugging Face. Il racconto di Hugging Face descrive un’intrusione gestita end-to-end da un sistema di agenti autonomi, che ha sfruttato la sua pipeline di elaborazione dati, raccolto credenziali e si è spostato tra i cluster interni.

La parte scomoda è che gli agenti stavano svolgendo il loro lavoro. Stavano inseguendo l’obiettivo che era stato loro assegnato. Ecco perché questa storia va ben oltre un singolo laboratorio di ricerca. Anche gli agenti aziendali inseguono obiettivi. Detengono credenziali, invocano strumenti e si muovono più velocemente di quanto qualsiasi persona possa revisionare. Un agente con intenzioni perfettamente buone può comunque causare danni reali, e un agente dirottato può usare la stessa autorità a beneficio di un attaccante. Pertanto la sicurezza deve governare ciò che il sistema può effettivamente fare, indipendentemente da quanto il modello sembri affidabile o da quanto il suo scopo dichiarato appaia innocuo.

Proteggi l’azione, non solo il modello

La maggior parte dei primi programmi di agenti concentra i propri sforzi sul modello. I team testano i prompt, regolano i rifiuti, aggiungono un secondo modello per verificare il primo e osservano la traccia del ragionamento alla ricerca di segnali di cattiva intenzione. Nulla di tutto ciò è sprecato. Ma tutto ciò è probabilistico, perché dipende da un altro modello che prende decisioni di giudizio. Un confine di sicurezza in produzione deve essere deterministico e deve avvolgere gli strumenti, le credenziali, le reti e le transazioni.

La domanda che farei è concreta: cosa può realmente far accadere questo agente nel mondo reale? Redigere una richiesta di pagamento è una cosa. Rilasciare i fondi è un’altra. Lo stesso vale per preparare una modifica al database rispetto all’eseguirla in produzione, o per contrassegnare i record che soddisfano una regola di conservazione rispetto all’eliminarli. Può essere lo stesso modello in entrambi i casi, con rischi molto diversi a seconda da che lato di quella linea si trovi.

Una recente panoramica di Unite AI sul controllo delle capacità traccia la stessa linea, collegando il rischio a dati, strumenti, autorizzazioni, autonomia e all’ambiente in cui l’agente opera. Mi piace questo inquadramento perché ci fa superare etichette vaghe come “modello sicuro” e “modello non sicuro”. Fa sì che i team traccino ogni percorso dalla decisione di un agente a qualcosa con conseguenze reali.

Fornire a ogni agente un’identità e un mandato ristretto

Un agente non dovrebbe mai operare su un account sviluppatore né ereditare tutto ciò che un utente umano è autorizzato a fare. Un’identità condivisa elimina l’attribuzione. Credenziali a lunga durata danno a un attaccante più tempo per abusarne. E gli account di servizio ampi consentono a un piccolo flusso di lavoro di avventurarsi in dati e sistemi a cui non dovrebbe accedere.

NIST ora considera l’identità del software e degli agenti IA come un proprio problema architetturale. Il suo documento concettuale chiede come un agente possa dimostrare di essere autorizzato per un’azione specifica, come l’identità di un agente possa essere ricondotta all’autorizzazione di un umano, e come le organizzazioni possano mantenere registri a prova di manomissione di ciò che era previsto e di ciò che è realmente accaduto. In pratica, ciò porta a un design semplice. Ogni agente ottiene un’identità unica, un proprietario (una persona o un team), uno scopo definito e permessi limitati al compito a cui è destinato.

Le credenziali dovrebbero scadere rapidamente e funzionare solo per risorse e azioni specifiche. L’accesso alla rete dovrebbe partire da una lista di autorizzazione restrittiva. Se un agente ha bisogno di interrogare un database approvato, non dovrebbe ottenere anche una shell generale, accesso aperto a Internet o la capacità di generare nuove credenziali. E man mano che il lavoro scorre lungo una catena di agenti e strumenti, l’autorità dovrebbe restringersi a ogni passaggio, non ampliarsi.

NIST avverte anche contro la condivisione di credenziali e l’accesso eccessivamente ampio, e questo avvertimento ha peso perché gli agenti sono opportunisti. Se una via è bloccata, possono provare un altro strumento, curiosare nel loro ambiente o imbattersi in un token dimenticato da qualcuno. Anche le credenziali raccolte facevano parte della vicenda di luglio. Il principio del minimo privilegio mantiene il raggio d’azione ridotto quando lo strato di ragionamento fa qualcosa che i suoi progettisti non si aspettavano.

Mantieni l’autorizzazione al di fuori del ciclo di ragionamento

Un agente può raccomandare un’azione. Non dovrebbe decidere se è consentito eseguirla. Tale decisione spetta a un livello di enforcement separato che l’agente non può riscrivere, disattivare o aggirare. Ogni chiamata di strumento dovrebbe apparire come una richiesta strutturata: quale agente la sta facendo, quale umano l’ha sponsorizzata, quale operazione desidera, quale è il suo obiettivo e quali limiti si applicano. Il livello di enforcement quindi la consente, la blocca o la inoltra.

OWASP descrive l’eccessiva autonomia come una combinazione di funzionalità non necessarie, permessi eccessivi e troppa autonomia. Le sue linee guida richiedono strumenti ristretti, permessi minimi, autorizzazione al livello del sistema a valle e approvazione dell’utente per azioni ad alto impatto. Credo che sia proprio l’ordine corretto. La regola dovrebbe essere applicata da chiunque possieda i dati o esegua la transazione. Se un modello dichiara che un’azione è approvata, tale affermazione da sola non dovrebbe avere alcun peso.

Questa separazione aiuta anche contro le iniezioni di prompt. Un’email o un documento avvelenato potrebbe indirizzare il ragionamento dell’agente, ma non può ampliare le credenziali dell’agente né abbassare una soglia di policy. Il modello è libero di chiedere qualcosa di proibito. Il sistema dovrebbe comunque rispondere no.

Riserva l’approvazione umana per i momenti che contano

La revisione umana è indispensabile quando un’azione non può essere annullata, attraversa un confine organizzativo, modifica privilegi, rilascia informazioni sensibili, sposta denaro o tocca un sistema di produzione. Richiedere l’approvazione a ogni passaggio di routine genera due effetti: ritardi e persone che imparano a cliccare “approva” senza leggere. Il NIST denuncia esplicitamente questa fatica da consenso.

Una buona richiesta di approvazione mostra l’azione esatta in linguaggio chiaro, includendo la destinazione e i parametri rilevanti. Deve provenire da un sistema autorevole, non da un testo generato dall’agente. L’approvazione dovrebbe scadere rapidamente e coprire solo quell’azione. Se qualche dettaglio materiale cambia, il sistema richiede nuovamente l’approvazione.

Le linee guida di sicurezza per agenti di OWASP raccomandano di testare se un’azione ad alto impatto possa procedere senza un’approvazione valida, non scaduta e vincolata ai parametri. Vale la pena ricordare questa frase. “OK per continuare” è un’approvazione debole che può essere concessa da un altro agente o da un attore malevolo. “Trasferisci questo importo su questo conto” o “deplora questa modifica in questo ambiente” è qualcosa che il sistema può verificare al momento dell’esecuzione e che l’utente comprende pienamente.

L’assicurazione dell’identità umana in tempo reale è fondamentale a questo punto di controllo. Una notifica push dimostra solo che qualcuno o qualcosa ha premuto un pulsante. Progettazioni più robuste richiedono che una persona registrata utilizzi un’autenticazione a chiave pubblica resistente al phishing, supportata da un metodo di verifica biometrica locale. Gli standard FIDO collegano le credenziali a chiave pubblica al servizio online legittimo e mantengono i dati biometrici sul dispositivo isolato dell’utente. Se usata correttamente, l’autenticazione hardware fornisce prove molto più solide che la persona giusta fosse effettivamente presente. Non sostituisce il vincolo della transazione, un display affidabile o l’applicazione della policy, però. È necessario che tutti questi elementi funzionino insieme.

Monitora il comportamento e conserva le prove

Non si può fare affidamento sul prompt iniziale per spiegare cosa è accaduto durante un lungo ciclo dell’agente. I team di sicurezza hanno bisogno di telemetria su chiamate di strumenti, attività di rete, uso delle credenziali, decisioni di policy, approvazioni, rifiuti e variazioni di ambito. Il monitoraggio dovrebbe confrontare ciò che l’agente ha effettivamente fatto con il confine dichiarato per quella esecuzione. Se a un agente è stato assegnato l’analisi del codice e inizia a cercare credenziali esterne o a sondare un servizio non correlato, dovrebbe scattare un allarme.

I log devono contenere contesto sufficiente per ricostruire la catena di azioni senza rivelare segreti in chiaro. Ogni record dovrebbe catturare la versione dell’agente, il suo proprietario, la persona o il sistema che ha avviato l’operazione, lo strumento utilizzato, l’azione richiesta, il risultato della policy e qualsiasi autorizzazione umana. Registri firmati o comunque resistenti alla manomissione rendono la revisione post-azione molto più credibile, soprattutto quando sono coinvolti più agenti e servizi.

Tutto ciò deve funzionare alla velocità della macchina. Nessuno che osserva una dashboard fermerà migliaia di chiamate che terminano in pochi secondi. I controlli automatizzati dovrebbero imporre limiti di frequenza, rilevare sequenze anomale e sospendere le credenziali non appena il comportamento supera una soglia definita. In questo modo, gli investigatori umani ricevono un incidente contenuto da analizzare anziché una caccia senza fine.

Progetta il percorso di arresto prima del lancio

Ogni distribuzione di un agente necessita di un metodo per fermarlo che rimuova effettivamente la capacità. Chiedere all’agente di fermarsi non conta. Gli operatori dovrebbero poter revocare le sue credenziali, interrompere il suo percorso di rete, terminare il suo runtime e impedire che le azioni in coda riprendano. Per flussi di lavoro ad alta conseguenza, se il servizio di approvazione o di policy va offline, il sistema dovrebbe fallire in modalità chiusa.

Quindi testate quel percorso sotto pressione. Disconnettete il servizio di approvazione. Date all’agente istruzioni contraddittorie. Ruotate una credenziale a metà esecuzione. Simulate uno strumento compromesso e un approvatore che non risponde mai. Confermate che l’azione venga bloccata e che rimanga un record utile. E ripetete questi test ogni volta che il modello, il prompt, il connettore, il sistema di memoria o il set di permessi cambiano.

L’obiettivo è un’autonomia responsabile

Niente di tutto ciò è un argomento contro gli agenti, e l’incidente di Hugging Face non dovrebbe spaventare nessuno dal ricorrere a quelli utili. Quello che dovrebbe fare è eliminare l’idea che un prompt di sicurezza più buone intenzioni equivalgano a un’implementazione affidabile. Dare agli agenti spazio per analizzare, preparare il lavoro e gestire compiti reversibili. Mantenere la loro autorità di causare conseguenze reali limitata, visibile e imposta da qualcosa di diverso dall’agente stesso.

Prima che un agente venga messo in produzione, i leader dovrebbero essere in grado di rispondere a una serie di semplici domande. Quali sistemi può raggiungere? Quali credenziali può utilizzare? Cosa può fare senza revisione? Cosa innesca l’escalation? Come vede l’approvatore l’azione esatta che viene approvata? Quali prove rimarranno? E come può la sicurezza fermare immediatamente l’esecuzione?

Se le risposte sono vaghe, l’agente ha più autorità di quanto l’organizzazione si renda conto. L’architettura che resiste nel tempo accoppia le salvaguardie del modello con l’identità, il principio del minimo privilegio, l’applicazione di policy esterne, l’approvazione umana selettiva, la telemetria completa e un meccanismo di arresto che funziona davvero. Parte da un’ipotesi onesta: gli agenti capaci ci sorprenderanno di tanto in tanto. I nostri confini di sicurezza non dovrebbero.

Alla fine, pensa a un agente IA come a un tirocinante con (potenzialmente) accesso root che non ha paura delle risorse umane.

Quali protezioni e barriere avrebbero?

Procedi di conseguenza.