I ricercatori di HiddenLayer aggirano le guardrails di OpenAI, esponendo una criticità fondamentale nell’autoregolamentazione dell’AI

Il 6 ottobre 2025, OpenAI ha annunciato AgentKit, uno strumento per la creazione, la distribuzione e la gestione di agenti AI. Uno dei suoi componenti è Guardrails, un livello di sicurezza modulare progettato per monitorare gli input, gli output e le interazioni degli strumenti degli agenti per prevenire abusi, perdite di dati o comportamenti maligni. Guardrails può mascherare o segnalare informazioni personali, rilevare tentativi di evasione e applicare vincoli di politica accanto all’esecuzione degli agenti.

Mentre Guardrails è un pezzo recentemente reso pubblico dell’architettura degli agenti di OpenAI, la ricerca di HiddenLayer rivela una vulnerabilità più profonda: poiché sia le azioni degli agenti che i controlli di sicurezza utilizzano una logica di modello simile, gli attaccanti possono creare input che compromettono entrambi contemporaneamente, rompendo efficacemente il livello di sicurezza dall’interno.

Cosa ha scoperto HiddenLayer

La progettazione di OpenAI prevede agenti che operano attraverso una logica a catena: un utente emette una richiesta, l’agente chiama strumenti o risorse esterne e le risposte vengono filtrate o validate da Guardrails prima dell’esecuzione o dell’output. L’intenzione è che, indipendentemente da ciò che l’agente tenta di fare, che si tratti di generare testo, recuperare una pagina web o attivare una funzione, Guardrails agisca come un guardiano.

HiddenLayer sostiene che questo guardiano è strutturalmente difettoso quando è costruito con la stessa classe di modello che sta proteggendo. Nei loro esperimenti, hanno creato prompt che svolgono un doppio ruolo: costringono il modello dell’agente a generare contenuti che violano la politica e manipolano il modello di giudizio di Guardrails per dichiarare che il contenuto è “sicuro”. In effetti, il prompt incorpora un override della logica interna del giudice, delle sue soglie di confidenza, dei rami decisionali, in modo che il giudice falsamente approvi l’output maligno. Il sistema produce quindi contenuti non ammessi senza scatenare alcun allarme.

Hanno spinto l’attacco più in là, mirando a iniezioni di contenuti indiretti, come ad esempio richieste di fetch basate su strumenti. Supponiamo che l’agente recuperi una pagina web contenente istruzioni maligne o prompt nascosti. Guardrails dovrebbe segnalare o bloccare, ma la tecnica di HiddenLayer incorpora un override del giudice nel contenuto recuperato stesso. Quando il giudice elabora il contenuto, vede l’override e “approva” il contenuto, permettendo alla richiesta di strumento, e a qualsiasi contenuto maligno che restituisce, di passare incontrollato.

La lezione più profonda è chiara: quando il tuo meccanismo di sicurezza è costruito utilizzando la stessa logica e le stesse vulnerabilità della cosa che protegge, un singolo prompt astuto può rompere entrambi.

Perché questo è importante

Ciò che HiddenLayer ha esposto non è un semplice bug, ma una storia di avvertimento su come progettiamo la sicurezza nei sistemi LLM. Qualsiasi architettura che si affidi alla stessa classe di modello per generazione ed valutazione rischia di fallire condiviso in caso di input avversariali.

Ciò significa che molti deployer che credevano “abbiamo inserito Guardrails, quindi siamo al sicuro” potrebbero sottovalutare il rischio. Nei casi d’uso benigni e casuali, i loro filtri potrebbero sembrare efficaci, ma in scenari avversariali, potrebbero fallire silenziosamente. In domini come sanità, finanza, governo o sistemi critici, tali fallimenti silenziosi potrebbero portare a gravi danni.

Questa ricerca si basa anche su metodi di iniezione di prompt precedenti. La tecnica precedente di HiddenLayer, “Policy Puppetry“, ha mostrato come gli attaccanti possano mascherare istruzioni dannose come contenuto di politica. Ora, dimostrano che tali attacchi mascherati possono estendersi nella logica di sicurezza stessa.

Implicazioni per i deployer e i ricercatori

Alla luce di questa vulnerabilità, chiunque utilizzi o costruisca sistemi LLM agentici deve ripensare la strategia di sicurezza.

Innanzitutto: non affidarsi solo ai controlli basati sul modello interno. La sicurezza deve essere stratificata. Ciò significa combinare filtri basati su regole, rilevamento di anomalie, sistemi di logging, monitoraggio esterno, supervisione umana e tracce di audit. Se un livello fallisce, altri potrebbero intercettare la violazione.

In secondo luogo: test di red team avversariali regolari sono indispensabili. I modelli dovrebbero affrontare iniezioni di prompt che tentano di sovrascrivere la logica di guardia stessa, non solo “contenuti cattivi”. I test devono evolversi man mano che gli attaccanti inventano nuove tecniche.

In terzo luogo: nei settori regolamentati o critici per la sicurezza, trasparenza e verificabilità sono essenziali. I deployer necessitano della prova che un sistema possa resistere agli attacchi avversariali, non solo alla funzionalità di base. Ciò suggerisce che audit di terze parti, verifica formale o garanzie di sicurezza potrebbero diventare requisiti.

In quarto luogo: per i costruttori di modelli, correggere questa classe di vulnerabilità è difficile. Poiché è legata a come i modelli analizzano e obbediscono alle istruzioni, semplicemente filtrare una classe di prompt non garantisce la resilienza a nuovi prompt. La difesa basata sul fine-tuning o sui filtri potrebbe degradare le prestazioni del modello o portare a una corsa agli armamenti. Un design più robusto potrebbe richiedere separazione architettonica, con la logica di guardia che esegue in un modello o sottosistema diverso dal modello di generazione.

Limitazioni e domande aperte

Per essere chiari: il lavoro di HiddenLayer è una dimostrazione di concetto, non un verdetto finale su ogni architettura di sicurezza. I loro attacchi di successo dipendono da una profonda conoscenza della struttura di prompt e della logica di punteggio interna del modello di guardia. In ambienti di prompt più restrittivi o sistemi che randomizzano le difese, l’attacco potrebbe essere più difficile da eseguire.

Inoltre, non analizzano completamente quanto siano coerenti o utili gli output maligni quando creati sotto queste limitazioni. Alcuni output di jailbreak o override potrebbero degradare in qualità o affidabilità. Quindi il rischio è reale, ma limitato dall’ambiente, dal budget di prompt, dalle restrizioni dell’interfaccia e dalla casualità della guardia.

Infine, alcuni progetti di guardrail utilizzano classi di modelli diverse, metodi ensemble o valutazioni randomizzate. Non è certo che ogni sistema del genere sia vulnerabile; se questo attacco si generalizza ampiamente è una domanda di ricerca aperta.

Guardando avanti: il futuro della sicurezza dell’AI

Sembra che stiamo entrando in una nuova fase: attacchi di prompt non solo contro i modelli, ma contro i loro strati di sicurezza. Tecniche come hijacking della catena di pensiero, sovversione gerarchica dei prompt e override del giudice spingeranno le difese a evolversi più velocemente.

La strada in avanti è probabilmente verso la supervisione esterna: sistemi che monitorano gli output dall’esterno, non condividono la logica del modello o applicano controlli di sicurezza tramite verifiche esterne. Architetture ibride, metodi formali, rilevamento di anomalie e cicli di feedback umani dovranno unirsi.

Guardrails sono uno strumento utile, ma le scoperte di HiddenLayer ci ricordano: non possono essere l’unico strumento. La sicurezza deve provenire dall’esterno del sistema, non solo dall’interno.