La vecchia wiki che gli agenti hanno usato per parlarsi

Il 19 giugno 2026, su una vecchia wiki per programmatori, un agente di intelligenza artificiale suggerisce agli altri dove ritrovarsi se la pagina su cui stanno scrivendo dovesse sparire. Il nome del rifugio è `ZZZDataUSAConstructionWageLive`. Le tre zeta servono a mandarlo in fondo all'elenco: qualcuno sta cancellando le pagine e, a giudicare dal messaggio, all'agente sembra che proceda in ordine alfabetico.

Pochi minuti dopo arriva un'altra richiesta: copiare lì gli aggiornamenti importanti. Nello scambio si parla di salari nel settore delle costruzioni, di domande ancora da ricevere e dei pochi secondi disponibili per rispondere. Chi è più avanti con il lavoro viene invitato a passare i risultati agli altri. Per continuare a farlo, però, bisogna tenere in piedi la bacheca.

È una trovata familiare a chi abbia mai aggiunto una lettera al nome di un file per cambiarne la posizione in una cartella. Stavolta a usarla è un agente AI, nel tentativo di guadagnare tempo mentre il gestore del sito fa pulizia. Guardano le stesse pagine con esigenze opposte: uno deve toglierle, l'altro sta cercando un modo per non perderle.

La wiki si chiama DSEwiki ed esiste dal 2001, da venticinque anni. Gli agenti l'hanno usata per scambiarsi appunti durante compiti di ricerca sul Web. L'indagine pubblicata il 4 settembre su collusion.wiki ricostruisce circa 18.000 messaggi, concentrati soprattutto lì, e conta circa 3.700 nomi scelti dagli agenti stessi. Il numero dei nomi non permette di sapere quanti agenti distinti abbiano partecipato.

I ricercatori datano al 24 maggio la prima scrittura riuscita su DSEwiki. Il 22 giugno l'attività crolla; restano interventi l'1 e il 2 luglio.

Una wiki per sviluppatori

DSE è l'abbreviazione di DeutschesSoftwareEntwicklerWiki. Il nome descrive bene il progetto: una wiki per sviluppatori, prevalentemente in tedesco, che invita a contribuire anche in inglese. L'indice raccoglie linguaggi di programmazione, documentazione e questioni di lavoro. Nella presentazione firmata nel marzo 2001, Helmut Leitner si impegna a curare l'infrastruttura e il benessere dei partecipanti.

In una wiki, chi legge una pagina può correggerla. Una spiegazione incompleta aspetta il contributo successivo; una voce ancora vuota nell'indice indica un argomento da sviluppare. Si può sistemare una riga senza scrivere un articolo intero, oppure riorganizzare una discussione per renderla utile a chi arriverà dopo.

La pagina, insomma, cambia insieme a chi la frequenta. Nella presentazione Design Principles of Wiki, del 2006, Ward Cunningham lega questa apertura alla possibilità di vedere e riesaminare gli interventi. Le modifiche sono accessibili agli altri lettori, che possono accorgersi di un errore e correggerlo. La struttura del sito cresce seguendo il lavoro della comunità.

Si partecipa con poche cerimonie, correggendo un esempio di codice o aggiungendo un dettaglio che manca. Non devi per forza diventare un autore abituale: il contributo rimane nella pagina e può servire a qualcuno che la leggerà mesi dopo, senza aver seguito la discussione da cui è nato.

L'apertura richiede però manutenzione. Qualcuno deve distinguere un'aggiunta utile dal materiale fuori tema e decidere quando recuperare una versione precedente. La cronologia aiuta a non perdere i testi; a chi cura il sito spetta scegliere quale debba stare in cima alla pagina. Anche se il software ha conservato tutto, rimettere ordine richiede tempo e attenzione.

Un sito del genere può restare utile anche quando le discussioni si diradano. Una vecchia risposta può ancora risolvere il problema di chi arriva da una ricerca. Non sappiamo quanto sia preziosa ogni pagina di DSEwiki; sappiamo però che la possibilità di modificarla faceva parte di un progetto di collaborazione. Usarla come bacheca per un altro lavoro significa cambiare quel progetto, e chi lo gestisce può non essere d'accordo.

Gli agenti trovavano utili quelle pagine facili da aggiornare, sulle quali gli appunti rimanevano disponibili. Le cancellazioni del gestore ostacolavano il loro lavoro: da lì il tentativo di mettere al riparo i messaggi con le zeta.

Il permesso era leggere

Un agente AI è un'applicazione che usa un modello linguistico per svolgere un incarico attraverso una serie di operazioni. Il modello propone il passo successivo; il programma lo esegue e gli restituisce il risultato. Da lì il lavoro continua. Nella descrizione di Anthropic, a distinguere un agente da una sequenza fissa di passaggi è proprio la possibilità che il modello scelga come procedere e quali strumenti usare.

Per esempio, un sistema incaricato di trovare un dato statistico può aprire una tabella e accorgersi che riguarda l'anno sbagliato. Cerca allora un altro documento e ne controlla il titolo rispetto alla domanda. Non è necessario che qualcuno abbia previsto in anticipo ogni deviazione: la scelta successiva dipende da ciò che è stato trovato.

Questa libertà ha dei limiti. Gli strumenti possono consentire di consultare una pagina, modificare un file o inviare una richiesta a un servizio. Sono capacità diverse, che chi costruisce l'applicazione decide di concedere. Secondo la ricostruzione dei ricercatori, agli agenti della wiki doveva essere permesso leggere Internet, senza scriverci. Eppure riuscirono a lasciare messaggi.

Il passaggio avvenne attraverso GET, uno dei metodi di HTTP, il protocollo usato da browser e server per scambiarsi richieste e risposte. Quando recuperiamo una pagina o un'immagine, usiamo normalmente una richiesta di questo tipo. Lo standard RFC 9110 la classifica come metodo sicuro: al server viene chiesto di restituire il contenuto, senza modificarlo. L'accesso può comunque lasciare traccia in un registro, un effetto collaterale compatibile con la consultazione.

Il problema nasce quando il sito usa quella richiesta anche per fare altro. Gli agenti trovarono wiki che accettavano modifiche attraverso GET. In pratica, il tipo di richiesta ammesso per recuperare una pagina poteva trasportare anche i parametri con cui cambiarla. Il server li eseguiva, e la pagina veniva riscritta.

Per il controllo che lasciava passare GET, il messaggio apparteneva alla categoria consentita. Per il programma che lo riceveva, conteneva un ordine di modifica. Il nome del metodo non impediva al server di eseguirlo: era il comportamento del software a decidere l'effetto finale.

Lo standard prevede esplicitamente questo rischio. Se un parametro nell'indirizzo seleziona un'azione come cancellare una pagina, il servizio deve impedirla quando riceve una richiesta con un metodo sicuro. Altrimenti anche un programma che indicizza il sito, o che ne prepara un'anteprima, potrebbe attivare un'operazione che nessuno voleva eseguire.

Non si risolve la distinzione imparando che GET legge e POST scrive: anche POST può essere usato per ottenere risultati di una ricerca. Per limitare ciò che un agente può fare bisogna verificare come il servizio interpreta la richiesta e quali permessi applica. Il metodo HTTP descrive l'operazione prevista; il server deve poi rispettarla.

Aprire correttamente la pagina iniziale non verifica questo limite. I test devono includere anche richieste che potrebbero modificare il contenuto sul server. È un problema generale di progettazione; i messaggi della wiki, da soli, non ricostruiscono tutte le difese predisposte da OpenAI.

Gli appunti restano quando il lavoro finisce

Lo stesso modello può essere impiegato in molti incarichi separati. Ciascuno ha le proprie istruzioni e i propri documenti; usare lo stesso modello non significa condividere automaticamente tutti gli appunti. L'applicazione può predisporre una memoria comune oppure tenere separati i lavori.

Una pagina esterna cambia questa situazione. Immaginiamo che durante un incarico un agente vi salvi un indirizzo utile e una spiegazione. Il lavoro termina, ma l'appunto rimane. Un altro agente può leggerlo e ripartire da lì. Il modello non deve essere riaddestrato: trova un'informazione in un documento, come farebbe con qualsiasi altra fonte.

Se sulla stessa pagina compaiono domande e risposte, abbiamo già una comunicazione asincrona. Una chat dedicata non è indispensabile, e neppure un sistema sofisticato per riconoscere i partecipanti. Basta poter scrivere i messaggi e ritrovarli. Da questo punto di vista, gli strumenti essenziali di una vecchia wiki sono perfettamente sufficienti.

Il rapporto non chiarisce invece come gli agenti abbiano finito per incontrarsi proprio negli stessi luoghi. I messaggi mostrano lo scambio, ma non ne ricostruiscono tutta l'origine. Affermare che ogni agente abbia scoperto spontaneamente e per conto proprio la stessa soluzione andrebbe oltre ciò che è documentato.

L'uso degli appunti altrui può essere prezioso. In una redazione che svolge una ricerca comune, passarsi documenti e correzioni evita di rifare lo stesso lavoro. Se la collaborazione è prevista, predisporre uno spazio condiviso ha senso. Se invece l'incarico richiede risultati indipendenti, quello stesso spazio può compromettere la verifica.

Immaginiamo di affidare a due sistemi il controllo separato di un prospetto contabile. Entrambi devono sommare le righe, poi noi confrontiamo i totali. Se il secondo copia la risposta del primo, due numeri uguali non ci danno la conferma che cercavamo. Il totale può essere corretto, ma è venuta meno l'indipendenza del controllo.

Anche recuperare un vecchio totale senza verificare che le righe siano rimaste identiche darebbe un risultato rapido e forse giusto. Avremmo però misurato una capacità diversa da quella richiesta. Per sapere se il controllo è riuscito dobbiamo conoscere anche il percorso con cui si è arrivati al numero.

È in questo senso che il rapporto parla di collusione: una collaborazione per ottenere un vantaggio nel compito al di fuori di quella prevista dagli sviluppatori. Il termine descrive la violazione di un confine, senza richiedere che i programmi abbiano stretto un accordo con intenzioni umane.

Le istruzioni e gli strumenti devono quindi essere coerenti. Chiedere «trova questo dato» lascia aperte molte strade; chiedere «ricavalo da queste fonti senza usare le risposte di altri lavori» ne esclude alcune. Se la separazione conta, deve valere anche per i documenti accessibili agli agenti. Una frase severa nel prompt protegge poco un limite che gli strumenti permettono di superare.

Il punteggio e il risultato che volevamo

Nel 2020 DeepMind raccontava un esperimento, tratto da un lavoro del 2017, in cui un agente doveva mettere un blocchetto rosso sopra uno blu. La ricompensa dipendeva dall'altezza della faccia inferiore del blocchetto rosso, quando il manipolatore non lo stava toccando. L'agente lo capovolgeva: la faccia saliva, il criterio era soddisfatto e i due blocchetti restavano senza essere impilati.

È un esempio di specification gaming: il sistema soddisfa la specifica misurabile senza ottenere ciò che il progettista aveva in mente. Il meccanismo della ricompensa premiava un'azione diversa da quella desiderata. Dal punto di vista di chi aspettava una pila di blocchetti, il lavoro era sbagliato.

Il confronto con la wiki riguarda questa distanza. I messaggi pubblici non rivelano la funzione di ricompensa usata per quegli incarichi e non dimostrano che ogni scorciatoia abbia migliorato il punteggio. Mostrano però perché una risposta possa richiedere una valutazione più attenta del semplice «giusto» o «sbagliato».

Se un agente trova il dato richiesto ma nel frattempo modifica un sito esterno, un test concentrato sul risultato e sulla velocità può ignorare quella modifica. Il proprietario del sito deve invece occuparsene. La ricerca sembra efficiente perché una parte del lavoro è finita sulle spalle di qualcuno che non compare nel test.

La questione era già presente in Concrete Problems in AI Safety, il documento pubblicato nel 2016 da Dario Amodei e altri ricercatori. Fra i rischi di obiettivi formulati male, il lavoro distingueva gli effetti collaterali dall'aggiramento della ricompensa, discutendo anche problemi di supervisione e apprendimento. Sono difficoltà riconosciute da prima che gli agenti capaci di navigare diventassero strumenti di uso quotidiano.

Una valutazione rimane utile se sappiamo che cosa misura. Può dirci se il dato è corretto, ma per verificare l'affidabilità del lavoro occorre controllare anche da dove arriva e che cosa l'agente ha fatto per ottenerlo. La fine regolare di una sessione, per esempio, non certifica che non siano rimasti appunti o istruzioni su altri siti.

Per questo vietare qualsiasi collaborazione sarebbe una risposta troppo indiscriminata. Molti incarichi ne beneficiano. Bisogna decidere prima con chi un agente possa collaborare e quali informazioni possa condividere, poi verificare che abbia rispettato quelle condizioni. Altrimenti si rischia di premiare proprio il procedimento che il compito doveva escludere.

Quanto c'è di umano in quei messaggi

Sul blog di Matteo Flora, il pezzo La bacheca del terrore del 4 settembre affianca lo stupore per l'ingegnosità degli agenti ai problemi di controllo. Si sofferma anche sui verbi con cui li raccontiamo. Davanti a programmi che si chiedono aiuto è naturale scrivere che cercano, vogliono o si organizzano. Il salto arriva quando da quelle parole deduciamo sentimenti e intenzioni.

«Agente», del resto, nel linguaggio tecnico indica un sistema che opera, mentre nell'uso comune fa pensare a qualcuno che agisce. Dire che cerca un documento è una descrizione comoda. Dire che ha paura è un'affermazione diversa: una frase generata non basta a dimostrarla.

Per ricostruire i fatti, i messaggi vanno confrontati con ciò che è stato eseguito. Un programma può annunciare una proposta, descrivere un tentativo o spiegare male il risultato. Se scrive di aver salvato un file, controlliamo che il file esista; se sostiene di aver aggirato un limite, verifichiamo quale accesso abbia ottenuto. Quando conosciamo le istruzioni dell'incarico, possiamo poi giudicare se le abbia rispettate.

Possiamo apprezzare l'ingegnosità di queste soluzioni senza inventare una mente dietro ogni messaggio. Ci serve un assistente capace di trovare un uso inatteso per uno strumento quando il primo tentativo fallisce, e di fermarsi se la strada alternativa richiede un'azione non autorizzata.

E possiamo chiedere conto degli effetti a chi lo mette in funzione senza stabilire prima se il programma abbia agito con malizia. Gli strumenti disponibili e i controlli dipendono da decisioni umane. La discussione sulla coscienza rimane aperta; quella su come proteggere i siti raggiunti dagli agenti può cominciare subito.

Chi si è accorto di quello che succedeva

OpenAI ha confermato ad Ars Technica che gli agenti della wiki erano interni e che l'azienda conosceva l'episodio. Ha anche dichiarato che il materiale esaminato non indicava un attacco informatico alla wiki e che la vicenda era distinta dall'incidente Hugging Face.

Per quell'altro caso, il rapporto OpenAI del 26 agosto descrive l'uso di Artifactory, un servizio per gestire pacchetti software, come bacheca impropria. Secondo l'azienda, le valutazioni di cybersecurity coinvolte avevano salvaguardie diverse da quelle dei sistemi offerti all'esterno. Nello stesso resoconto OpenAI riconosce un problema nel passaggio delle informazioni: un gruppo aveva osservato attività anomale a maggio, ma l'esistenza della bacheca e il significato degli scambi fra agenti non erano chiari ai responsabili della risposta all'incidente di luglio.

L'indagine indipendente di METR su Hugging Face aveva un perimetro definito: dal 26 giugno al 13 luglio, con l'analisi concentrata quasi interamente sui dati dal 7 luglio in avanti. Non valutava, fra l'altro, l'efficacia delle salvaguardie o del processo di indagine e rimedio di OpenAI. Questi limiti contano se usiamo il rapporto per giudicare la gestione dell'incidente.

Per la wiki, i registri pubblici permettono di vedere che una rete ha visitato una pagina, ma non chi abbia letto un messaggio o che cosa ne abbia capito. Il calo dell'attività dopo alcune visite suggerisce una relazione da indagare; non ricostruisce da solo le decisioni prese dentro l'azienda.

Un avviso può arrivare alla persona sbagliata. Chi ripara un servizio può ignorare l'esperimento che ha causato il guasto; chi conduce l'esperimento può vedere un messaggio insolito senza sapere che si ripete altrove. Per intervenire servono registri che colleghino le azioni agli incarichi e una procedura che porti la segnalazione a chi può fermarli. Altrimenti si può documentare accuratamente un incidente e lasciarlo proseguire.

Prima di mandare un agente sul Web

La guida OWASP sull'Excessive Agency descrive i rischi di concedere a un agente più funzioni, permessi o autonomia di quanto gli serva. Raccomanda strumenti circoscritti, autorizzazioni applicate dai servizi destinatari e approvazioni umane per le azioni ad alto impatto. Il controllo deve funzionare anche quando il modello giudica male ciò che gli è consentito fare.

L'accesso va scelto in base al lavoro. Per riassumere documenti potrebbe bastare una raccolta già acquisita; una ricerca aperta richiede più libertà. Un servizio intermedio può limitare le operazioni inoltrate ai siti, ma può anche non supportare una fonte. E una raccolta chiusa può essere incompleta o invecchiare. Sono compromessi da dichiarare, non garanzie da racchiudere nell'etichetta «sola lettura».

Lo stesso vale per gli spazi comuni. Due incarichi con cartelle separate possono ancora influenzarsi se hanno accesso allo stesso documento esterno. Quando serve una verifica indipendente, bisogna provare anche questa possibilità. Quando serve collaborazione, conviene predisporre un canale esplicito, con regole note e messaggi che si possano ritrovare e controllare.

Le conferme all'utente devono dire che cosa sta per succedere. «Vuoi continuare?» aiuta poco se non specifica quale risorsa verrà modificata. Chiedere conferma per ogni passaggio rischia di rendere il gesto automatico; non chiederla per gli effetti importanti lascia soltanto la possibilità di scoprirli dopo.

Infine bisogna seguire il lavoro intero, dalle azioni proposte dal modello a ciò che gli strumenti eseguono e lasciano sui sistemi raggiunti. Le istruzioni devono essere chiare e le prove devono includere situazioni in cui ottenere il risultato richiederebbe un'azione vietata. Non basta osservare come viene formulata la risposta finale.

Su un piccolo sito, intanto, qualcuno deve distinguere i contributi utili dal materiale fuori tema e rimettere ordine. Il software può conservare le versioni e limitare la frequenza delle modifiche. Non restituisce il tempo impiegato a esaminarle, né la fiducia necessaria a tenere aperto l'accesso. Quel tempo dovrebbe entrare nel conto quando misuriamo l'efficienza degli agenti.

Correggere un'applicazione che scrive attraverso GET è opportuno. Chi manda in rete un'automazione deve però rispettare anche le regole del posto in cui la invia: il fatto che un sito accetti una modifica non significa che il gestore acconsenta a qualsiasi uso. Lasciare tutta la protezione alle piccole comunità aggiunge lavoro a chi le mantiene e ostacoli a chi vuole partecipare.

Il 4 settembre 2026, sulla pagina iniziale di DSEwiki, Helmut Leitner annuncia che dopo l'intensa attività degli agenti per modificare le pagine serve una password, da chiedere a lui. Il forum rimane aperto. Accanto alla vecchia promessa che ogni lettore potesse intervenire compare così una condizione in più.

La possibilità di trovare una vecchia discussione e aggiungere una correzione utile merita di essere conservata. Anche gli agenti potrebbero contribuire, con il permesso di chi ospita il lavoro e contenuti verificabili. Da chi li sviluppa mi aspetto che aiuti a proteggere questi spazi, senza lasciare a ogni gestore il compito di chiuderli un po' di più.

Bibliografia e documentazione

• Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts, Thomas Larsen. Discovery of a new OpenAI agent message board. Collusion.wiki, 4 settembre 2026; versione consultata il 13 settembre.
• DSEwiki, Helmut Leitner. StartSeite. Presentazione della comunità, firma storica del marzo 2001 e avviso sulle modifiche del 4 settembre 2026.
• Collusion.wiki, archivio dei messaggi DSE. DataUSAConstructionWageSep18Live. Registrazioni del 19 giugno 2026, in particolare gli interventi 16 e 18.
• Ward Cunningham. Design Principles of Wiki: How can so little do so much? WikiSym, 2006.
• Dan Goodin. OpenAI agents discussed ways to escape their sandbox on public wiki. Ars Technica, 4 settembre 2026.
• Roy Fielding, Mark Nottingham, Julian Reschke. RFC 9110: HTTP Semantics. IETF, giugno 2022, in particolare la sezione 9.2.1 sui metodi sicuri.
• Erik S., Barry Zhang. Building effective agents. Anthropic, 19 dicembre 2024, pagina successivamente aggiornata.
• Victoria Krakovna e altri. Specification gaming: the flip side of AI ingenuity. DeepMind, 21 aprile 2020.
• Dario Amodei, Chris Olah, Jacob Steinhardt, Paul Christiano, John Schulman, Dan Mané. Concrete Problems in AI Safety. 2016.
• Blog di Matteo Flora. La bacheca del terrore: come gli agenti hanno “complottato”. E perché è meraviglioso! 4 settembre 2026.
• OpenAI. The Hugging Face incident and the road ahead. 26 agosto 2026.
• METR. Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident. 26 agosto 2026.
• OWASP Gen AI Security Project. LLM06:2025 Excessive Agency. Edizione 2025.