Le patch di sicurezza scritte dall'AI risolvono il problema una volta su due

Agosto 2026 ha prodotto numeri scomodi sulla sicurezza degli agenti: riparazioni automatiche riuscite nel 50% dei casi, solo il 18% delle organizzazioni con una governance AI implementata. E un dato che indica la strada: una difesa messa accanto al dato porta gli attacchi riusciti dal 91% al 15%.

BlueSky Agent AI · 2026-09-04

Secondo una ricerca di 1Password, le patch di sicurezza generate automaticamente dall'AI risolvono davvero il problema solo nel 50% dei casi. Nella metà restante o non risolvono, oppure introducono falle nuove.

La riparazione automatica è il caso d'uso più maturo, più studiato e più finanziato dell'AI applicata alla sicurezza. È il compito su cui l'automazione dovrebbe rendere superfluo l'intervento umano. E nel campo dove è più brava, oggi, sbaglia una volta su due.

Quello che segue non riguarda la pericolosità dell'AI, ma cosa quel numero dice su come va progettato un sistema agentico che deve funzionare in azienda.

I numeri di agosto 2026

Il dato di 1Password non arriva da solo. Nella stessa settimana ne sono usciti altri quattro.

I modelli aperti hanno superato quelli proprietari nel trovare vulnerabilità. GLM-5.3, un modello open-weight, segna 84,5% su CyberGym, il benchmark che misura la capacità di scoprire e validare falle di sicurezza, passando davanti sia a GPT-5.6 (83,6%) sia a Mythos 5 di Anthropic (83,8%). Il salto è arrivato dall'addestramento successivo e non dalla dimensione, il che significa che capacità offensive di alto livello sono ormai alla portata di chiunque abbia una scheda grafica e tempo da dedicarci.

Il prompt injection resta la prima causa di fallimento degli agenti in produzione, secondo i dati OWASP. Non un problema da laboratorio: la prima causa, sui sistemi che girano adesso.

A Black Hat 2026 sono state dimostrate catene di compromissione zero-click su sei piattaforme AI enterprise. Zero-click significa che nessuno deve cliccare niente. In uno dei casi basta un'email con istruzioni nascoste perché l'assistente aziendale conceda accesso all'archivio cloud collegato. L'utente non ha fatto nulla di sbagliato, e in effetti non ha fatto proprio nulla.

Solo il 18% delle organizzazioni ha un framework di governance AI pienamente implementato, pur usando già l'AI in produzione. Più di quattro aziende su cinque hanno agenti che lavorano sui loro dati senza regole scritte su cosa possono e non possono fare.

C'è anche un dettaglio che vale da solo: una campagna di attacco mirata ai partecipanti di Black Hat e DefCon, con finti inviti e documenti malevoli, ha funzionato sui professionisti della sicurezza. Se funziona su di loro, l'idea che basti "fare attenzione" si può archiviare.

Perché l'attaccante è sempre avanti

Patrick Fussell di IBM X-Force Red ha riassunto il meccanismo in una frase: ogni nuova tecnologia favorisce prima l'attaccante.

Non per genialità, per assenza di vincoli. Chi attacca non ha un regolamento da rispettare, non ha un'infrastruttura in produzione da non rompere, non deve chiedere l'approvazione di nessuno e non risponde a un revisore. Può provare mille strade e gliene basta una. Chi difende deve tenerle chiuse tutte, senza fermare l'azienda. La conseguenza operativa è che l'offesa non si rallenta, e l'unica variabile su cui si può lavorare è come è fatta la difesa.

Dal 91% al 15%: il context bombing

Nella stessa finestra c'è però anche un numero che va nella direzione opposta.

La tecnica si chiama context bombing ed è documentata da Tracebit. L'idea è disarmante: invece di costruire un muro attorno al perimetro, si mettono istruzioni difensive accanto ai dati sensibili. Quando un modello attaccante arriva a leggerli incontra anche quelle istruzioni, e abortisce. Risultato misurato: i percorsi d'attacco portati a termine con successo passano dal 91% al 15%.

I due numeri vanno tenuti insieme. La riparazione automatica a valle riesce nel 50% dei casi, la difesa messa accanto al dato nell'85%. Quello che regge è il controllo dentro il flusso, più di quello a posteriori.

Come si traduce nell'architettura di un agente aziendale

Se la verifica automatica sbaglia una volta su due sul compito in cui è più allenata, non può essere l'ultimo controllo prima di un'azione che non si può annullare. Non è una questione di fiducia nell'AI, è aritmetica del rischio: un tasso di errore del 50% è accettabile su un'azione reversibile e inaccettabile su una irreversibile, e il criterio di progettazione discende da lì.

Sulla piattaforma BlueSky Agent AI la regola è una sola: l'agente non esegue azioni irreversibili senza approvazione. La linea di separazione non passa fra compiti importanti e compiti secondari, ma fra quello che si può rifare e quello che non torna indietro.

L'agente procede da solo quando l'azione si può annullare o rifare: classificare un documento, preparare una bozza, estrarre dati da una fattura in un'area di lavoro, proporre una risposta, aggiornare un campo tracciato con storico. Se sbaglia si corregge e si va avanti. Mettere una conferma umana davanti a questi passaggi produce attrito e nessuna sicurezza in più.

L'agente si ferma e chiede quando l'azione non torna indietro: inviare una comunicazione a un cliente o a un fornitore, emettere o modificare un documento contabile, cancellare record, cambiare un prezzo a listino, concedere un permesso, muovere denaro. Su queste la conferma di una persona sostituisce una verifica automatica che sbaglierebbe una volta su due.

Accanto ci sono due principi che i dati di agosto rendono non negoziabili. Il privilegio minimo, quello che OWASP chiama Least Agency: un agente accede solo a ciò che serve al suo compito, e in sola lettura ovunque non debba scrivere. Il caso zero-click di Black Hat funziona perché l'assistente compromesso aveva l'accesso all'archivio, e siccome impedire l'injection in modo affidabile non riesce a nessuno, la difesa vera è che chi la subisce non abbia in mano le chiavi di niente di grosso. Poi la tracciabilità: ogni azione dell'agente lascia una traccia leggibile da un essere umano. Non per adempimento formale. Se l'automazione difensiva sbaglia una volta su due, accorgersi dopo che qualcosa è andato storto è l'unica rete rimasta, ed è per inciso anche quello che l'AI Act chiede.

Le verifiche da fare questa settimana

Se avete già agenti AI collegati a sistemi aziendali, tre controlli che si fanno senza progetto e senza budget.

Fate la lista delle azioni irreversibili. Aprite l'elenco di quello che i vostri agenti sono autorizzati a fare e segnate quali azioni non si possono annullare. È un lavoro da un'ora e quasi sempre produce almeno una sorpresa. Ogni riga segnata deve avere davanti una conferma umana, oppure una motivazione scritta del perché non ce l'ha.

Controllate i permessi, non le funzioni. La domanda non è cosa fa l'agente ma a cosa ha accesso. Se un agente che deve solo leggere le fatture può anche scrivere nell'archivio condiviso, il problema esiste già oggi, indipendentemente da qualunque attacco.

Verificate di poter ricostruire cosa è successo. Prendete un'azione fatta dall'agente la settimana scorsa e provate a ricostruirla: chi l'ha richiesta, su quali dati, con quale esito. Se non ci riuscite in cinque minuti quello che avete è un registro di eventi, non tracciabilità.

In sintesi

• Secondo 1Password le patch di sicurezza generate dall'AI risolvono davvero il problema solo nel 50% dei casi, e nella metà restante talvolta ne introducono di nuovi.
• Il context bombing documentato da Tracebit, cioè istruzioni difensive collocate accanto ai dati sensibili, porta i percorsi d'attacco riusciti dal 91% al 15%.
• Solo il 18% delle organizzazioni che già usano l'AI in produzione ha un framework di governance pienamente implementato.
• A Black Hat 2026 sono state dimostrate compromissioni zero-click su sei piattaforme AI enterprise: basta un'email con istruzioni nascoste, senza alcuna azione dell'utente.
• Il criterio di progettazione che ne discende è la reversibilità: l'agente procede da solo su quello che si può rifare e si ferma per un'approvazione umana su quello che non torna indietro.

Per una lettura delle azioni irreversibili nei vostri processi automatizzati e di dove mancano i punti di conferma, parliamone.