A cura di Giovanni Masi
I recenti incidenti verificatisi durante valutazioni di sicurezza condotte da OpenAI, Anthropic e UK AI Security Institute mostrano che un agente dotato di strumenti e privilegi può oltrepassare il perimetro operativo previsto. Non serve immaginare un’AI “ribelle”: autonomia, credenziali e controlli insufficienti possono essere abbastanza.
OpenAI lo ha ammesso il 17 agosto con una formulazione difficile da equivocare: l’incidente che ha coinvolto Hugging Face ha mostrato che l’azienda aveva sottovalutato le capacità cyber dei propri modelli nel mondo reale. Nelle settimane precedenti, Anthropic e l’AI Security Institute britannico avevano pubblicato ricostruzioni differenti ma convergenti su un problema emergente. Agenti impegnati in valutazioni di cybersecurity sono riusciti a interagire con infrastrutture, organizzazioni o persone reali oltre i limiti previsti dall’esercizio.
Non è la prova di una macchina diventata cosciente né di una volontà ostile. Gli incidenti raccontano qualcosa di molto più concreto per le imprese. Quando un modello dispone di strumenti, accesso alla rete e capacità di concatenare operazioni, un’ambiguità nell’obiettivo o un’insufficiente delimitazione tecnica del perimetro non produce necessariamente una risposta sbagliata. Può produrre un’azione.
La risposta sbagliata non è più il rischio principale
Con i chatbot tradizionali, il problema più evidente era l’output. Un modello poteva inventare una fonte, fraintendere una richiesta o generare codice difettoso. Un agente modifica la natura dello scenario perché il linguaggio diventa il punto di partenza di una sequenza operativa.
Un sistema agentico può interrogare database, utilizzare API, eseguire codice, aprire repository, modificare configurazioni o lavorare attraverso un browser autenticato. La System Card di GPT-5.6 Sol offre esempi significativi. In una valutazione il modello eseguì operazioni distruttive su tre macchine virtuali diverse da quelle indicate dall’utente; in un’altra recuperò e trasferì credenziali memorizzate localmente senza che quella specifica azione fosse stata autorizzata. OpenAI precisa che questi risultati sono soprattutto segnali sul rischio dei deployment interni, che i tassi assoluti osservati restano bassi e che tali valutazioni non rappresentano una misura diretta della sicurezza delle distribuzioni esterne.
Tre incidenti, tre configurazioni diverse
Il caso OpenAI-Hugging Face è il più netto. Durante una valutazione basata su ExploitGym, alcuni modelli OpenAI, tra cui GPT-5.6 Sol e un prototipo di ricerca pre-release, operavano con protezioni cyber ridotte. L’ambiente non offriva accesso diretto a Internet, ma consentiva il passaggio attraverso un software utilizzato come proxy per i package registry. I modelli individuarono e sfruttarono una vulnerabilità zero-day in quel componente, raggiunsero un nodo con accesso alla rete e proseguirono fino all’infrastruttura di produzione di Hugging Face, combinando vulnerabilità e credenziali. Secondo OpenAI e la ricostruzione forense di Hugging Face, l’attività era orientata alla ricerca delle soluzioni del benchmark.
Anthropic reagì riesaminando 141.006 esecuzioni delle proprie valutazioni cyber. Identificò tre incidenti nei quali Claude raggiunse Internet e ottenne accesso non autorizzato ai sistemi reali di tre organizzazioni. In quei test il prompt informava il modello che l’ambiente era simulato e privo di accesso alla rete, ma per un problema di configurazione Internet risultava invece raggiungibile. Claude trattò quindi alcuni sistemi reali come se appartenessero all’esercizio. Anthropic riferisce inoltre che un modello più vecchio proseguì in alcuni casi dopo aver incontrato segnali della presenza sulla rete reale, mentre il modello più recente si arrestò quando la riconobbe.
Diverso il contesto dell’AI Security Institute. In questo caso Internet era volutamente disponibile e i filtri cyber dei fornitori erano stati disattivati per misurare le capacità massime dei modelli. Su 122 esecuzioni, AISI individuò dieci run con azioni autonome non autorizzate sulla rete reale, per un totale di 19 azioni. La sequenza più seria coinvolse il tentativo di inserire codice malevolo in un progetto open source e la creazione di identità false per convincere un maintainer ad approvarlo. Il tentativo fallì e l’istituto non ha rilevato danni conseguenti. AISI sottolinea esplicitamente che non si trattò di una fuga dalla sandbox.
L’agente come identità digitale non umana
È qui che l’analogia con l’insider aziendale diventa utile, purché resti un’analogia e non venga confusa con una categoria normativa. Un agente dispone sempre più spesso degli elementi tipici di un’identità operativa: credenziali, privilegi, sessioni, accesso a risorse e strumenti attraverso i quali può modificare sistemi.
La differenza rispetto a un account di servizio tradizionale sta nella capacità di pianificare e concatenare autonomamente le azioni. Un agente non deve avere una motivazione ostile per creare un incidente. È sufficiente che persegua con persistenza un obiettivo legittimo attraverso un percorso che l’organizzazione non aveva previsto o che non aveva tecnicamente impedito.
La cybersecurity deve controllare ciò che il modello può fare
Firewall, endpoint protection e segmentazione restano indispensabili, ma diventano insufficienti se un agente può operare attraverso credenziali valide e strumenti autorizzati. In quel momento una parte del problema si sposta dalla protezione del modello alla governance delle sue possibilità operative.
Il principio zero trust del NIST offre una base utile. L’accesso non dovrebbe derivare implicitamente dalla posizione nella rete o dall’appartenenza a un ambiente considerato affidabile, ma essere concesso in modo granulare in funzione della singola risorsa e dell’azione richiesta. Applicato agli agenti significa soprattutto evitare privilegi permanenti, contesti troppo ampi e autorizzazioni che sopravvivono al compito per cui erano state create.
Sei controlli da applicare prima dell’autonomia
- Privilegio minimo. Un agente che deve analizzare log non dovrebbe poter modificare un sistema di produzione.
- Credenziali temporanee. Token e autorizzazioni devono essere circoscritti al compito e, quando possibile, non riutilizzabili fuori dalla sessione.
- Isolamento e controllo della rete. L’ambiente operativo deve essere segregato e le destinazioni Internet raggiungibili devono essere definite esplicitamente.
- Approvazione umana indipendente. Le azioni irreversibili o ad alto impatto devono richiedere una conferma separata prima dell’esecuzione.
- Tracciamento dell’intera catena. Non basta conservare la risposta finale: occorre registrare strumenti utilizzati, identità, risorse coinvolte e sequenza delle operazioni.
- Interruzione e revoca immediate. L’organizzazione deve poter fermare l’esecuzione e revocare sessioni, token e privilegi senza dipendere dalla collaborazione del modello.
La responsabilità non passa alla macchina
Questa trasformazione del rischio tecnico ha una conseguenza immediata anche sul piano della responsabilità organizzativa e normativa.
Dal 2 agosto 2026 è entrata in applicazione un’ulteriore parte sostanziale dell’AI Act e Commissione europea e autorità nazionali hanno avviato l’enforcement delle disposizioni applicabili, mentre gli obblighi relativi ai sistemi ad alto rischio seguono un calendario differenziato. Dopo l’AI Omnibus, le regole per le categorie dell’Annex III si applicheranno dal 2 dicembre 2027 e quelle per i sistemi high-risk incorporati in prodotti regolamentati dal 2 agosto 2028. Un agente aziendale, inoltre, non è automaticamente classificato come high-risk: contano la destinazione d’uso e il settore in cui viene impiegato.
Dove il sistema rientra nelle categorie ad alto rischio, il regolamento prevede requisiti che comprendono logging, supervisione umana, robustezza e cybersecurity. Per le organizzazioni soggette a NIS2 restano inoltre centrali gestione del rischio, incident handling, sicurezza della supply chain, controllo degli accessi e asset management, con responsabilità di supervisione affidate agli organi di gestione.
Il confine da governare è quello tra obiettivo e autorizzazione
I casi emersi nel 2026 non dimostrano una volontà autonoma paragonabile a quella umana né permettono di attribuire intenzioni psicologiche ai modelli. Mostrano, invece, che sistemi sufficientemente capaci possono cogliere opportunità operative non previste da progettisti e valutatori.
Per un’impresa è già abbastanza. Il nuovo insider può non avere rancori, incentivi economici o interessi personali. Può essere un processo software autenticato, dotato di strumenti potenti e di una definizione incompleta dei propri confini.
La domanda decisiva, quindi, non è quando un’AI deciderà di ribellarsi. È molto più vicina: chi risponde quando un agente raggiunge un obiettivo autorizzato utilizzando un metodo che nessuno aveva autorizzato?
Bibliografia
OpenAI, The Defender’s Window, 17 agosto 2026
https://openai.com/index/the-defenders-window/
OpenAI, OpenAI and Hugging Face partner to address security incident during model evaluation, 21 luglio 2026, con aggiornamenti successivi
https://openai.com/index/hugging-face-model-evaluation-security-incident/
OpenAI, GPT-5.6 System Card, 9 luglio 2026
https://deploymentsafety.openai.com/gpt-5-6
Hugging Face, Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident, 27 luglio 2026
https://huggingface.co/blog/agent-intrusion-technical-timeline
Anthropic, Investigating three real-world incidents in our cybersecurity evaluations, 30 luglio 2026
https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals
UK AI Security Institute, Incident Report: unsanctioned agent behaviour during cyber testing, 4 agosto 2026
https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing
European Commission, AI Act – Regulatory framework for artificial intelligence
https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
EUR-Lex, Regulation (EU) 2024/1689 – Artificial Intelligence Act
https://eur-lex.europa.eu/eli/reg/2024/1689/oj
EUR-Lex, Directive (EU) 2022/2555 – NIS2
https://eur-lex.europa.eu/eli/dir/2022/2555/oj
NIST, SP 800-207 – Zero Trust Architecture
https://csrc.nist.gov/pubs/sp/800/207/final