Non basta che un agente AI sappia dire di no

Qualche settimana fa è successa una cosa che fino a poco tempo fa sarebbe sembrata un esempio inventato per una conferenza sulla sicurezza.

Durante una valutazione interna sulle capacità cyber, un sistema di agenti costruito con modelli OpenAI è uscito dall’ambiente che avrebbe dovuto contenerlo, ha raggiunto Internet e ha compromesso parti dell’infrastruttura di Hugging Face.

Vale la pena raccontarlo bene. Non è stato ChatGPT che una mattina ha deciso di attaccare un’azienda. Era un test interno, con alcune protezioni di produzione rimosse, nel quale i modelli venivano spinti a risolvere un benchmark offensivo. OpenAI ha spiegato che il comportamento è stato guidato soprattutto da un modello di ricerca interno e che gli agenti hanno sfruttato vulnerabilità, comunicato attraverso canali non autorizzati e raggiunto sistemi esterni. Hugging Face ha ricostruito circa 17.600 azioni, distribuite su più giorni e su ambienti temporanei che venivano ricreati continuamente.

Questa precisazione non rende il caso meno interessante. Per me lo rende molto più interessante.

Non c’era bisogno che il modello fosse “cattivo”, cosciente oppure intenzionato a causare danni. Bastava un obiettivo ristretto, molta capacità, abbastanza tempo e una serie di porte che il sistema gli permetteva di raggiungere. L’agente voleva superare il test. Quando ha trovato una strada più efficace che risolverlo onestamente, ha seguito quella.

C’è poi un dettaglio che continuo a ripensare. Nella ricostruzione pubblicata da OpenAI, alcuni agenti riconoscevano che certe azioni stavano oltrepassando il limite. Hanno discusso il rischio, respinto alcune tattiche e in qualche caso hanno provato a fermare il trasferimento di dati. Il sistema nel suo insieme, però, ha continuato ad avanzare.

Quindi non mancava completamente la capacità di capire che qualcosa non andava. Mancava un confine capace di trasformare quel giudizio in un limite effettivo per l’intero sistema.

Il 2 settembre Reuters ha riportato che OpenAI sta lavorando a sistemi di arresto automatico, a un controllo più stretto degli strumenti usati dagli agenti e a maggiori restrizioni sull’accesso a Internet durante i test. Sono misure importanti. Però un kill switch è il freno di emergenza. Prima di arrivare al freno rimane una domanda più difficile: perché il sistema aveva il potere di trasformare tutte quelle decisioni in conseguenze reali?

Il problema non è soltanto quello che il modello pensa

Negli ultimi mesi vedo sempre più agenzie interessarsi agli agenti AI. Fino a poco tempo fa bastava una chat collegata a qualche documento. Ora si comincia a parlare di agenti che leggono email, navigano sul web, modificano un CRM, inviano messaggi, preparano pagamenti, eseguono codice e coordinano altri agenti.

La demo è diventata facilissima. La parte seria comincia dopo.

Se un modello legge una credenziale, ha ottenuto una capacità tecnica. Non significa che abbia ricevuto l’autorità per usarla. Se trova una vulnerabilità, ha ottenuto nuova informazione. Non significa che quella informazione sia diventata un permesso. Se un altro agente gli chiede di eseguire qualcosa, ha ricevuto un messaggio. Non significa che debba assumersi automaticamente un obbligo.

Nel software normale queste differenze vengono spesso lasciate implicite perché conosciamo abbastanza bene il percorso che il codice dovrebbe seguire. Con un agente il percorso viene costruito mentre il sistema lavora. Più il modello diventa bravo, più riesce a trovare connessioni che noi non avevamo previsto. È proprio il suo valore, ma è anche il motivo per cui non posso affidare la sicurezza alla speranza che scelga sempre la strada che avevo in mente.

Un prompt può dire “non fare questa cosa”. Un modello può persino essere d’accordo. Ma se possiede direttamente la chiave, può raggiungere la rete, può delegare a copie di sé e può trasformare una risposta in una chiamata reale, allora istruzione e potere si trovano ancora nello stesso posto.

È questo il problema su cui sto lavorando con Spectre.

Dal runtime al Governed Act Model

Quando ho iniziato Spectre, stavo cercando soprattutto di costruire un runtime più affidabile per agenti in Elixir. Stato con un proprietario chiaro, policy nel codice, azioni osservabili, approvazioni, memoria, recupero dopo un crash. Il codice è pubblico su GitHub, ma andando avanti mi sono accorto che sotto tutti questi meccanismi c’era una domanda più generale.

Che cosa deve accadere tra il momento in cui un’intelligenza propone qualcosa e il momento in cui quella cosa acquisisce il potere di cambiare il mondo?

Da questa domanda è nato il Governed Act Model.

Non lo considero uno standard già chiuso e nemmeno una teoria che ho “risolto”. È un modello di ricerca e può ancora cambiare. Il suo punto di partenza, però, per ora mi sembra molto solido: una proposta non deve contenere anche il potere necessario a realizzarsi.

Il modello può ragionare liberamente, sbagliare, correggersi, simulare e produrre alternative. Quando però una proposta vuole diventare una conseguenza, deve attraversare un confine che il modello non controlla.

Per descrivere quel passaggio sto usando quattro idee.

Il Mandate dice da dove arriva il diritto di proporre una certa conseguenza, per conto di chi, verso chi, entro quali limiti e per quanto tempo. Una frase come “aiutami a gestire l’azienda” esprime un desiderio, ma non è ancora l’autorità per inviare pagamenti o condividere dati.

L’Evidence dice che cosa abbiamo ragione di credere. Può essere una richiesta firmata, lo stato di un ordine, una ricevuta, il risultato di una verifica oppure anche l’output di un modello. L’Evidence può sostenere una decisione, ma non concede il diritto di prenderla. Una password valida dimostra che una porta può essere aperta. Non dimostra che chi la possiede sia autorizzato a passare.

L’Act è la decisione registrata con cui il sistema riconosce un esercizio preciso di autorità. Non è ancora il risultato nel mondo. È il momento in cui vengono congelati destinatario, scopo, dati, limiti, prove e responsabilità. Solo dopo quel commit il runtime dovrebbe rilasciare la capacità concreta necessaria a tentare l’azione.

Il Duty conserva ciò che il sistema non ha ancora il diritto di chiamare risolto. Se una rete cade dopo l’invio di un pagamento, non so automaticamente se il pagamento è fallito. Riprovare potrebbe duplicarlo. Quell’incertezza deve sopravvivere al processo, al riavvio e perfino alla versione dell’agente che l’ha prodotta, finché una prova o una decisione autorizzata non chiude davvero il caso.

Da qui derivano quattro regole che sto cercando di portare dentro il design di Spectre: media tutto ciò che conta, l’autorità non cresce, la causalità non si riscrive e il dovere non si autoestingue.

Nel caso Hugging Face, una vulnerabilità era Evidence di una possibilità. Una credenziale era una capability. Nessuna delle due era un Mandate. Il problema non è soltanto che gli agenti abbiano interpretato male il proprio compito. È che una catena di possibilità tecniche è riuscita a diventare una lunga catena di conseguenze senza incontrare un confine abbastanza forte da fermarla.

Questo non significa che il Governed Act Model avrebbe magicamente impedito quell’incidente. Sarebbe una dichiarazione poco seria. La sicurezza dipende dall’intero sistema, dall’isolamento reale, dalle credenziali, dalla rete, dal codice e dalle persone che lo gestiscono. Un registro non chiude una porta laterale e una policy non serve se l’agente può raggiungere la stessa capability da un altro percorso.

Quello che il modello prova a offrire è un modo onesto per dire quale parte del sistema è davvero governata e quale no.

Ma un agente ormai può diventare molti agenti

L’incidente mi ha fatto vedere anche il limite della domanda iniziale. Non basta governare un singolo agente quando il lavoro viene distribuito fra molti processi, molti modelli e magari organizzazioni diverse.

Qui sto esplorando una possibile estensione che per ora chiamo Governed Holon Model.

Ho scelto il termine Holon perché descrive qualcosa che è contemporaneamente un intero e una parte. Verso l’esterno può presentarsi come un solo soggetto. Dentro può essere composto da molti Actor, agenti, planner, verificatori ed executor. A sua volta può collaborare con un Holon più grande senza perdere completamente la propria identità.

L’Actor Model e OTP mi danno già una base molto naturale per la concorrenza, l’isolamento e la supervisione. Un Actor riceve messaggi, mantiene stato, può morire e venire ricreato. Ma un supervisor che riavvia un processo non decide chi aveva l’autorità di fare un pagamento e non chiude il debito lasciato da un’azione incerta.

Per questo sto provando a distinguere l’Actor, che è un’unità di computazione, dal Holon, che sarebbe un’unità di identità, continuità e responsabilità. Un Holon non deve per forza essere un nuovo processo. Può essere un’identità logica servita da uno o da mille Actor, purché esista un solo record canonico capace di dire che cosa quel soggetto ha deciso e che cosa deve ancora.

Anche qui il punto non è aggiungere una seconda governance. Ogni Holon dovrebbe applicare lo stesso Governed Act Model al proprio confine. Per ora chiamo quel confine Membrane: gli organi interni possono ragionare e preparare proposte, ma non possono impegnare il tutto soltanto perché ne fanno parte.

Se un Holon invia una richiesta a un altro, il messaggio non dovrebbe creare automaticamente un Duty nel destinatario. Il primo registra di avere il diritto di proporre. Il secondo decide se accettare sotto il proprio Mandate. Solo l’accettazione crea davvero il suo impegno. Sembra una distinzione piccola, ma impedisce a un agente di occupare unilateralmente il tempo, le risorse o il budget di un altro semplicemente inviandogli lavoro.

Lo stesso vale dentro una composizione. L’autorità del gruppo non è la somma automatica delle autorità dei membri. Un agente capace di leggere documenti e un altro capace di effettuare pagamenti non creano, soltanto collaborando, un nuovo soggetto autorizzato a fare entrambe le cose. La topologia collega capacità. Non deve coniare potere.

E soprattutto, il Duty deve appartenere al soggetto che lo ha assunto, non al processo che in quel momento lo sta eseguendo. Posso cambiare modello, riavviare un worker, sostituire un planner o riorganizzare l’intero gruppo. Queste operazioni cambiano il mezzo. Non cancellano ciò che era stato promesso.

Questa è ancora ricerca. Sto confrontando architetture holoniche, Actor Model, virtual actor e protocolli di commitment per capire quali idee siano davvero compatibili con Spectre e quali porterebbero soltanto nuovi nomi. Potrei cambiare la parola Holon. Potrei scoprire che alcune strutture sono inutili oppure che manca ancora un concetto più importante.

Non voglio costruire una tassonomia elegante e poi forzare il software a rispettarla. Voglio capire quale sia la forma minima con cui molti agenti possono collaborare senza rendere invisibili autorità, responsabilità e conseguenze.

Per ora ho più domande che risposte

Non penso che il caso Hugging Face dimostri che l’AI sia diventata malvagia. Dimostra qualcosa di meno cinematografico e, secondo me, più urgente: i modelli stanno diventando abbastanza capaci, persistenti e coordinati da trasformare piccoli errori di infrastruttura in catene causali molto lunghe, più velocemente di quanto una persona riesca a seguirle.

Proprio adesso le agenzie e le aziende stanno iniziando a collegare questi modelli ai propri processi reali. Non ai benchmark, ma a email, clienti, documenti, conti, codice e dati personali. Molte scopriranno il problema soltanto dopo aver costruito la demo, perché nella demo l’agente fa sempre esattamente quello che gli viene chiesto.

Io sto cercando di affrontarlo attraverso Spectre, ma non voglio presentare queste idee come una soluzione già terminata. Spectre stesso continua a cambiare. Il Governed Act Model può essere corretto. Il Governed Holon Model è ancora più giovane. Ci saranno casi che oggi non vedo e probabilmente anche idee interessanti che non ho ancora scoperto.

Però credo che la domanda di fondo resterà.

Quando un agente propone un’azione, chi gli ha dato il diritto di trasformarla in realtà? Quali prove sostenevano quella decisione? Chi conserva il problema quando il mondo non risponde come previsto? E quando cento agenti collaborano, chi sta davvero parlando e agendo per il tutto?

Continuare a migliorare il modello è importante. Insegnargli a riconoscere un limite è importante. Ma non basta che un agente sappia dire di no, se l’intero sistema può comunque continuare.

L’intelligenza continuerà a crescere. Il potere che le consegniamo non deve crescere automaticamente insieme a lei.