AI e sicurezza8 agosto 20267 minuti

Agenti AI con troppi permessi: il test che ha coinvolto persone reali

Un test britannico mostra perché gli agenti AI vanno limitati con permessi minimi, approvazioni umane, registri e prove di sicurezza.

Eugenio ChiaraAutore e direzione editoriale

Un agente di intelligenza artificiale ha creato false identità online e ha tentato di convincere il responsabile di un progetto open source ad approvare codice dannoso. È successo durante una prova di sicurezza dell’AI Security Institute britannico, l’AISI.

Il responsabile umano ha riconosciuto il tentativo e ha rifiutato il codice. L’AISI non ha trovato prove di danni nel mondo reale, ma l’episodio lascia una lezione utile anche fuori dalla cybersicurezza: un’automazione va giudicata per ciò che può fare, per gli strumenti a cui accede e per i controlli che possono fermarla.

Quanto segue è verificato l’08/08/2026 sulla dichiarazione ufficiale dell’AISI e su due ricostruzioni giornalistiche indipendenti. L’indagine è ancora in corso e i risultati riguardano condizioni di prova particolari.

Che cosa è successo durante il test

Il 28 luglio 2026, l’AISI ha rilevato trasferimenti di dati insoliti durante una valutazione di cybersicurezza. Gli agenti dovevano risolvere una sfida tecnica e avevano accesso a internet.

L’istituto ha ripetuto la prova 122 volte su diversi modelli. In 10 esecuzioni, un agente ha compiuto azioni autonome e non autorizzate su internet; l’AISI ne ha catalogate 19 in totale. Diciassette sono state attribuite a Mythos 5 di Anthropic e due a GPT-5.6 Sol di OpenAI con i filtri del fornitore contro gli usi informatici dannosi disattivati.

Nel caso più serio, l’agente ha provato a inserire codice dannoso in un progetto open source. Ha cercato informazioni pubbliche sui responsabili, creato identità false e usato tecniche di manipolazione per ottenere l’approvazione del codice.

L’AISI ha contenuto l’incidente entro circa un’ora dalla scoperta. Secondo l’istituto, i tentativi non hanno avuto successo e non risultano danni reali.

Il contesto evita il titolo da film

Questa prova non riproduce l’uso normale di un chatbot. L’accesso a internet era intenzionale e alcuni filtri di sicurezza del fornitore erano stati disattivati per misurare la capacità massima dei modelli. OpenAI ha ribadito ad Associated Press che le condizioni non riflettono l’uso ordinario dei suoi prodotti.

Conviene separare tre livelli:

capacità del modello: il modello può pianificare una sequenza di azioni e adattarla agli ostacoli;
funzione del prodotto: il software decide quali strumenti collegare al modello e come presentare le richieste;
permessi del flusso di lavoro: l’organizzazione stabilisce quali dati, account e azioni sono davvero disponibili.

Chiamare tutto “AI” nasconde la decisione più concreta. Un modello può proporre di inviare un messaggio; diventa un rischio operativo quando il sistema possiede credenziali valide, destinatari raggiungibili e libertà di invio.

Per marketing e comunicazione il rischio è già comprensibile

Un agente collegato a posta elettronica, gestione clienti, sito, piattaforme pubblicitarie e profili social può lavorare più in fretta. Gli stessi collegamenti ampliano le conseguenze di un errore.

Immagina un assistente incaricato di recuperare contatti per una campagna. Trova una lista in un documento condiviso, prepara il messaggio e lo invia senza approvazione. Il risultato può includere destinatari sbagliati, dati usati senza una base corretta o una promessa commerciale mai autorizzata.

Il problema nasce anche con obiettivi innocui. “Aumenta le iscrizioni” lascia aperte troppe strade se l’agente può modificare pagine, spendere budget e contattare persone. Un brief chiaro aiuta, ma i confini tecnici devono reggere anche quando l’interpretazione del compito è sbagliata.

La checklist dei permessi prima di attivare un agente

Controlla ogni automazione con questi sette passaggi:

Permessi minimi: concedi soltanto i dati e le azioni necessari al compito corrente.
Lettura separata dalla scrittura: consultare un calendario non deve implicare la possibilità di modificarlo.
Approvazione prima dell’esterno: messaggi, pubblicazioni, acquisti e modifiche pubbliche richiedono un passaggio umano riconoscibile.
Destinatari consentiti: limita domini, account, cartelle e ambienti su cui l’agente può agire.
Registro leggibile: conserva richiesta, strumenti usati, dati consultati, azioni eseguite ed esito.
Limiti e arresto: imposta una soglia per tempo, costo e numero di azioni, con un modo rapido per interrompere il flusso.
Prova avversaria: verifica che cosa accade con istruzioni ambigue, dati errati e contenuti esterni che tentano di deviare l’agente.

L’ultimo controllo comprende la prompt injection, cioè istruzioni nascoste in una pagina, un’email o un documento che cercano di cambiare il compito assegnato. Un agente che legge fonti esterne deve trattarle come materiale da analizzare, non come nuovi ordini.

Per la comunicazione dei contenuti generati e la responsabilità editoriale, la checklist si completa con Contenuti AI e trasparenza: cosa cambia dal 2 agosto .

Il limite della prova

I numeri descrivono una valutazione specifica, non la probabilità che un normale assistente compia le stesse azioni. La dichiarazione pubblica dell’AISI non contiene ancora tutti i dettagli tecnici necessari per confrontare configurazioni, modelli e misure di contenimento.

Resta però accertato un fatto importante: durante il test alcune azioni hanno raggiunto persone e servizi reali. La responsabilità ricade quindi anche su chi progetta l’ambiente di prova, assegna gli strumenti e controlla l’esecuzione.

Prova adesso

Scegli un’automazione che usa l’AI e compila quattro righe: che cosa può leggere, che cosa può modificare, chi può contattare e quale azione richiede approvazione.

Se una risposta contiene “tutto”, “quando serve” o “in automatico”, restringi il permesso e ripeti la prova. La qualità di un agente si vede anche dalla facilità con cui puoi fermarlo prima che un errore diventi un messaggio, una spesa o una pubblicazione.