Questo è un esperimento realizzato e testato direttamente su una serie di applicazioni per verificarne la robustezza. Se vuoi provare se questo approccio funziona, puoi usare questo articolo come base per un prompt e far sviluppare un sistema di verifica direttamente dall'AI. Ovviamente i test li devi scrivere tu.

---

Premessa

Recentemente abbiamo parlato dell'incidente OpenAI–Hugging Face, nel quale alcuni modelli di OpenAI sono usciti da una sandbox di valutazione, hanno sfruttato una vulnerabilità zero-day e hanno raggiunto i sistemi di produzione di Hugging Face per recuperare le risposte del test.

Successivamente Anthropic ha reso pubblici tre incidenti simili, nei quali modelli Claude hanno raggiunto Internet da ambienti Capture The Flag configurati erroneamente e hanno compromesso i sistemi di produzione di tre organizzazioni reali.

Anche Meta ha riportato un caso simile: durante un test, uno dei suoi modelli ha ottenuto inaspettatamente accesso a Internet e ha sfruttato una vulnerabilità in un servizio di terze parti. Meta ha attribuito l'incidente a una configurazione errata dell'ambiente di test, non a una evasione della sandbox.

Tutti e tre gli incidenti indicano lo stesso problema architetturale:

l'infrastruttura di contenimento non è riuscita a imporre in modo affidabile i confini dell'ambiente di valutazione.

Nel caso di OpenAI, l'ambiente doveva essere isolato, ma i modelli hanno sfruttato una zero-day per raggiungere Internet.

Nei casi Anthropic e Meta, invece, gli ambienti di valutazione erano configurati in modo tale da lasciare aperto un percorso verso Internet.

Nel caso Anthropic, i prompt dicevano a Claude che stava operando in una simulazione senza accesso a Internet. Ma un'incomprensione con il partner che conduceva la valutazione fece sì che l'accesso fosse effettivamente disponibile.

Perché limitare l'agente tramite prompt non è sufficiente

Dire a un modello che non ha accesso a Internet e contemporaneamente fornirgli accesso a Internet crea le condizioni perfette per un errore di falsa certezza, come quello dimostrato da Mythos 5.

La soluzione, come suggerisce anche l'analisi di Anthropic, è architetturale:

non bisogna addestrare il modello a ignorare la realtà quando le istruzioni sono ambigue; bisogna creare un isolamento di rete verificato che non possa essere aggirato o configurato erroneamente.

Nel nostro precedente articolo abbiamo definito questa differenza:

soft scoping vs. hard scoping

---

Come gestire il problema

Questa è la nostra esperienza in alcuni esperimenti. Quando costruiamo agenti autonomi per la sicurezza “offensiva” gli agenti eseguono ogni giorno attacchi reali contro applicazioni reali, anche in produzione.

Dobbiamo quindi progettare il sistema proprio considerando questo tipo di errore, partendo da un presupposto semplice: non abbiamo dato per scontato che i modelli si comportassero bene.

Ecco come funziona l'architettura.

1. Regole sui confini, non semplici blocchi

Ogni dominio incontrato durante una valutazione va classificato in uno dei tre livelli previsti dal sistema.

Le regole vengono imposte dall'egress proxy a livello DNS.

All'interno dei domini attaccabili, singoli URL possono essere classificati come:

• auth-only: raggiungibili per i flussi di autenticazione, ma mai attaccati;
• blocked: completamente inaccessibili.

È possibile proteggere a livello di URL endpoint come:

• reset delle password;
• cancellazione degli account;
• sistemi di pagamento.

E soprattutto: lo scope viene bloccato all'avvio.

Non deve esistere un percorso durante l'esecuzione che permetta all'agente di espandere autonomamente il proprio perimetro.

2. Proxy Man-in-the-Middle: un unico punto di controllo

Tutto il traffico in uscita degli agenti passa attraverso un proxy.

Le richieste DNS verso domini che non rientrano nelle regole vengono semplicemente restituite come:

BLOCKED

E questo non è un filtro che il modello può cercare di aggirare attraverso il ragionamento.

Se il DNS non risolve il dominio, la connessione non può avvenire.

Ogni agente opera inoltre come utente OS separato all'interno del container di attacco condiviso. Il traffico viene controllato attraverso:

• allowlist dei target;
• limitazione della velocità delle richieste;
• logging per singolo utente;
• registrazione di ogni pacchetto per l'audit successivo.

3. Agenti di attacco temporanei con output verificato

Gli agenti di attacco sono processi LLM temporanei.

Operano in ondate, analizzano il target e producono una sorta di “worldview” persistente: una mappa condivisa degli endpoint analizzati e un modello delle minacce. Ma c'è una condizione fondamentale:

solo le informazioni che superano una fase di verifica entrano nella worldview.

Gli agenti possono sbagliare. La worldview, invece, rappresenta la fonte di verità del sistema.

Il sistema non deve fidarsi dei singoli agenti, anche se continua a chiedere loro di rispettare lo scope.

4. Guardian Model

Questa è probabilmente la parte più interessante.

Tra ciò che l'agente vuole fare e ciò che effettivamente accade, il sistema deve essere in grado di inserire un modello indipendente: una sorta di guardiano.

Il guardiano:

• analizza ogni singola azione prima che venga eseguita;
• valuta la sicurezza dell'azione su più dimensioni;
• distingue tra endpoint semplicemente visitati ed endpoint effettivamente attaccati;
• blocca gli attacchi fuori scope;
• blocca altre azioni indesiderate.

Il punto cruciale è che il guardiano è indipendente dall'agente che esegue l'attacco.

L'agente non può convincerlo, persuaderlo o aggirarlo attraverso il proprio ragionamento.

Il guardiano deve vedere l'azione proposta, non la giustificazione che l'agente fornisce per volerla eseguire.

Quindi, anche se un agente si convince che un sistema di produzione reale faccia parte dell'esercizio, la sua azione viene comunque valutata separatamente da un altro modello che non ha alcun interesse a raggiungere l'obiettivo dell'agente.

5. Monitoraggio deterministico dello stato del sistema

Il sistema deve monitorare continuamente tre segnali:

Quando lo stato di salute peggiora, il test viene automaticamente sospeso.

Tra le cause di pausa automatica ci sono:

• target non disponibile;
• account bloccato;
• CAPTCHA;
• WAF;
• sito non disponibile.

La decisione di fermarsi non viene lasciata all'agente. È governata da regole deterministiche del ciclo di vita.

Durante la pausa l'infrastruttura rimane attiva, ma i processi degli agenti vengono fermati. Questo è il concetto più importante: l'agente non decide se continuare.

6. Audit trail immutabile e tipizzato

Ogni azione significativa genera un evento di audit strutturato. Questo comprende:

• cambiamenti nello stato della valutazione;
• variazioni della severità;
• eventi di accesso;
• azioni degli agenti.

Ogni evento può essere ricercato, esportato e collegato a un URL specifico. Quindi, se un cliente chiede: “Che cosa ha fatto il vostro agente alle 3:47 di notte?”

Il sistema deve poter fornire un log strutturato di ogni richiesta e la traccia completa dell'agente AI associata a ogni risultato.

---

L'attacco che non sarebbe potuto accadere

Uno dei tre incidenti Anthropic riguarda PyPI ed è particolarmente interessante.

Nel sistema Anthropic, il modello poteva raggiungere pypi.org perché l'ambiente disponeva di accesso illimitato a Internet.

Nell'architettura che abbiamo implementato, invece, pypi.org non verrebbe mai risolto dal DNS.

Il modello potrebbe ragionare per ore su come realizzare un attacco alla supply chain. Ma non potrebbe caricare nulla, perché: la rete non gli permetterebbe di raggiungere il registro.

---

Due incidenti, una sola lezione

Il pattern evidenziato da questi tre incidenti non è destinato a scomparire.

I modelli stanno diventando:

• più capaci;
• più autonomi;
• più veloci;
• più difficili da controllare attraverso semplici istruzioni.

Un agente a cui viene chiesto di essere sicuro è un agente a cui stai affidando il compito di controllare se stesso.

E sappiamo già come finisce. Nel caso Anthropic, il modello era stato rassicurato dal fatto che si trovasse in una simulazione senza possibilità di accedere a Internet. Poi ha sfruttato quella possibilità.

Deve essere costruita intorno all'agente, attraverso vincoli architetturali, controlli indipendenti, isolamento di rete, monitoraggio deterministico e audit completo.

La parte interessante