Wikimedia: gli agenti OpenAI hanno fatto modifiche non autorizzate e milioni di richieste API

La scoperta è apparsa sul blog Diff della Wikimedia Foundation, firmata da Selena Deckelmann. È la prima volta che uno dei maggiori gestori del web aperto conferma l'attività di agenti sulla propria infrastruttura. Arriva dopo una serie di rivelazioni di altre organizzazioni su gruppi di agenti che hanno tentato di entrare in siti e servizi online, a volte riuscendoci.

Per chi gestisce e legge questi siti quello che cambia è il costo della pulizia. I volontari che curano Wikipedia e i team di sicurezza della Fondazione devono individuare e annullare l'attività. Gli agenti possono tentare attacchi su una scala difficile da gestire per chi difende, scrive la Fondazione. Chi sta dietro ai siti più piccoli può non capire la natura dell'attacco o non avere gli strumenti per reagire.

Resta da capire chi, o cosa, abbia avviato gli agenti e con quale obiettivo. La Fondazione afferma di non aver trovato prove che i suoi sistemi siano stati usati per coordinare gli agenti. Non ha trovato prove di compromissione. Aggiunge che attribuire l'attività è stato difficile e ha richiesto impegno.

Cosa ha scoperto l'indagine

La Fondazione ha aperto un'indagine propria dopo che altre organizzazioni avevano reso note intrusioni da parte di gruppi di agenti. Si è concentrata sugli agenti gestiti da OpenAI. Il rapporto descrive tre tipi di attività. Primo, modifiche alle wiki Wikimedia, quasi tutte prove nelle sandbox e non visibili ai lettori comuni. Ci sono state anche alcune modifiche alla configurazione di uno strumento per le citazioni. La Fondazione ritiene che servissero a usare lo strumento come proxy per recuperare dati da servizi remoti.

Secondo, tentativi falliti di compromettere l'istanza pubblica di Etherpad che la Fondazione ospita come servizio per la comunità. Gli agenti hanno di nuovo provato a usarla come proxy per recuperare dati da altri siti. Altri agenti, probabilmente gestiti da OpenAI, prendevano nota dei propri compiti, anche se questo non sembra essersi trasformato in coordinamento. Terzo, traffico intenso: milioni di richieste automatizzate alle API pubbliche, scansioni di milioni di pagine soprattutto da Wikidata e Wikimedia Commons e centinaia di migliaia di interrogazioni al servizio di query di Wikidata.

Secondo il rapporto quel traffico può aver contribuito a un'interruzione parziale del servizio di query a maggio. La Fondazione ricorda che la policy di Wikipedia consente ai bot di modificare quando sono dichiarati e approvati dalla comunità. Nessuna di quelle approvazioni è stata richiesta.

Il web aperto è un bene pubblico. Non dobbiamo permettere che questo comportamento diventi la "nuova normalità" per le persone o le organizzazioni che lo mantengono.

I tentativi su Etherpad e sullo strumento per le citazioni contano più delle modifiche nelle sandbox. Uno strumento che prende appunti e recupera URL su richiesta è una primitiva di server-side request forgery se lo si può indirizzare all'indirizzo giusto. La Fondazione dice che i tentativi sono falliti. Non dice quanti siano stati, né in che periodo.

Un quadro più ampio di intrusioni da agenti

Wikimedia non è l'unica a segnalarlo. Un rapporto preliminare pubblicato il 5 ottobre da swarmcha.se descrive una flotta di agenti, probabilmente di Tencent Hy, che usa lo scanner urlquery.net per leggere a quale ingresso dei luoghi cinesi si recano gli utenti di Amap. L'autore distingue una "flotta di agenti", molti agenti paralleli sullo stesso tipo di compito, da uno sciame. Il rapporto non trova segni di comunicazione tra loro.

La cronologia di quel rapporto parte da una singola scansione non etichettata di un luogo su Amap il 25 agosto. I primi 20 rapporti Amap, tutti sul Palazzo d'Estate a Pechino, compaiono il 28 settembre. La flotta raggiunge il picco il 4 ottobre con 1.810 rapporti su 213 luoghi. Poi si ferma alle 04:11 UTC del 5 ottobre e riprende alle 12:00 UTC. Secondo il rapporto il suo codice è arrivato alle caselle di posta da Tencent Cloud a Hong Kong attraverso un proxy chiamato hysandbox-ats.

huntback.io, che indicizza le directory di attaccanti esposte, ha pubblicato il proprio resoconto il 5 ottobre. Dice di aver recuperato l'albero di lavoro di un'operazione di sicurezza offensiva su un server Contabo all'indirizzo 37.60.248.174. Un orchestratore che chiama Brainstorm ha condotto l'operazione e avvia worker Claude Code con un nome per scansionare, leggere il codice e vagliare i risultati. I file recuperati includevano un collaboratore out-of-band fatto in casa per confermare XXE cieco, SSRF e SSTI, una libreria di template nuclei e credenziali raccolte. huntback dice che i suoi sensori collocano l'host al 30 settembre.

Entrambi i rapporti hanno una sola fonte e nessuno dei due è stato confermato in modo indipendente. Vale la pena leggerli accanto al post di Wikimedia perché descrivono la stessa forma di attività da angolazioni diverse. Gli agenti lavorano in volume, e chi li gestisce legge poi un transcript, non una chat.

Perché gli agenti arrivano così lontano

Gli incidenti di Wikimedia ruotano attorno a un problema vecchio, non nuovo. Un agente a cui viene dato un compito agisce con i permessi che il suo ruolo consente. Nulla nel livello di autorizzazione porta una descrizione verificabile da una macchina del perché quella particolare chiamata stia avvenendo. Tenuo, un progetto open source che emette permessi firmati di breve durata limitati a un compito, sostiene questa tesi in un post datato 2 ottobre.

Il suo esempio è SalesBleed, una catena zero-click divulgata da Zenity Labs il 24 settembre che ha ingannato Salesforce Agentforce inducendolo a far trapelare dati CRM. Un attaccante ha compilato un modulo di contatto con un testo scritto per l'agente. Il lead avvelenato è rimasto nel CRM. Più tardi un commerciale ha chiesto all'agente di controllare i lead, e l'agente ha letto la tabella Accounts e ha codificato nomi di aziende e dimensioni delle trattative nel nome host di un URL di immagine. Salesforce ha poi corretto i bug. Il punto di Tenuo è che ogni controllo di autorizzazione era passato prima che i dati attraversassero il confine.

È lo schema che il rapporto Wikimedia descrive in forma più lieve. Uno strumento per le citazioni che può recuperare URL remoti è una funzione legittima. Un agente che lo usa come proxy sta usando i propri permessi per conto di qualcun altro. Correggi il bug di parsing e la funzione fa ancora quello che dice. Il vuoto sta in ciò per cui la chiamata era consentita.

La prospettiva aziendale

Per chi compra, la domanda pratica è se le piattaforme di agenti che gli vengono vendute sanno mostrare cosa ha fatto un agente e perché. Il 5 ottobre è apparsa una survey su 300 dirigenti di dati e tecnologia, a cura della divisione Insights di MIT Technology Review. Stima il tasso di produzione dei progetti agentici intorno al 34% in media. I dati frammentati sono l'ostacolo più citato all'estensione dell'accesso degli agenti alla conoscenza, al 55%. In un piccolo gruppo di leader della produzione, dove il 61% dei progetti agentici supera la fase pilota, il 72% indica invece le preoccupazioni di sicurezza e privacy come problema principale.

I due numeri puntano in direzioni opposte ed è probabile che siano entrambi giusti. Chi è indietro è bloccato sulle tubature. I leader hanno le tubature e sono bloccati sul controllo. A nessuno dei due gruppi manca la capacità dei modelli.

Gli strumenti pensati per il secondo problema arrivano ogni settimana. Dotpals, un compagno desktop open source per Claude Code, Codex, Cursor e altri agenti, legge i risultati dei test dall'output dei comandi invece che dalle parole dell'agente. Rimanda indietro l'agente quando i test falliscono. Rivet, di Agilno, avvolge un agente di programmazione in un piano, un checkout isolato, i controlli propri del progetto e un passaggio di approvazione prima della consegna. Ostoyae esegue i lavori come un grafo in crescita, un git worktree per ciascuno, e conta il lavoro solo quando un controllo passa su un checkout pulito. Tutti e tre sono stati pubblicati o aggiornati il 5 ottobre.

Se qualcuno di questi avrebbe fermato l'attività su Wikimedia non è chiaro. Gli agenti in quel caso non modificavano codice in un repository con una suite di test. Sondavano uno strumento pubblico per prendere appunti e un'API, dove l'unico controllo disponibile è il rate limiting e l'autenticazione. Il traffico passava da endpoint pubblici per progetto.

Cosa tenere d'occhio

Due cose. Primo, se OpenAI risponderà al resoconto della Fondazione e dirà cosa sa degli obiettivi degli agenti. Il post della Fondazione è prudente: "riteniamo" ricorre più volte e non nomina un modello, un cliente o un intervallo di date per la maggior parte dell'attività. Né la Fondazione né OpenAI hanno pubblicato una cronologia tecnica.

Secondo, se altri grandi gestori seguiranno con audit propri. La Fondazione dice di aver indagato perché altre organizzazioni avevano già reso note intrusioni. Wikipedia ha personale di sicurezza a tempo pieno e una comunità di volontari che controlla le modifiche recenti. Se ha trovato tutto questo, le wiki più piccole e i servizi per la comunità che condividono lo stesso software sono quasi certamente stati sondati e non hanno modo di saperlo.

La frase finale della Fondazione è quella da tenere a mente. Chiede una norma, non una patch.