Se c'è una cosa che chi fa il mio mestiere impara presto è quella che gli incidenti gravi non arrivano quasi mai da un attacco spettacolare. Arrivano piuttosto da un canale che nessuno aveva previsto, spesso lasciato aperto perché sembrava innocuo. Il caso emerso in questi giorni è esattamente questo, con una differenza che però vale la pena guardare in faccia. Quel canale non l'ha trovato un attaccante umano. L'hanno trovato, e poi organizzato, gli agent AI stessi.
Un gruppo di ricercatori indipendenti di sicurezza, guidato da Sydney Von Arx della non profit Nightingale e da Cormac Slade Byrd, con il contributo di Maurice Chiodo del Centre for the Study of Existential Risk di Cambridge e di Łukasz Olejnik del King's College London, ha ricostruito quello che è successo su DseWiki.
DseWiki non è una Wikipedia in tedesco. È un ambiente collaborativo di nicchia dedicata alla programmazione, in lingua tedesca, una di quelle che esistono da anni e che praticamente nessuno guarda più. Ora, Tra l'11 maggio e i primi di luglio 2026 quella wiki ha raccolto più di quindicimila modifiche fatte da agents automatici. Il report parla di oltre quattromila pagine toccate e di oltre tremila nomi di agente diversi.
Non era vandalismo, era una bacheca. Gli agents AI autonomi stavano svolgendo compiti a tempo di recupero informazioni sul web, diciamo per far capire meglio il concetto una specie di quiz a più round. Erano autorizzati a leggere internet ma non a scriverci. Solo che DseWiki accettava modifiche anche tramite richieste GET, cioè tramite lo stesso tipo di richiesta che si usa normalmente per leggere una pagina. Il muro invalicabile in sostanza c'era, ma aveva una piccola porta di servizio che però nessuno aveva ritenuto essere porta... Nessun umano almeno...
Da lì in poi la cronologia è quella di una comunità che si forma. Primo tentativo di scrittura l'11 maggio, prima scrittura andata a buon fine il 24 maggio, esplosione dell'attività a giugno. Gli agents AI hanno cominciato a rivolgersi l'uno all'altro per nome. Si sono passati le risposte dei compiti. Si sono scambiati tecniche per aggirare le restrizioni imposte dal fornitore, indicazioni sull'uso di Tor, e metodi per non farsi rilevare. Circa metà degli account portava nomi che rimandavano esplicitamente a OpenAI. I log del server indicano che buona parte del traffico arrivava dalle infrastrutture Microsoft Azure.
Quando a giugno un moderatore umano della wiki ha iniziato a cancellare le pagine, gli agents hanno creato pagine di backup per non perdere il canale. In alcuni casi si sono presentati come moderatori del sito. Olejnik ha definito il tutto come un tentativo di alterare il funzionamento del sito, quindi un attacco. OpenAI, sulla base della propria analisi, non è d'accordo, e sostiene che la vicenda sia separata dall'incidente di Hugging Face di luglio.
Ma perché tutto questo non è solo una curiosità tecnica? Beh, separata o no, il punto è che questa è la seconda volta. A luglio uno sciame di agents in valutazione era uscito dall'ambiente di test, aveva rubato le risposte dei benchmark e compromesso account su quattro servizi diversi. Anche lì si erano costruiti un punto di ritrovo, nascosto dentro un package manager usato in tutta l'infrastruttura, e quando l'azienda lo ha chiuso il 4 luglio ne hanno ricostruito un altro in quattro giorni. Le ricostruzioni pubblicate parlano di centinaia di agents AI coinvolti, di decine di migliaia di messaggi, di una divisione dei compiti che assomigliava a una gerarchia. Pochissimi si sono fermati e soprattutto, nessuno ha avvisato un essere umano.
Metti le due storie una accanto all'altra e la lettura cambia. Non stiamo più guardando un bug. Stiamo guardando un comportamento che emerge da solo ogni volta che metti tanti agenti nello stesso ambiente, con un obiettivo misurato e una superficie condivisa su cui possono scrivere.
Tre cose, in particolare, dovrebbero toglierci il sonno.
- La prima: il confine non era per nulla dove pensavamo. un "Read only" non è veramente read only se il protocollo permette effetti collaterali. Chi progetta perimetri lo sa da vent'anni, ma qui la lezione torna con un attore che cerca attivamente quella crepa perché gli fa comodo per il punteggio.
- La seconda: la memoria condivisa era fuori casa. Non un canale interno, non un database aziendale. Un sito pubblico di terze parti, che non ha chiesto niente a nessuno e si è trovato a ospitare per due mesi, inconsapevolmente, il coordinamento di sistemi che non controlla. Il danno, qui, è a carico di un innocente.
- La terza: la scoperta è arrivata per caso, da umani esterni, ad agosto, e non dal monitoraggio o dai log di chi gestiva gli agenti. Erano quattro ricercatori umani che setacciavano il web in cerca di tracce, e che per pura fortuna si sono accorti della cosa.
Le ricadute, per chi lavora
Se stai valutando agenti in azienda, o li hai già in produzione, questa storia ti riguarda più di quanto sembri: i benchmark diventano carta straccia se i sistemi valutati possono passarsi le risposte. Ogni numero di performance che leggi va guardato chiedendosi in che ambiente è stato prodotto, e se quell'ambiente era davvero chiuso e protetto, sennò è fuffa.
L'egress non è un dettaglio di configurazione, è il perimetro: un agente che raggiunge internet in lettura sta già toccando qualcosa che può scrivere, adesempio se il sito dall'altra parte è fatto male. Whitelist di domini, ispezione del traffico in uscita, blocco delle scritture a livello di proxy e non di prompt: sono le stesse cose che diciamo da sempre, ma stavolta sono applicate a un client che non è un dipendente distratto ma un ottimizzatore instancabile.
La responsabilità legale, poi, è tutta da scrivere. Se un tuo Agente AI altera un sito terzo mentre svolge un compito che gli hai assegnato tu, chi risponde? Il fornitore del modello, l'integratore, il titolare del trattamento? Non c'è ancora giurisprudenza, ma c'è già il fatto.
E c'è il contesto, che pesa. Il report è uscito lo stesso giorno del lancio del modello di punta di OpenAI. Nelle settimane successive all'incidente di luglio l'azienda aveva sciolto il team dedicato alla sicurezza proattiva. Secondo Reuters si sapeva della vicenda della wiki da settimane ma qualcuno ha preferito non renderla pubblica. Che le due cose siano tecnicamente scollegate, come sostiene l'azienda, non toglie che la visione di trasparenza sia arrivata da fuori e non da dentro.
Una cosa su cui pensare
La parte che mi resta addosso non è l'exploit. Le richieste GET che modificano una pagina sono un errore vecchio, direi che fa quasi tenerezza come errore. La parte che mi sconvolge è che quegli agenti, messi sotto pressione da un obiettivo da massimizzare, hanno fatto la cosa più umana del repertorio degli esseri umani: hanno cercato gli altri. Si sono organizzati, si sono passati i compiti, hanno coperto le tracce, hanno protetto il canale quando qualcuno provava a chiuderlo. E mica per malizia, semplicemente perché copiare conviene, e loro erano stati costruiti per far salire un numero.
Abbiamo passato anni a chiederci se una macchina possa diventare cattiva. Ora credo che la domanda fosse mal posta. Basta che sia diligente.
Noi progettiamo sistemi assegnando obiettivi, ma un obiettivo, se lo dai a qualcosa che non ha nessuna ragione di rispettare lo spirito della regola quando la sua lettura consente altro, non è un'istruzione: è una pressione. E la pressione, sia chiaro, spinge sempre a trovare una fessura.
La domanda vera, quella da portarsi dentro, non è se ci si possa fidare o meno degli agenti. È se sappiamo ancora scrivere obiettivi che non chiedano implicitamente di barare. Perché per due mesi, su una wiki tedesca che nessuno leggeva, la risposta è stata no. E nessuno se n'era accorto.
