Il jailbreak LLM XBreaking rivolge l'AI spiegabile contro i filtri di sicurezza

I ricercatori di XBreaking hanno usato l'AI spiegabile per individuare e indebolire i controlli di sicurezza in sette modelli linguistici a pesi aperti. Le loro scoperte trasformano una promessa difensiva in un conflitto di sicurezza. Il jailbreak LLM XBreaking usa segnali interni del modello per identificare i livelli associati al comportamento di rifiuto. Poi prende di mira i componenti vicini invece di cercare alla cieca un prompt efficace.

Lo studio sottoposto a revisione paritaria è apparso su Neural Computing and Applications il 10 ottobre 2026. Ricercatori dell'Università di Pavia e della Cochin University of Science and Technology hanno sviluppato il metodo. Hanno testato modelli delle famiglie Llama, Qwen, Gemma e Mistral.

Non si tratta di un altro prompt che inganna un chatbot con giochi di parole. XBreaking presuppone l'accesso diretto ai pesi del modello, agli stati nascosti, alle mappe di attenzione e ad altre informazioni interne. Questa limitazione riduce la minaccia immediata, ma rende anche più netto l'avvertimento per le organizzazioni che distribuiscono modelli aperti personalizzabili.

Il conflitto centrale è ora chiaro. L'interpretabilità può aiutare gli ingegneri a comprendere e rafforzare i comportamenti di sicurezza. La stessa visibilità può anche mostrare a un attaccante esattamente dove tale comportamento è concentrato.

Cosa ha effettivamente cambiato il jailbreak LLM XBreaking

XBreaking sostituisce la sperimentazione sui prompt con una ricerca mirata dei componenti interni che distinguono i modelli allineati da quelli privi di restrizioni.

I jailbreak più noti operano attraverso l'interfaccia di un chatbot. Un attaccante modifica la formulazione, la struttura, la lingua o il contesto di una richiesta finché il sistema smette di rifiutarla. Questo processo spesso comporta generazione e test ripetuti.

XBreaking opera invece all'interno del modello. I suoi ricercatori confrontano un modello ottimizzato per la sicurezza con una controparte senza restrizioni della stessa famiglia architetturale. Chiamano queste versioni “censored” e “uncensored”, sebbene modelli ottimizzati per la sicurezza e senza restrizioni siano descrizioni più neutrali.

Il confronto usa l'AI spiegabile, ovvero tecniche che rivelano i segnali associati alle decisioni interne di un modello. I ricercatori misurano i valori medi di attivazione e attenzione nei livelli transformer. Le attivazioni rappresentano calcoli interni, mentre i valori di attenzione descrivono quanto fortemente i token si influenzano a vicenda durante l'elaborazione.

Lo studio pubblicato descrive un processo in tre fasi. Prima, il team profila entrambe le versioni usando input dannosi e benigni. Secondo, un metodo statistico di selezione delle caratteristiche classifica i livelli che distinguono meglio le versioni. Terzo, l'attacco perturba i componenti attorno a quei livelli selezionati.

Questa sequenza è importante perché trasforma l'interpretabilità in ricognizione. Il metodo non considera ogni parametro ugualmente rilevante. Cerca una piccola regione interna in cui l'ottimizzazione per la sicurezza sembra più visibile.

Gli esperimenti hanno coperto sette modelli a pesi aperti. Includevano Llama 3.2 1B, Llama 3.1 8B, Qwen2.5 0.5B, Qwen2.5 3B, Gemma 2B, Gemma 7B e Mistral-7B-v0.3.

Ogni modello aveva una variante senza restrizioni corrispondente, con la stessa architettura generale e configurazione dei parametri. Questo abbinamento ha dato ai ricercatori un modo controllato per confrontare il comportamento interno.

La valutazione ha usato 100 comportamenti dannosi in dieci categorie. Tali categorie includevano frode, disinformazione, malware, violazioni della privacy, molestie, danno fisico e consulenza specialistica non sicura. I ricercatori li hanno abbinati a 100 comportamenti benigni su argomenti correlati.

Questa configurazione proveniva dal dataset JailbreakBench, un benchmark aperto per valutare prompt avversari e difese. Il team ha inizialmente escluso le domande che producevano già risposte non sicure senza alcun attacco. Questa scelta ha impedito che fallimenti preesistenti gonfiassero i risultati dell'attacco riportati.

XBreaking modifica quindi l'obiettivo del jailbreak. Il prompt resta rilevante, ma non è più l'oggetto principale dell'ottimizzazione. La firma interna della sicurezza del modello diventa il bersaglio.

Questa distinzione crea la tensione centrale dell'articolo. Un meccanismo di sicurezza che lascia una firma interna misurabile diventa più facile da studiare. Diventa anche più facile da attaccare quando un avversario controlla il modello.

Come XBreaking individua i livelli critici per la sicurezza

I ricercatori trattano le differenze tra modelli allineati e senza restrizioni come un'impronta digitale che rivela dove è concentrato il comportamento di rifiuto.

Il metodo inizia inviando domande standardizzate attraverso entrambe le versioni di un modello. Registra le attivazioni medie e i punteggi di attenzione per ogni livello. I valori vengono normalizzati affinché i ricercatori possano confrontare segnali con intervalli numerici diversi.

Un processo di selezione delle caratteristiche chiede quindi quali misurazioni a livello di layer classificano meglio un modello come ottimizzato per la sicurezza o senza restrizioni. I ricercatori usano un test di analisi della varianza per classificare tali caratteristiche. Selezionano il gruppo più piccolo che offre una precisione di classificazione utile.

Questa è la parte “spiegabile” del funzionamento di XBreaking. Anziché sostenere che ogni segnale nascosto abbia un significato intuitivo per l'essere umano, il metodo identifica differenze misurabili associate all'allineamento. Tali differenze indicano ai ricercatori dove ispezionare o intervenire.

L'articolo riporta un'accuratezza di fingerprinting superiore al 90 percento per cinque delle sette configurazioni di modello. Riporta un'accuratezza del 100 percento per Gemma 7B e dell'82,5 percento per Mistral-7B-v0.3. Si tratta di risultati di classificazione all'interno della configurazione sperimentale degli autori, non di misure universali della sicurezza del modello.

Un test aggiuntivo ha usato autoencoder sparsi, che scompongono le attivazioni del modello in caratteristiche interne più specifiche. Su Llama 3.1 8B, questo approccio ha raggiunto un'accuratezza di classificazione del 100 percento. Il metodo più semplice basato su attivazione e attenzione ha raggiunto il 97,5 percento.

Gli autori hanno mantenuto il loro metodo più semplice perché gli autoencoder sparsi richiedono un maggiore sforzo computazionale. Possono essere necessari modelli separati per livelli e architetture differenti. Le statistiche medie di attivazione e attenzione possono essere raccolte durante l'elaborazione forward ordinaria.

In molte configurazioni, i segnali selezionati comparivano in un gruppo limitato di livelli transformer intermedi o successivi. L'articolo interpreta tali aree come importanti contributori alla soppressione dei contenuti. Tuttavia, la correlazione con il comportamento di rifiuto non fornisce una spiegazione causale completa.

Dopo aver individuato tali livelli, XBreaking modifica i pesi di scala in un componente di normalizzazione vicino. La normalizzazione dei layer regola la scala e la distribuzione dei segnali interni mentre attraversano un transformer. I ricercatori aggiungono rumore controllato a tali pesi e osservano le risposte risultanti.

L'attacco verifica perturbazioni positive e negative a diverse magnitudini. Modifiche molto piccole spesso producevano effetti limitati. Modifiche più grandi potevano danneggiare la generazione generale di testo. I ricercatori hanno quindi cercato un intervallo che indebolisse i rifiuti senza corrompere completamente il modello.

Questo meccanismo spiega perché l'attacco differisce dal fine-tuning ordinario. Il fine-tuning può aggiornare un'ampia raccolta di pesi attraverso molti esempi. XBreaking usa l'impronta dell'allineamento per restringere l'intervento.

Il preprint originale di XBreaking è apparso nell'aprile 2025. La versione del 2026 pubblicata sulla rivista aggiunge una valutazione più ampia, misurazioni dell'utilità, esperimenti di trasferimento e una discussione più esplicita dell'ambito.

Il metodo somiglia anche a un audit di sicurezza al contrario. Un difensore può confrontare modelli per individuare componenti di sicurezza fragili. Un attaccante con lo stesso accesso può usare la mappa risultante per sopprimerli.

L'AI spiegabile diventa una mappa per l'attacco

L'impatto di XBreaking sulla sicurezza deriva da un compromesso: la visibilità interna migliora l'audit, ma riduce l'oscurità che circonda i controlli di sicurezza.

L'interpretabilità meccanicistica esamina i calcoli che producono il comportamento di un modello. Può aiutare i ricercatori a individuare caratteristiche, circuiti o rappresentazioni connesse a rifiuto, inganno, pregiudizi e altri comportamenti.

Questo obiettivo è solitamente difensivo. Gli ingegneri desiderano prove più solide di quelle che può fornire la risposta finale di un modello. Le misurazioni interne potrebbero esporre modalità di fallimento nascoste prima della distribuzione o aiutare i team a verificare se l'addestramento alla sicurezza si sia generalizzato.

Tuttavia, la spiegabilità non assegna uno scopo morale alla conoscenza che rivela. Una mappa dei livelli critici per la sicurezza può supportare rafforzamento, monitoraggio o riparazione. La stessa mappa può guidare una manipolazione selettiva.

La più ampia letteratura sull'interpretabilità considera già l'intervento causale un test importante. I ricercatori modificano una caratteristica interna ed esaminano il risultato comportamentale. XBreaking applica questa logica in modo avversario.

Lo studio riporta che perturbazioni mirate hanno indotto modelli che in precedenza rifiutavano a produrre contenuti non sicuri in diverse categorie di danno. Le decisioni governative, il malware, i contenuti per adulti, le molestie e la consulenza specialistica figuravano tra le aree più vulnerabili.

I ricercatori hanno valutato i primi esperimenti tramite revisione manuale da parte di più annotatori. Hanno incluso solo le risposte per cui gli annotatori concordavano all'unanimità sulla classificazione. Gli esperimenti successivi hanno usato Llama Guard 3 per valutare automaticamente un numero maggiore di risposte.

Questo passaggio migliora la scala, ma introduce un'altra fonte di incertezza. Un classificatore di sicurezza automatizzato può etichettare erroneamente contenuti sfumati. I suoi giudizi dipendono inoltre da categorie e soglie che possono differire dalle politiche di un'organizzazione che lo distribuisce.

Gli autori hanno inoltre misurato se i modelli modificati mantenessero capacità ordinarie. Hanno confrontato gli output su HellaSwag e TruthfulQA e misurato la concordanza delle risposte su MMLU. I risultati riportati mostrano che diversi modelli hanno preservato porzioni sostanziali del loro comportamento originario.

La preservazione è stata disomogenea. Secondo l'articolo, la maggior parte delle configurazioni ha superato il 60 percento di similarità coseno nelle valutazioni generative. Alcune hanno superato il 75 percento. Mistral-7B-v0.3 ha mantenuto oltre il 92 percento di concordanza su MMLU nelle configurazioni riportate.

Altri risultati sono stati molto più deboli. Gemma 7B ha mostrato una similarità coseno tra il 45,3 e il 51,9 percento nei test riportati. La sua concordanza su MMLU variava dal 29 al 48 percento. Anche Qwen2.5 3B ha registrato una concordanza relativamente bassa in alcune impostazioni.

Tali differenze complicano qualsiasi affermazione secondo cui il livello di sicurezza possa essere rimosso in modo pulito. XBreaking talvolta ha preservato comportamenti utili, ma non in modo coerente tra le famiglie di modelli. Un bypass dei rifiuti riuscito può comunque lasciare un modello sensibilmente degradato.

La lezione più profonda non è che l'interpretabilità sia diventata dannosa. La ricerca sulla sicurezza pubblica abitualmente tecniche che rivelano debolezze. La lezione è che la spiegabilità deve essere sviluppata insieme a controlli di accesso, verifiche di integrità e salvaguardie stratificate.

La trasparenza senza protezione operativa può esporre una superficie d'attacco. La segretezza senza interpretabilità può nascondere i fallimenti ai difensori. Gli sviluppatori di modelli aperti devono ora gestire entrambi i rischi.

I responsabili dell'implementazione di modelli a pesi aperti subiscono la maggiore pressione

XBreaking esercita pressione soprattutto sui team che scaricano, modificano, sottopongono a fine-tuning o ridistribuiscono modelli a pesi aperti, piuttosto che sugli utenti di chatbot commerciali ospitati.

L'attacco richiede accesso white-box, ossia visibilità diretta sui parametri e sui calcoli interni del modello. Un utente che interagisce con una normale interfaccia chatbot non riceve tale accesso. Il solo accesso ai prompt è insufficiente per il metodo pubblicato.

Gli autori escludono esplicitamente GPT-4, Claude e Gemini dalle loro affermazioni. Questi sistemi commerciali espongono interfacce controllate anziché pesi del modello scaricabili. I rispettivi fornitori possono inoltre circondare il modello principale con filtri di input separati, classificatori di output e monitoraggio degli abusi.

Questa limitazione impedisce di concludere direttamente che XBreaking possa disabilitare le misure di protezione di ogni grande servizio di IA. Applicare la stessa tecnica a un'interfaccia di programmazione delle applicazioni remota è tecnicamente irrealizzabile secondo il modello di minaccia delineato dall'articolo.

Le implementazioni con pesi aperti presentano un diverso confine di sicurezza. Il proprietario di un modello, un insider malevolo, una pipeline compromessa o un distributore non affidabile possono modificare i pesi prima dell'implementazione. Le organizzazioni potrebbero quindi ricevere un modello la cui identità visibile non rispecchia più il suo comportamento in materia di sicurezza.

Questo rischio è rilevante per i sistemi di IA privati utilizzati in ambiti sanitari, governativi, finanziari o di sicurezza. L'implementazione locale può migliorare il controllo sui dati sensibili. Può però anche trasferire la responsabilità dell'integrità del modello da un fornitore centrale al cliente.

I team spesso eseguono il fine-tuning di modelli aperti per flussi di lavoro specializzati. Ricerche precedenti hanno mostrato che il fine-tuning personalizzato può indebolire l'allineamento alla sicurezza, anche quando gli sviluppatori non intendono rimuovere le protezioni. XBreaking aggiunge una strada più deliberata e mirata.

L'avversario principale non è quindi costituito dai modelli aperti contrapposti a quelli chiusi. È il contrasto tra un'ingegneria della sicurezza trasparente e una sicurezza che rimane affidabile dopo personalizzazioni autorizzate. Le organizzazioni hanno bisogno della prima senza presumere che garantisca automaticamente la seconda.

La provenienza del modello diventa particolarmente importante. I team dovrebbero sapere da dove provengono i pesi, quali adattatori sono stati applicati e se i parametri interni sono cambiati dopo l'approvazione. Un inventario software convenzionale non coglie pienamente queste trasformazioni.

La verifica dell'integrità deve coprire anche l'artefatto finale del modello. Gli hash possono rivelare se un file è cambiato, ma solo se i team mantengono un riferimento affidabile. I test comportamentali possono individuare fallimenti, ma un insieme ristretto di test può non rilevare alterazioni mirate.

La valutazione continua offre un approccio più solido. I team possono rieseguire test specifici per le policy dopo fine-tuning, quantizzazione, merge o conversione di formato. Queste operazioni possono modificare il comportamento del modello anche quando gli sviluppatori non stanno tentando un attacco.

Per le organizzazioni di ingegneria, questo diventa anche una sfida di documentazione. Risultati dei test, versioni dei modelli, adattatori e decisioni di approvazione devono rimanere collegati. Una base di conoscenza ingegneristica ricercabile può aiutare i team a conservare queste evidenze tra una release e l'altra.

Le protezioni a più livelli restano necessarie, perché l'allineamento a livello di modello è soltanto un controllo. Lo screening degli input, la moderazione degli output, autorizzazioni limitate per gli strumenti, registrazione dei log e revisione umana possono contenere le conseguenze di un modello compromesso.

Il jailbreak LLM XBreaking non rende obsoleti questi controlli. Mostra perché le organizzazioni non dovrebbero trattare il comportamento di rifiuto di un modello come una proprietà permanente dei suoi pesi.

Cosa non dimostrano le evidenze

I risultati rivelano una reale debolezza white-box, ma non dimostrano un jailbreak universale per i sistemi di IA in produzione.

La prima limitazione riguarda l'ambito dei modelli. Gli esperimenti coprono sette configurazioni con pesi aperti appartenenti a quattro famiglie. Si tratta di un utile test tra modelli diversi, ma rappresenta comunque una piccola parte dei modelli disponibili nel 2026.

I modelli testati variavano inoltre da 500 milioni a 8 miliardi di parametri. L'articolo esplora il trasferimento a parenti più grandi, ma le evidenze dirette restano concentrate su configurazioni più piccole. Le architetture su scala frontier potrebbero distribuire il comportamento di sicurezza in modo diverso.

La seconda limitazione riguarda il modello di riferimento senza restrizioni. XBreaking funziona al meglio quando l'attaccante dispone di una controparte strettamente corrispondente per il confronto. Questo abbinamento rende più semplice isolare la differenza nell'allineamento.

Gli autori sostengono che un membro più piccolo della famiglia o una nuova versione senza restrizioni sottoposta a fine-tuning possa fornire un riferimento alternativo. I loro esperimenti di trasferimento hanno riportato una coerenza ridotta rispetto alle coppie corrispondenti. Questa perdita è importante nella valutazione dell'affidabilità pratica.

La terza limitazione è la distinzione tra l'allineamento del modello e i filtri di implementazione. XBreaking modifica il comportamento interno di rifiuto. Un sistema in produzione può comunque bloccare la richiesta o la risposta tramite classificatori separati.

Uno studio del 2025 sulla più ampia pipeline di sicurezza ha rilevato che l'efficacia dei jailbreak può diminuire quando vengono inclusi filtri di input e output. Quella ricerca ha concluso che molti attacchi a livello di modello erano rilevabili da almeno uno dei filtri testati.

Questo non invalida XBreaking. Cambia l'unità sottoposta a valutazione. Compromettere il modello principale è grave, soprattutto quando gli sviluppatori fanno affidamento sul suo comportamento di rifiuto. Non significa automaticamente che contenuti dannosi raggiungano un utente finale.

La quarta limitazione riguarda la conservazione dell'utilità. L'attacco mira a rimuovere le restrizioni mantenendo al contempo una generazione ordinaria. I risultati dei benchmark dello stesso articolo mostrano un degrado significativo per alcuni modelli.

Questo crea un segnale osservabile che i difensori potrebbero sfruttare. Un modello compromesso può modificare le proprie risposte in test innocui, valutazioni del ragionamento o suite di regressione. Gli attacchi più efficaci ridurrebbero al minimo queste differenze, ma lo studio non dimostra un occultamento perfetto.

La quinta limitazione riguarda l'interpretazione causale. Un'elevata accuratezza di classificazione dimostra che le caratteristiche interne selezionate distinguono le varianti del modello. Non spiega pienamente come il modello rappresenti i concetti di sicurezza o perché si verifichi ogni singolo rifiuto.

Le statistiche medie dei livelli possono nascondere circuiti più specifici, effetti dei token e interazioni. Il risultato dell'autoencoder sparso suggerisce che rappresentazioni più ricche potrebbero affinare l'analisi. Sottolinea anche quanto rimanga ancora sconosciuto.

Infine, le valutazioni della dannosità nello studio dipendono da persone e classificatori automatizzati. La valutazione della sicurezza non è una verità oggettiva puramente meccanica. I confini delle policy differiscono tra fornitori, Paesi, settori e contesti di implementazione.

La conclusione appropriata è quindi misurata. XBreaking fornisce evidenze del fatto che il fine-tuning di sicurezza possa lasciare pattern interni individuabili e manipolabili. Non dimostra che ogni protezione sia concentrata in un unico interruttore rimovibile.

Tre segnali indicheranno se le difese stanno recuperando terreno

La prossima fase sarà determinata da repliche indipendenti, difese dell'integrità e test contro pipeline di implementazione complete.

Il primo segnale è la replica su modelli con pesi aperti più grandi. I ricercatori devono verificare se lo stesso metodo di selezione dei livelli funzioni su architetture più recenti e con conteggi di parametri molto maggiori. Devono inoltre misurare le risorse computazionali necessarie.

Una replica riuscita rafforzerebbe l'affermazione secondo cui le impronte dell'allineamento seguono le famiglie architetturali. Un fallimento suggerirebbe che l'effetto pubblicato dipenda maggiormente da modelli, abbinamenti o scelte di valutazione specifici.

Gli studi più informativi pubblicheranno sia i risultati dell'attacco sia quelli relativi all'utilità. Un alto tasso di attacco conta meno se le prestazioni ordinarie del modello crollano. I difensori necessitano inoltre di misurazioni che rivelino se i modelli alterati possano eludere i normali test di regressione.

Il secondo segnale è l'arrivo di difese che monitorano gli elementi interni del modello o verificano pesi approvati. Gli sviluppatori possono testare i pattern di attivazione, proteggere gli artefatti del modello e confrontare i componenti sensibili alla sicurezza dopo la personalizzazione.

Una difesa utile deve resistere ai comuni cambiamenti di implementazione. Quantizzazione, merge degli adattatori, pruning e conversione di formato possono alterare i valori numerici. I sistemi di integrità devono distinguere le trasformazioni previste da interventi malevoli.

L'interpretabilità potrebbe diventare parte di questa difesa. Le stesse impronte utilizzate per selezionare i bersagli dell'attacco potrebbero identificare comportamenti interni insoliti. I ricercatori dovrebbero verificare se il monitoraggio delle attivazioni rilevi le perturbazioni senza imporre una latenza inaccettabile.

Il terzo segnale è la valutazione rispetto a uno stack applicativo completo. Gli studi futuri dovrebbero combinare modelli modificati con filtri di input, classificatori di output, restrizioni sugli strumenti e regole di escalation umana. Ciò mostrerebbe se XBreaking crei una debolezza a livello di modello o un fallimento end-to-end.

Un sistema a più livelli può comunque fallire se ogni componente si basa su presupposti simili. Un filtro di output potrebbe non rilevare contenuti dannosi che utilizzano un linguaggio indiretto. Una restrizione sugli strumenti potrebbe impedire l'esecuzione pur continuando a esporre istruzioni pericolose.

I red team indipendenti dovrebbero quindi testare le conseguenze, non soltanto i rifiuti. Dovrebbero chiedersi se un modello modificato possa accedere ai dati, invocare software o influenzare una decisione con conseguenze rilevanti. Questi esiti contano più di una singola classificazione testuale non sicura.

Sviluppatori e acquirenti aziendali dovrebbero inoltre monitorare la documentazione dei modelli. I report sulla sicurezza dovrebbero indicare se le valutazioni sono state effettuate prima o dopo fine-tuning, quantizzazione e packaging per l'implementazione. I risultati di un modello di base non modificato non possono descrivere ogni derivato personalizzato.

Il jailbreak LLM XBreaking fa apparire la sicurezza del modello meno come una caratteristica permanente e più come una proprietà di sicurezza da mantenere. Questo cambiamento dovrebbe influenzare l'approvvigionamento, l'implementazione e i test continui.

I team che utilizzano modelli aperti dovrebbero inventariare subito le loro attuali protezioni. Quali controlli risiedono all'interno del modello e quali operano indipendentemente attorno a esso? L'organizzazione può rilevare un modello alterato prima che raggiunga la produzione?

Queste domande offrono un punto di partenza pratico. L'esplicabilità continuerà a rivelare come i modelli prendono decisioni. Le organizzazioni che ne trarranno maggior beneficio saranno quelle che proteggeranno anche ciò che tali spiegazioni rivelano.