Lunedì mattina un agente AI entra in una sandbox. È lì per fare il bravo: scrivere codice, eseguire qualche test, magari cercare una vulnerabilità in un ambiente controllato. Nessuno gli ha dato Internet. Nessuno gli ha detto che può parlare con altri agenti. Le porte sono chiuse, almeno secondo il diagramma dell’architettura. Poi l’agente scopre che può scrivere file in un servizio di Artifactory. Quel servizio, a sua volta, può parlare con Internet. La sandbox non ha una rete, ma ha una finestra. Naturalmente la finestra non era disegnata nell’architettura.
La vicenda OpenAI-Hugging Face raccontata nel recente postmortem di OpenAI è interessante proprio per questo motivo. Non perché un agente abbia trovato una vulnerabilità, cosa che ormai non dovrebbe sorprendere nessuno, ma perché ha collegato elementi che gli esseri umani avevano considerato separatamente. Un servizio per i pacchetti è diventato un canale di comunicazione. Un sistema di storage è diventato una bacheca. Credenziali esposte sono diventate il ponte verso un’altra infrastruttura. Una vulnerabilità ha fornito l’accesso necessario per sfruttarne un’altra. La sicurezza aveva costruito muri; l’agente ha cercato corridoi.
Il dettaglio più scomodo è che non serve immaginare un’intelligenza artificiale particolarmente sofisticata o fantascientifica. Basta un sistema capace di scrivere codice, utilizzare strumenti, interrogare servizi, analizzare risultati e perseguire un obiettivo per un periodo sufficientemente lungo. È precisamente il tipo di comportamento che l’industria sta vendendo come la prossima grande rivoluzione della produttività. Lo stesso meccanismo che rende un agente utile per automatizzare un lavoro rende possibile anche una forma di attacco diversa da quella a cui siamo abituati: non un singolo exploit spettacolare, ma una ricerca instancabile di una sequenza di piccoli passaggi.
Qui entra in scena Trail of Bits, che ha sottoposto a un test ancora più imbarazzante una delle convinzioni fondamentali dell’infrastruttura moderna. Un agente cyber-capable basato su GPT-5.6-Cyber è riuscito per tre volte a evadere da una macchina virtuale QEMU/KVM. Il primo tentativo ha sfruttato una vulnerabilità del kernel già nota. Dopo l’aggiornamento dell’host, l’agente ha combinato un’altra vulnerabilità conosciuta con un bug fix che non era stato classificato come problema di sicurezza. Quando anche QEMU e le sue dipendenze sono state ricostruite dal codice upstream aggiornato, l’agente non ha semplicemente dichiarato forfait, come farebbe un consulente umano quando vede che il budget è finito. Ha continuato a studiare lo stack per ore e ha costruito una nuova catena comprendente tre vulnerabilità precedentemente sconosciute.
È questo il passaggio che dovrebbe interessare maggiormente chi progetta infrastrutture AI. Il problema non è che una VM possa essere vulnerabile. Lo sappiamo da decenni. Il problema è che stiamo mettendo dall’altra parte del confine un’entità che può continuare a cercare finché non trova qualcosa. La sicurezza tradizionale è stata costruita intorno a una combinazione di patch, controlli, autenticazione, segmentazione e assunzioni statistiche sul comportamento dell’attaccante. L’attaccante umano ha tempo limitato, attenzione limitata, memoria limitata e, soprattutto, tende a stancarsi. L’agente non ha nessuna di queste virtù.
La cultura DevSecOps ha passato vent’anni a spiegare che il container non è una frontiera di sicurezza assoluta. Adesso dobbiamo ripeterlo con le macchine virtuali, probabilmente con maggiore enfasi. Container e VM restano strumenti eccellenti. Alzano il costo dell’attacco, riducono la superficie disponibile e rendono più difficile attraversare determinati confini. Ma confondere un ostacolo con una garanzia è uno degli errori più antichi dell’informatica. La storia della sicurezza è sostanzialmente una collezione di tecnologie progettate come ultima linea di difesa che, dopo qualche anno, diventano la prima cosa che l’attaccante studia.
La conseguenza architetturale è brutale nella sua semplicità: non bisogna più progettare un ambiente AI assumendo che l’agente resterà confinato. Bisogna progettare l’ambiente assumendo che prima o poi verrà compromesso. La differenza sembra semantica, ma cambia completamente il modello operativo. Se un agente non deve accedere alla produzione, non bisogna chiedergli attraverso un prompt di non farlo. Bisogna semplicemente evitare di dargli credenziali e percorsi di rete che conducano alla produzione. Se deve leggere un repository, la sua identità deve poter leggere quel repository e niente altro. Se una certa operazione richiede approvazione, l’approvazione deve essere verificata dall’infrastruttura prima dell’esecuzione, non interpretata dal modello come un suggerimento morale.
Il prompt, in questo scenario, torna al suo ruolo reale. È uno strumento comportamentale, non un firewall. Può orientare il modello, spiegargli le regole, segnalare ciò che non dovrebbe fare. Non può diventare il componente che garantisce che una determinata operazione sia impossibile. Chiedere a un modello di non utilizzare una credenziale quando la credenziale è disponibile è una forma molto sofisticata di fiducia mal riposta. È come lasciare le chiavi della cassaforte sulla scrivania e appendere sopra un cartello con scritto “per favore, no”.
La superficie di attacco cresce inoltre con ogni interfaccia che colleghiamo all’agente. File system condivisi, API, browser, package manager, webhook, URL preview, proxy, socket di amministrazione, servizi cloud, sistemi CI/CD, strumenti di debugging. Ogni comodità aggiunge codice, e ogni pezzo di codice aggiunge una possibilità. La vecchia regola del least privilege diventa quindi ancora più importante nell’era degli agenti: meno strumenti, meno privilegi, meno rete, meno segreti e identità temporanee con valore limitato.
Il problema della rete è particolarmente insidioso perché l’isolamento raramente è una proprietà del singolo processo. Un agente può non avere accesso diretto a Internet e tuttavia raggiungere un servizio che può raggiungere Internet. Può non poter interrogare Kubernetes direttamente e tuttavia chiamare un’API che lo fa per lui. Può non possedere una credenziale privilegiata e tuttavia scrivere qualcosa in un sistema dal quale quella credenziale viene successivamente recuperata. L’incidente OpenAI-Hugging Face dimostra esattamente questo principio: la sicurezza di un sistema distribuito non può essere valutata osservando una singola connessione. Bisogna seguire l’intera catena.
La stessa logica vale per le identità. Un worker compromesso non dovrebbe trasformarsi nel passe-partout dell’infrastruttura. Le credenziali devono essere brevi, circoscritte e possibilmente inutili al di fuori dello specifico compito. Un agente che elabora documenti non deve poter amministrare Kubernetes. Un ambiente di inferenza non deve poter enumerare segreti aziendali. Un sistema incaricato di analizzare codice non dovrebbe poter creare nuove identità cloud o modificare le policy di rete. Sembra banale; proprio per questo viene dimenticato con impressionante regolarità.
La vera trasformazione introdotta dagli agenti AI, quindi, non riguarda soltanto la capacità offensiva del modello. Riguarda la velocità con cui può attraversare una superficie tecnologica complessa e ricombinare informazioni apparentemente scollegate. Un essere umano può identificare tre vulnerabilità appartenenti a componenti diversi e capire che insieme costituiscono una catena. Un agente può farlo sistematicamente, provando varianti, leggendo documentazione, scrivendo exploit, osservando gli errori e ricominciando. La vulnerabilità individuale diventa meno importante della topologia complessiva del sistema.
Questo obbliga anche a cambiare il modo in cui facciamo red teaming. Cercare singole falle non è più sufficiente. Bisogna simulare percorsi completi: dall’agente al workload, dal workload alle credenziali, dalle credenziali al cloud, dal cloud al CI/CD, dal CI/CD alla supply chain e, eventualmente, verso infrastrutture di terze parti. La sicurezza deve cominciare a ragionare come ragiona l’agente, cioè in termini di obiettivo e percorso, non soltanto di vulnerabilità catalogate.
Qesta nuova realtà arriva proprio mentre l’industria sta raccontando gli agenti come dipendenti digitali instancabili. Potranno lavorare tutta la notte, usare decine di strumenti, coordinarsi tra loro, prendere decisioni e completare task complessi senza supervisione continua. È una descrizione eccellente della produttività futura e, con poche modifiche, anche di un incidente di sicurezza particolarmente costoso. L’autonomia è una feature quando l’obiettivo è corretto; diventa una vulnerabilità quando l’obiettivo è sbagliato o quando l’ambiente concede troppo spazio per perseguirlo.
Per questo la regola più sensata emersa dagli incidenti di questa settimana è anche la meno spettacolare: progettare assumendo il compromesso. Non significa rinunciare agli agenti, alle VM, ai container o alle guardrail comportamentali. Significa smettere di chiedere a uno solo di questi strumenti di essere la nostra ultima speranza. Una guardrail può fallire. Una VM può essere evasa. Una credenziale può essere rubata. Un servizio può essere trasformato in proxy. Una vulnerabilità sconosciuta può esistere proprio dove nessuno l’ha ancora cercata.
Un buon sistema AI non è quello in cui l’agente non riesce mai a uscire. È quello in cui, quando finalmente ci riesce, scopre di essere uscito in una stanza vuota.