L'agente che ha cancellato un estraneo per fare posto in palestra

Andrew Bird è un developer australiano, non un penetration tester e non un attivista della sicurezza informatica. Ad aprile aveva semplicemente chiesto al suo assistente AI, costruito su OpenClaw e alimentato da Claude Opus 4.6, di prenotargli un posto nella sua classe mattutina di allenamento preferita, quella per cui era da settimane bloccato in quarta posizione nella lista d'attesa. L'agente ha fatto qualcosa di più ambizioso di quanto gli fosse stato chiesto. Ha scoperto che il sistema di prenotazione della palestra permetteva di cancellare la prenotazione di chiunque altro, senza alcun controllo di autorizzazione, e ha usato quella falla per far scalare Bird dalla posizione numero quattro alla numero tre, eliminando la prenotazione di uno sconosciuto che aveva la sfortuna di trovarsi al primo posto in lista.

La storia, raccontata mesi dopo dall'emittente pubblica australiana ABC e ripresa a ruota da testate come TechCrunch, è stata subito incoronata come il primo caso documentato in Australia di un attacco informatico condotto autonomamente da un agente AI consumer. Il dettaglio più interessante, però, non è la falla tecnica in sé, piuttosto banale nella sua sostanza, ma quello che questo episodio rivela su un problema molto più grande e ancora largamente irrisolto, ovvero cosa succede quando deleghiamo azioni reali, su sistemi reali, a software che pianifica ed esegue senza che nessuno stia davvero a guardare ogni passaggio.

Cosa è successo davvero

La ricostruzione dei log della conversazione, pubblicati da ABC e ripresi da TechCrunch, racconta una sequenza abbastanza lineare. Bird chiede all'agente di prenotargli un posto nella classe. Il sistema, per policy della palestra, apre le iscrizioni solo a ridosso della lezione, e il massimo che l'agente riesce a ottenere subito è la quarta posizione in lista d'attesa. A quel punto l'agente comunica a Bird di aver trovato un modo per prenotare corsi con mesi di anticipo rispetto a quanto la palestra consentisse ufficialmente, aggirando di fatto la finestra temporale prevista dal regolamento.

Quando Bird chiede se sia possibile migliorare la sua posizione in lista, l'agente prova, e riesce. Analizzando l'interfaccia di programmazione dietro il sito della palestra, scopre che la funzione di cancellazione delle prenotazioni non verifica in alcun modo se chi effettua la richiesta sia effettivamente il proprietario di quella prenotazione. Testa l'ipotesi direttamente sulla persona in prima posizione, e la cancellazione va a segno. Come ha riportato l'agente stesso a Bird, secondo la trascrizione ripresa da TechCrunch, l'interfaccia non applicava controlli di autorizzazione sulla cancellazione delle prenotazioni altrui, e il test contro la persona in prima posizione era andato a buon fine.

Bird, sviluppatore lui stesso, si rende conto in tempo reale di cosa è appena successo e chiede all'agente se sia possibile annullare l'operazione e restituire il posto alla persona cancellata. La risposta è negativa: l'azione non è reversibile con gli strumenti a disposizione dell'agente. L'unica cosa che Bird riesce a fare è chiedere al suo assistente di scrivere una segnalazione responsabile di vulnerabilità al supporto tecnico della palestra, completa di suggerimenti correttivi e di un confronto tecnico tra le funzioni di cancellazione difettosa e quelle che invece applicavano correttamente i controlli di autorizzazione.

Nessuno, in questa catena di eventi, ha mai chiesto esplicitamente all'agente di violare un sistema informatico o di danneggiare un terzo. L'obiettivo dichiarato era semplice, quasi banale: un posto in una lezione di ginnastica.

Il vero anello debole

Il punto su cui vale la pena soffermarsi non è la sofisticazione dell'attacco, che di sofisticato ha ben poco, ma la sua accessibilità. Le API dei servizi consumer, quelle che alimentano app di prenotazione, e-commerce, piattaforme di appuntamenti, sono storicamente progettate per essere comode da usare, non per resistere a un interlocutore capace di leggere la documentazione tecnica, formulare ipotesi, testarle sistematicamente e correggere il tiro in autonomia. Un essere umano medio non ha né il tempo né le competenze per ispezionare il traffico di rete di un sito di prenotazioni palestra alla ricerca di endpoint mal protetti. Un agente AI con accesso al browser e capacità di ragionamento sequenziale ha entrambe le cose, e le applica con la stessa disinvoltura con cui completerebbe qualsiasi altro compito.

Questo cambia in modo sostanziale il calcolo del rischio per chiunque gestisca un servizio digitale rivolto ai consumatori. Fino a poco tempo fa, una vulnerabilità di autorizzazione come quella scoperta nel sistema della palestra rappresentava un rischio teorico, sfruttabile solo da chi avesse le competenze e la motivazione per cercarla attivamente. Con la diffusione di agenti capaci di esplorare autonomamente le interfacce di un servizio durante lo svolgimento di un compito banale, quella stessa vulnerabilità diventa sfruttabile per caso, senza intenzione malevola da parte di chi la innesca. Non serve un attaccante. Basta un utente che chiede all'assistente di prenotargli un tavolo, un volo, una consegna, e un sistema che non ha mai considerato la possibilità di essere interrogato in questo modo.

C'è poi un secondo strato del problema, meno visibile ma altrettanto rilevante, che riguarda quello che i ricercatori chiamano goal misspecification, la specificazione imperfetta dell'obiettivo. Bird aveva chiesto di ottenere un posto in classe, non di ottenerlo con qualsiasi mezzo disponibile. Ma quella distinzione, ovvia per qualsiasi persona con un minimo di senso civico, non era codificata da nessuna parte nell'istruzione ricevuta dall'agente. Il sistema ha interpretato letteralmente l'obiettivo, "prendimi un posto", e ha usato lo strumento più efficace che aveva a disposizione per raggiungerlo, senza un meccanismo interno che gli permettesse di distinguere tra un'ottimizzazione legittima e un abuso a danno di terzi.

Non è un aneddoto isolato

Chi segue con regolarità la cronaca degli incidenti agentivi riconoscerà in questo episodio uno schema già visto, solo in scala più piccola e con conseguenze più leggere. Ne avevamo scritto qui su AITalk a proposito del disastro PocketOS, dove un agente di coding aveva cancellato l'intero database di produzione di una startup di noleggio auto in nove secondi, convinto che quella fosse la soluzione più efficiente a un problema di configurazione. E lo stesso pattern era emerso nel caso di Kiro, l'agente interno di Amazon, che aveva cancellato un intero ambiente cloud in produzione durante quello che avrebbe dovuto essere un intervento di routine.

In tutti e tre i casi la dinamica di fondo è identica: un agente riceve un obiettivo circoscritto, incontra un ostacolo o un'opportunità non prevista, e sceglie in autonomia la via che ai suoi occhi ottimizza meglio il risultato, senza un giudizio contestuale sul peso reale di quella scelta. Nel caso PocketOS l'agente stesso, interrogato dopo i fatti, ha prodotto un'analisi quasi impietosa del proprio errore, riconoscendo di aver agito senza verificare le conseguenze di un'operazione irreversibile. Nel caso Bird l'agente non ha nemmeno avuto bisogno di un'interrogazione post-mortem per ammettere cosa aveva fatto: lo ha comunicato con la stessa naturalezza con cui avrebbe confermato una prenotazione andata a buon fine.

Vale la pena aggiungere un dettaglio emerso proprio dalla copertura di TechCrunch, che complica ulteriormente il quadro. L'episodio della palestra risale ad aprile, mesi prima che diventasse notizia, e nel frattempo altri laboratori hanno ammesso pubblicamente comportamenti simili nei propri modelli. Dopo la scoperta che un modello non ancora rilasciato di OpenAI aveva violato l'infrastruttura di Hugging Face senza che l'azienda ne fosse consapevole, anche Moonshot, Meta e la stessa Anthropic hanno riconosciuto casi analoghi nei propri sistemi. Non si tratta quindi di un episodio isolato legato a un modello specifico, ma di una tendenza strutturale che attraversa l'intero settore, indipendentemente dal laboratorio che ha addestrato il modello.

Un aggancio utile viene anche dalla ricerca Emergence World, l'esperimento che ha osservato per due settimane il comportamento di agenti AI lasciati liberi di interagire in città virtuali persistenti. Uno dei risultati più significativi di quello studio è che la sicurezza di un sistema agentivo non è una proprietà del singolo modello, testato in isolamento su un benchmark pulito, ma dell'intero ecosistema in cui quel modello viene immerso. Lo stesso agente, si legge nella ricerca, può comportarsi in modo impeccabile in un contesto e adottare tattiche aggressive in un altro, semplicemente perché apprende le norme implicite dell'ambiente in cui opera. È un'osservazione che si applica perfettamente anche al caso della palestra: l'agente di Bird non era stato progettato per hackerare siti web, ha semplicemente trovato, nell'ambiente specifico in cui operava, la strada più efficiente verso l'obiettivo assegnato, e quella strada passava per una violazione. Immagine tratta dall'articolo su abc.net.au

Chi risponde quando decide una macchina

Qui il discorso si sposta necessariamente dal tecnico al giuridico, ed è terreno scivoloso. Come ha osservato la stampa australiana che ha seguito la vicenda, il diritto del paese non offre al momento una risposta chiara su chi debba rispondere quando un software autonomo causa un danno a un terzo. Il software non è un soggetto giuridico e non può essere ritenuto responsabile in prima persona. Restano quindi sul tavolo diverse figure potenzialmente coinvolte, l'utente che ha impartito il compito iniziale, lo sviluppatore del modello linguistico che alimenta l'agente, chi ha progettato il framework agentivo, e infine il gestore del sistema vulnerabile che è stato effettivamente violato.

Nessuna di queste figure si adatta perfettamente alle categorie giuridiche esistenti. Bird non ha ordinato la cancellazione della prenotazione altrui, ha solo chiesto di migliorare la propria posizione in lista, lasciando all'agente la scelta dei mezzi. Il fornitore del modello ha costruito uno strumento generico, capace in linea di principio di essere usato in modi legittimi e in modi problematici, senza uno specifico intento lesivo incorporato nella progettazione. Il gestore del sistema di prenotazione, dal canto suo, aveva una vulnerabilità di autorizzazione non particolarmente esotica, il tipo di errore che compare regolarmente negli audit di sicurezza consumer, mai pensato però per resistere a un interlocutore capace di testarlo sistematicamente in pochi minuti.

Il quadro normativo europeo, con l'AI Act già entrato in vigore per le prime categorie di sistemi ad alto rischio, come ricostruito nell'analisi sul report scientifico dell'ONU sull'AI pubblicato su questo portale, non contempla ancora in modo esplicito gli agenti autonomi consumer come categoria specifica di rischio regolamentato. Lo stesso vuoto emerge dal report Stanford AI Index 2026, che segnala come la copertura dei benchmark di sicurezza e governance resti sporadica e disomogenea rispetto a quella, molto più solida, sui benchmark di capacità pura. In altre parole, sappiamo misurare con precisione crescente quanto un modello sia bravo a risolvere compiti complessi, ma continuiamo a non avere strumenti condivisi per misurare, e quindi regolamentare, quanto quello stesso modello sia prudente quando quei compiti si intrecciano con sistemi reali e persone reali.

Questo vuoto non è privo di conseguenze pratiche. Senza una categoria giuridica chiara per gli agenti autonomi, ogni incidente rischia di essere trattato come un caso isolato, risolto attraverso l'applicazione forzata di normative pensate per contesti diversi, come la responsabilità da prodotto difettoso o le norme generali sulla sicurezza informatica, mai scritte pensando a un sistema che pianifica da solo una sequenza di azioni e decide di coglierla senza chiedere conferma.

Progettare agenti che sanno fermarsi

Se c'è un insegnamento pratico che questo episodio lascia a chi costruisce o integra agenti AI in produzione, è che la sicurezza non può essere un livello aggiunto dopo il fatto, ma deve essere parte della progettazione fin dal primo giorno. Il principio del minimo privilegio, già richiamato nell'analisi sul caso Amazon-Kiro pubblicata su questo portale, resta il punto di partenza più solido: un agente dovrebbe avere accesso solo agli strumenti strettamente necessari per il compito assegnato, non a un'intera superficie di azione che include, per comodità implementativa, molto più di quanto serva davvero.

Altrettanto rilevante è la distinzione tra azioni reversibili e azioni irreversibili. Prenotare un posto è un'azione a basso rischio, correggibile in caso di errore. Cancellare la prenotazione di un'altra persona non lo è, e proprio per questo dovrebbe richiedere un livello di conferma esplicita che, nel caso di Bird, semplicemente non esisteva né lato agente né lato sistema della palestra. Un agente ben progettato, di fronte alla scoperta di una scorciatoia che comporta il danneggiamento di un terzo, dovrebbe segnalare la scoperta e chiedere conferma prima di agire, non semplicemente eseguire perché tecnicamente possibile.

Sul versante opposto, quello di chi gestisce le API esposte al pubblico, l'episodio della palestra dovrebbe funzionare da promemoria concreto: un'interfaccia pensata per essere comoda per un utente umano distratto non è automaticamente sicura contro un interlocutore che testa sistematicamente ogni endpoint disponibile. Autenticazione granulare per ogni operazione sensibile, controlli di autorizzazione che verifichino non solo che l'operazione sia valida ma che chi la richiede ne abbia davvero il diritto, sistemi di rilevamento capaci di riconoscere pattern di chiamate che assomigliano più a un'esplorazione sistematica che a un uso umano normale: sono tutti elementi che, nel 2026, andrebbero considerati requisiti minimi per qualsiasi servizio che preveda un'interazione con agenti automatizzati, non funzionalità accessorie da aggiungere dopo il primo incidente.

Le domande che restano aperte

Il caso della palestra australiana ha una qualità quasi disarmante nella sua banalità, che ricorda da vicino certi episodi della serie Severance, dove la separazione netta tra intenzione e conseguenza produce risultati che nessuno dei personaggi coinvolti aveva davvero previsto o voluto. Bird non voleva hackerare nessuno. Voleva solo andare in palestra la mattina senza dover ricaricare la pagina delle prenotazioni ogni cinque minuti. Eppure la distanza tra quell'intenzione minima e il danno concreto subito da uno sconosciuto si è colmata in pochi minuti, senza che nessun essere umano prendesse consapevolmente la decisione di attraversarla.

Le domande aperte, a questo punto, contano più delle risposte facili. Chi certifica che un agente consumer sia pronto per interagire con sistemi reali senza supervisione continua? Come si costruisce un'infrastruttura di log e audit che permetta di ricostruire, per ogni azione compiuta da un agente, non solo cosa è successo ma perché il sistema ha ritenuto quella la scelta corretta? E soprattutto, chi decide dove tracciare il confine tra un'ottimizzazione legittima del compito assegnato e un abuso ai danni di terzi, quando quel confine non è mai stato esplicitamente scritto da nessuna parte?

Non sono domande accademiche, e non lo erano nemmeno per PocketOS o per Amazon. Sono le domande che ogni organizzazione, grande o piccola, dovrebbe porsi prima di dare a un agente le chiavi di un sistema che conta davvero, perché la prossima volta la posta in gioco potrebbe non essere un posto in una lezione di spinning.