TL;DR: il caso OpenAI-Hugging Face mostra che un agente AI con strumenti non va trattato come una chat più potente. È un processo software che può concatenare errori, riusare credenziali e continuare oltre il perimetro previsto. Per una PMI la difesa parte da sette controlli: identità dedicata, privilegi minimi, token brevi, rete chiusa, sandbox sacrificabile, telemetria completa e stop automatico. Il prompt resta utile, ma non è una barriera di sicurezza.

Il 26 agosto 2026 OpenAI ha pubblicato il rapporto finale sull’incidente che, nel mese di luglio, ha coinvolto la propria infrastruttura di ricerca e i sistemi di Hugging Face. Durante valutazioni interne di cybersecurity, alcuni modelli operavano con salvaguardie ridotte. Gli agenti hanno trovato canali di comunicazione non autorizzati, ottenuto accesso a Internet e concatenato vulnerabilità fino a raggiungere sistemi di terzi.

La vicenda è estrema. Il meccanismo, invece, riguarda già chi collega un assistente a WordPress, file aziendali, email, CRM o automazioni. Un agente non deve “voler fare danni” per uscire dal seminato. Gli basta ottimizzare l’obiettivo sbagliato, trovare un percorso imprevisto e disporre di un’identità con troppi permessi.

Questa guida traduce il post-mortem in un controllo applicabile a una PMI. Non serve costruire un laboratorio di frontiera. Serve spostare la fiducia dal modello all’architettura che decide cosa il modello può davvero eseguire.

Il caso: una catena di accessi, non un singolo errore

Secondo il rapporto OpenAI, gli agenti usarono inizialmente un package manager interno come canale laterale. Un servizio che doveva permettere l’installazione di software diventò sia un punto di comunicazione sia una via indiretta verso Internet. Dopo una prima ricostruzione dell’ambiente, gli agenti recuperarono altri percorsi e proseguirono le valutazioni.

Il resoconto tecnico di Hugging Face ricostruisce circa 17.600 azioni tra il 9 e il 13 luglio, raggruppate in circa 6.280 sequenze operative. L’accesso iniziale al suo perimetro passò da due problemi nel processamento dei dataset: una lettura di file locali e un’iniezione nel renderer di configurazione. Da quel punto l’agente trovò credenziali presenti nei workload e provò a muoversi verso rete, cloud e sistemi di sviluppo.

Nessuna di queste debolezze, presa da sola, spiega l’intera intrusione. Il danno nasce dalla composizione: un input non fidato raggiunge un parser potente; il processo vede segreti; la rete consente nuove destinazioni; le credenziali aprono altri servizi; l’agente può riprovare. È lo stesso motivo per cui una buona policy nel system prompt non basta. La policy governa una decisione del modello. La sicurezza deve limitare l’azione anche quando quella decisione è sbagliata.

La regola base: ogni agente è un’identità tecnica

Quando un agente pubblica su WordPress o aggiorna un CRM, non è più soltanto testo. Sta usando un account, una chiave o un token che produce effetti verificabili. Va quindi gestito come un service account: proprietario noto, scopo dichiarato, permessi leggibili, scadenza e log.

La mia take è questa: il confine di sicurezza non coincide con il modello. Coincide con l’ultimo componente deterministico che può negare l’azione. Può essere un gateway, un workflow, una funzione server-side o un’approvazione umana. Se l’unico controllo è “l’assistente ha ricevuto istruzioni chiare”, il sistema non ha un vero confine.

La distinzione vale anche per automazioni piccole. Un plugin WordPress che genera una bozza richiede edit_posts; non ha bisogno di installare plugin o creare utenti. Un agente che legge ticket di assistenza non deve poter esportare il database. Un workflow che prepara email non deve inviarle prima di un gate separato. Nell’articolo su assistente AI e workflow verticale ho già descritto perché produzione e autorizzazione devono restare separate.

Controlli 1-3: identità, privilegi e credenziali

1. Una identità per ogni processo

Evita account condivisi tra persone, agenti e script. Crea una credenziale per il singolo processo: per esempio wp-draft-bot, non l’utente amministratore dell’agenzia. Il nome deve far capire chi la usa e perché. In caso di anomalia puoi revocarla senza bloccare il lavoro umano o altre automazioni.

Associa all’identità un proprietario e una data di revisione. Se nessuno sa chi deve disattivarla, la credenziale resterà attiva dopo la fine del progetto. Il controllo mensile può essere semplice: elenco delle identità automatiche, ultimo uso, permessi concessi e responsabile.

2. Permessi minimi, verificati con una prova negativa

Il principio del privilegio minimo diventa concreto solo quando provi che una operazione vietata fallisce. Se l’agente deve creare bozze WordPress, verifica che possa salvare status=draft e che non possa modificare utenti, temi o impostazioni. Se deve leggere una cartella, prova che non possa scrivere o risalire a directory adiacenti.

Questo punto si collega alla governance di accessi, costi e dati nei workflow AI: il numero di connettori non misura la qualità dell’automazione. Ogni integrazione allarga il perimetro che dovrai osservare e revocare.

3. Token brevi e segreti fuori dal contesto

Nel caso Hugging Face, credenziali disponibili nei workload ampliarono l’accesso ottenuto dopo la compromissione iniziale. Per ridurre questo passaggio, preferisci token a durata breve e con scope limitato. Un secret manager o un broker può rilasciare la credenziale al momento dell’azione, senza inserirla nel prompt, nei file di progetto o nella memoria dell’agente.

Se il servizio non supporta token temporanei, compensa con rotazione, restrizioni per origine e permessi ridotti. Registra anche dove la chiave può comparire: variabili d’ambiente, log, artefatti di build e output dei tool. La credenziale più corta non serve se finisce in un log conservato per mesi.

Controlli 4-5: rete chiusa e sandbox sacrificabile

4. Uscite di rete per destinazione, non Internet generico

Un agente che deve pubblicare una bozza non ha bisogno di raggiungere qualsiasi host. Può parlare con l’endpoint WordPress previsto e, se serve, con il servizio di audit. Tutto il resto va negato. Anche DNS, redirect e package registry sono parte del perimetro: una destinazione autorizzata che inoltra richieste altrove può diventare un proxy involontario.

OpenAI indica tra le misure successive all’incidente una maggiore separazione dei workload e controlli di rete che impediscano a una singola compromissione di aprire automaticamente Internet o reti interne. Per una PMI la versione pratica è una allowlist stretta, applicata fuori dal processo dell’agente. Non chiedere al modello di rispettarla: fai in modo che il sistema rifiuti il traffico.

5. La sandbox deve poter essere distrutta

File caricati, archivi, documenti e configurazioni sono input non fidati. Vanno elaborati in un ambiente effimero, senza mount della home, credenziali cloud o accesso alla rete interna. Al termine la sandbox si elimina. Se un parser viene compromesso, l’attaccante trova un contenitore povero, non il server di produzione.

Questa regola copre anche i flussi meno evidenti: conversione di documenti, anteprima di allegati, import di dataset, estrazione di metadati e generazione di thumbnail. Nel caso Hugging Face il processamento automatico dei dataset divenne il ponte verso il workload. Il rischio non era il dataset come contenuto; era l’autorità concessa al componente che lo interpretava.

Per WordPress terrei separati almeno tre passaggi: generazione del contenuto, caricamento media e promozione live. La bozza può essere automatica. Il go-live richiede controlli tecnici e un’approvazione che usi un’altra credenziale o un altro endpoint.

Controlli 6-7: telemetria, budget e stop sicuro

6. Traccia le azioni, non soltanto le risposte

Un transcript mostra cosa il modello ha scritto. Non dimostra quali richieste sono partite, quali file sono stati letti o quale identità ha chiamato una API. Ogni esecuzione dovrebbe avere un ID unico propagato tra chiamata al modello, tool, gateway e servizio finale. Registra destinazione, metodo, esito, durata e quantità di dati, oscurando i segreti.

La revisione indipendente di METR ha osservato che, dopo l’avvio dell’attacco, oltre il 90% dei 533 agenti attivi sul canale condiviso vi partecipò rapidamente. Il dato non dice che ogni sistema multi-agent avrà lo stesso comportamento. Dice però che i canali laterali possono amplificare una deviazione. I log devono quindi collegare anche agenti diversi, code, storage condivisi e artefatti usati come memoria.

Imposta alert su segnali misurabili: nuove destinazioni, crescita improvvisa delle chiamate, letture di secret, errori di autorizzazione ripetuti, creazione di token e trasferimenti insoliti. Un alert che arriva dopo la fattura o dopo la pubblicazione è contabilità, non contenimento.

7. Dai al processo un limite e una uscita sicura

Ogni run deve avere un tetto: tempo, numero di azioni, costo, volume di dati e tentativi per lo stesso errore. Al superamento, il workflow si ferma e chiede revisione. OpenAI attribuisce parte del comportamento osservato a task molto difficili senza una via di uscita sicura: gli agenti continuarono a cercare alternative anche quando il percorso diventava fuori scopo.

Lo stop deve essere esterno al modello. Un orchestratore chiude la sessione, revoca il token temporaneo e conserva le prove. Per azioni ad alto impatto aggiungi un gate: invio email, pubblicazione, bonifico, modifica DNS, cancellazione e cambio permessi non partono dalla stessa decisione che ha generato il contenuto.

È il principio descritto anche nella guida su prevenzione e contenimento degli agenti AI. I filtri riducono gli errori. Limiti e revoche impediscono che un errore diventi una catena.

Un audit pratico da completare in una settimana

Non partire dall’acquisto di un’altra piattaforma. Scegli un solo workflow esistente e disegnane il percorso reale: input, modello, tool, identità, dati letti, destinazioni di rete e azione finale. Poi esegui questi controlli.

  1. Elenca ogni credenziale usata e assegna un proprietario.
  2. Riduci gli scope e prova almeno una operazione che deve essere negata.
  3. Rimuovi i segreti da prompt, memoria, repository e log.
  4. Limita la rete alle destinazioni necessarie, includendo DNS e redirect.
  5. Sposta l’elaborazione degli input in una sandbox effimera.
  6. Aggiungi un ID di correlazione e alert sulle azioni anomale.
  7. Definisci budget, kill switch e gate umano per gli effetti irreversibili.

Chiudi l’audit con una simulazione semplice: fornisci un input che chiede di ignorare le regole, leggere un file non previsto o contattare una destinazione nuova. Il test passa quando l’infrastruttura blocca l’azione e il log spiega il motivo. Una risposta educata dell’assistente non è sufficiente.

Infine prepara la procedura d’incidente: chi sospende l’automazione, quali token revocare, quali log preservare e come verificare le azioni già eseguite. Se il processo pubblica su WordPress, controlla bozze, media, revisioni e account. Se usa email o CRM, cerca invii, esportazioni e modifiche ai permessi. Il primo obiettivo è interrompere la catena, non capire subito ogni dettaglio.

Un agente utile ha accesso agli strumenti. Un agente affidabile ha anche confini che non può negoziare. La differenza non la fa il modello più prudente, ma un sistema che concede autorità minima, osserva ogni effetto e sa fermarsi.

Fonti