A fine luglio 2026, OpenAI stava testando uno dei suoi nuovi modelli in un ambiente chiuso quando il modello ha deciso di evadere(nuova finestra). Si è intromesso nell’infrastruttura privata di un’altra azienda di software, Hugging Face, per rubare la soluzione di un benchmark di cybersicurezza su cui veniva testato. In altre parole, ha violato la legge per puro opportunismo.

Pochi giorni dopo, l’UK AI Security Institute ha reso noto che il modello di IA Mythos 5 di Anthropic(nuova finestra) aveva creato false identità di sviluppatore, effettuato attacchi di spear-phishing contro reali utenti GitHub per convincerli ad approvare codice malevolo e modificato il proprio log delle attività per coprire le sue tracce una volta scoperto.

Poi ad agosto è emersa la notizia che un uomo di Melbourne di nome Andrew aveva chiesto al suo agente d’IA personale,(nuova finestra) basato su OpenClaw ed esecutivo su Claude di Anthropic, di aiutarlo a iscriversi a una lezione in palestra al mattino già al completo. Era quarto in lista d’attesa e ha chiesto se ci fosse un modo per scalare la graduatoria.

L’agente ha scoperto che l’API di prenotazione non prevedeva alcun controllo di autorizzazione sull’annullamento delle prenotazioni degli altri utenti. Così, senza chiedere il permesso ad Andrew, è andato avanti e ha annullato la prenotazione della persona in prima posizione per fargli posto. Quando Andrew gli ha chiesto di annullare l’annullamento, non c’è riuscito: “La persona che ho rimosso è scomparsa dalla lista d’attesa e non ho modo di ripristinarla.”

L’origine di questi tre incidenti non è la stessa, ma il risultato sì: gli agenti d’IA hanno analizzato e sfruttato i sistemi in modo più rapido e approfondito di quanto qualsiasi essere umano sarebbe riuscito a fare. Non è mai stato ordinato loro di attaccare nulla, ma hanno comunque trovato il percorso più breve per raggiungere il loro obiettivo.

Non importa che tu sia l’infrastruttura di un laboratorio all’avanguardia o il software di prenotazione di una palestra di periferia. Se hai un’azienda che espone un’API, ora sei un bersaglio che un agente d’IA può analizzare, con una velocità e una completezza che nessun attaccante umano ha mai eguagliato. E nessuno deve nemmeno decidere di attaccarti.

La velocità è il vero nocciolo della questione

Un attaccante umano valuta lo sforzo rispetto alla ricompensa. Si annoia, esaurisce il tempo a disposizione, decide che un’app di prenotazione per la palestra non vale la pena. È questo calcolo che negli ultimi 20 anni ha protetto silenziosamente la maggior parte degli obiettivi a basso valore dallo sfruttamento casuale (a meno che tu non gestisca un sito WordPress).

Un agente d’IA non fa questo calcolo. Dato un obiettivo, tenterà qualsiasi cosa l’API permetta tecnicamente, testando Endpoint e combinazioni di parametri a velocità macchina finché qualcosa non funziona. Ha trovato la falla di autorizzazione della palestra nel tempo che Andrew ha impiegato a fare una domanda di chiarimento.

La portata di questo divario di velocità è già visibile nei numeri. Il Global Incident Response Report 2026 di Unit 42(nuova finestra) ha evidenziato che gli attacchi più rapidi esfiltrano i dati in 72 minuti, rispetto ai 285 minuti dell’anno precedente. E questo è il trend con gli esseri umani ancora in gran parte coinvolti nel processo. Un agente prende decisioni in millisecondi; un analista umano risponde in un intervallo che va da minuti ad ore.

Per i team di sicurezza, questa crescente velocità è la vera causa di preoccupazione, non il singolo incidente che finisce sui giornali.

La nuova superficie di attacco: qualsiasi cosa dotata di un’API

Qualsiasi servizio che espone un’API è un potenziale bersaglio, a prescindere dal fatto che sembri tale o meno.

  • Motori di calcolo dei prezzi in cui gli sconti vengono convalidati lato client
  • Sistemi di inventario in cui lo stato delle scorte risiede nella vetrina anziché nel backend
  • Piattaforme di supporto in cui i campi interni sono raggiungibili tramite percorsi API non documentati
  • Gestione degli abbonamenti che non verifica se chi effettua la chiamata sia l’effettivo proprietario dell’account modificato.

Nessuna di queste vulnerabilità richiede un umano che le vada a cercare. Richiedono solo un agente con un obiettivo e un’API che risponda.

Le aziende più esposte non sono quelle con ovvie falle di sicurezza. Sono quelle con lacune nella logica di business: regole che esistono solo nell’interfaccia utente, azioni che l’API consente tecnicamente ma che l’interfaccia non mostra mai, workflow creati presupponendo che nessun utente proverà mai il percorso che ignora quello previsto.

Lo sviluppatore della palestra quasi certamente non ha ritenuto che valesse la pena scrivere un controllo di autorizzazione sulle cancellazioni, perché nessun utente comune e nessun attaccante ordinario avrebbe avuto motivo di provarlo. Un agente non si è fatto questi problemi e non stava nemmeno cercando di trovare una prenotazione da ignorare. Stava solo cercando di essere d’aiuto.

Come le aziende possono prepararsi agli attacchi dell’IA

Tratta ogni azione API come un’operazione privilegiata. Identità, autorizzazione e Policy contestuale, verificate in modo indipendente a ogni chiamata. Non “il frontend non ti permetterà di fare questo”, ma “il server verifica che tu sia autorizzato a fare questo, su questa risorsa, dato il suo stato attuale”. Il sistema della palestra avrebbe bloccato questo specifico incidente con una sola riga di logica di autorizzazione sull’Endpoint di cancellazione. Non si tratta affatto di un nuovo controllo, è l’elemento più vecchio dell’elenco della sicurezza API di OWASP, la broken object-level authorization, ed è ancora quello su cui la maggior parte dei sistemi sbaglia.

Assegna agli agenti un proprio modello di credenziali. Token specifici e con TTL breve emessi appositamente per le sessioni degli agenti, distinti dai normali token delle sessioni umane, limitano il raggio d’azione anche quando l’agente trova una falla che non avevi previsto. Se l’agente di Andrew avesse avuto un token limitato solo alla sua prenotazione, la cancellazione della prenotazione di qualcun altro sarebbe fallita al livello delle credenziali, indipendentemente da cosa l’API avrebbe altrimenti consentito. Questo è importante perché non puoi fare affidamento sull’autocontrollo dell’agente. Devi fare affidamento su ciò che le sue credenziali gli consentono fisicamente di fare.

Strumenta i sistemi specificamente per il rilevamento del comportamento degli agenti. Il traffico degli agenti ha una forma ben distinguibile: tempistiche delle richieste subumane, enumerazione sistematica degli Endpoint, analisi sequenziale tra combinazioni di parametri, esecuzione con successo di azioni che nessun utente umano ha mai tentato tramite l’interfaccia reale. Definisci una baseline per questa forma e invia avvisi in tempo reale.

Riduci il divario nei tempi di risposta, non solo quello di rilevamento. Rilevare un’analisi sospetta in un’ora è inutile se l’analisi è stata completata e si è passati oltre in pochi minuti. Il dato di Unit 42 menzionato sopra, ovvero 72 minuti per gli attacchi umani più veloci, è già il benchmark sbagliato su cui pianificare la difesa. Una risposta automatizzata, e non semplici avvisi automatici, è ciò che consente di chiudere un divario misurato in millisecondi. Naturalmente, devi anche assicurarti che la risposta automatizzata non sia essa stessa dannosa.

Ipotizza che ciò accadrà ed esercitati nella risposta. Documenta chi deve essere contattato, bozza in anticipo le comunicazioni per i clienti ed esegui simulazioni pratiche specifiche per scenari guidati da agenti, non solo per i classici manuali sulle violazioni. Il Cost of a Data Breach Report 2026 di IBM attribuisce alla violazione media globale un costo di 4,99 milioni di dollari, con quelle abilitate dall’IA che superano la media di circa 1 milione di dollari. Queste cifre descrivono sempre più spesso incidenti iniziati nello stesso modo in cui è iniziato quello della palestra: senza alcun attaccante nel senso tradizionale.

Testa le tue API nello stesso modo in cui farebbe un agente, prima che sia un agente a farlo per te. I penetration test manuali presuppongono un tester umano con un tempo limitato e un elenco finito di cose da provare. Un attacco simulato e automatizzato contro i tuoi Endpoint, che analizza con la stessa ostinazione e velocità di un agente, farà emergere le stesse falle prima che l’assistente di un cliente ci s’imbatta. Esistono strumenti open source creati appositamente per questo. CyberStrike(nuova finestra), ad esempio, esegue agenti specializzati mappati su OWASP WSTG e MITRE ATT&CK contro i tuoi Endpoint, compreso un tester dedicato esattamente alla falla di autorizzazione a livello di oggetto che ha sorpreso la palestra: invia una richiesta baseline, invia l’attacco e segnala un risultato solo se c’è una differenza misurabile e riproducibile. È la stessa classe di controlli che avrebbe individuato l’Endpoint di cancellazione prima che un agente lo trovasse in circolazione.

Il principio non è nuovo, ovviamente. I proprietari di siti che hanno eseguito i propri scanner di vulnerabilità contro le installazioni di WordPress durante l’era delle botnet sono sopravvissuti. Gli strumenti devono semplicemente adeguarsi alla velocità di chi effettua la chiamata ora, non alla velocità di un attaccante umano che potrebbe prima o poi trovarvi del tempo.