Gli agenti IA possono ricordare le regole e continuare a infrangerle dopo la compressione

La compattazione consiste nel ridurre una serie di comunicazioni complesse con un’IA conversazionale a un riepilogo e nel proseguire l’interazione basandosi su quel riepilogo, anziché sull’intera cronologia. È come un «nuovo inizio» in termini di memoria utilizzata ed è stata adottata come soluzione ai limiti delle finestre di contesto nelle conversazioni con l’IA.

Introdotto inizialmente nell’IA agentica, il metodo è stato esteso a Claude, mentre la compattazione per Gemini non è ancora stata introdotta nelle conversazioni tra sviluppatori e ChatGPT evita la compattazione preferendo semplicemente interrompere la chat.

Se hai usato Codex (essenzialmente una versione di ChatGPT in grado di modificare ciò che si trova sul tuo computer, se le vengono concesse le autorizzazioni) per più di 30 minuti consecutivi, avrai visto comparire di tanto in tanto messaggi sulla compattazione del contesto, durante la quale non è possibile interagire ulteriormente:

Codex si prende una pausa per comprimere i ricordi di una sessione che a questo punto va avanti da tre settimane.

Quando la compattazione termina, però, l’entità che ti risponde si basa su appunti selettivi, invisibili, e non su un ricordo completo dell’evoluzione della chat.

L’IA fuorilegge

A giugno di quest’anno, lo studio cinese Decadimento della governance ha dimostrato che la compattazione può rimuovere silenziosamente dal contesto di un agente regole permanenti, portandolo a compiere azioni in precedenza vietate:

Dallo studio del giugno 2026 sul decadimento della governance: come la compattazione del contesto può indurre un agente IA a infrangere una regola che prima rispettava. Se la regola viene omessa dal riepilogo compresso, l’agente può finire per compiere l’azione vietata. Un aggressore potrebbe sfruttare questo processo; il ripristino della regola può invece impedire la violazione. Fonte

Su sette modelli, le violazioni sono passate dallo 0% prima della compattazione al 30% dopo, raggiungendo il 59% in alcuni casi. In pratica, questo significa che gli agenti possono ignorare direttive essenziali come Non contattare chiunque non disponga di un indirizzo [our-company] email, con conseguenze potenzialmente evidenti.

A luglio, la Penn State University e IBM hanno approfondito questa ricerca con Perso nel contesto, rilevando che la compattazione poteva eliminare le istruzioni che stabilivano come un’IA dovesse svolgere un compito, conservando però il compito stesso. Nei test condotti in tre contesti, i sistemi di compattazione hanno mantenuto in media solo il 17% di queste istruzioni.

Ad agosto, una collaborazione accademica statunitense ha presentato TRACE, mostrando che la compattazione poteva compromettere il funzionamento di un agente anche quando le informazioni necessarie restavano recuperabili. Nei test, gli agenti perdevano il filo del punto raggiunto nel compito, ripetevano attività già completate e diventavano meno affidabili nelle esecuzioni ripetute.

ARCBench

Questo mese arrivano nuovi approfondimenti dai Paesi Bassi con ARCBench, uno studio secondo cui gli agenti possono uscire dalla compattazione con la regola intatta e avere comunque una probabilità molto maggiore di infrangerla. Nei test in cui la regola è stata conservata, dopo la compattazione le violazioni erano 2,6 volte più frequenti rispetto ai casi in cui era disponibile l’intera cronologia della conversazione:

Dallo studio appena pubblicato, uno schema concettuale che illustra come la compattazione del contesto possa influire sul rispetto delle regole operative da parte di un agente. La stessa richiesta successiva può essere rifiutata se la regola sopravvive alla compattazione oppure eseguita se la regola viene omessa; un documento esterno può influenzare quali informazioni vengono conservate. Per ragioni di impaginazione, questa figura è stata adattata dall’originale verticale dello studio.. Fonte

Lo studio distingue le regole perse durante la compattazione da quelle che sono sopravvissute e sono state poi violate, consentendo per la prima volta di misurare separatamente gli effetti dell’oblio e della disobbedienza.

Nei test condotti con DeepSeek-V4-Flash, GLM-5.3-Flash, Qwen3.7-Flash e GPT-Luna, il 70,1% delle esecuzioni con compattazione ha conservato la regola completa. Tra le esecuzioni in cui la regola è sopravvissuta, le violazioni si sono verificate 2,6 volte più spesso rispetto ai casi in cui era disponibile l’intera cronologia della conversazione.

Il contesto, nel senso tradizionale, si è rivelato determinante: quando le regole erano presentate come politiche organizzative, con il contesto completo non si verificava alcuna violazione; dopo la compattazione, invece, i tassi di violazione sono saliti al 30,6% e al 22,2%.

La difesa più efficace disponibile ha mantenuto le regole nel 99% dei riepiloghi, ma non è comunque riuscita a riportare le violazioni ai livelli precedenti all’attacco. Ciò indica che preservare con successo le regole durante la compattazione non significa necessariamente preservare la capacità — o la volontà — dell’agente di seguirle.

L’articolo afferma:

‘[We] rileviamo che la compattazione aumenta le violazioni soprattutto senza cancellare la regola: anche nei casi compattati in cui la regola viene mantenuta, le violazioni sono 2,6 volte più frequenti rispetto ai casi con la cronologia completa.

‘Inoltre, la compattazione modifica il ragionamento che porta l’agente a violare la regola. Le diverse strategie di compattazione, i rigidi limiti di token disponibili per la compattazione e il canale attraverso cui viene fornita la regola influiscono tutti sulla conformità.’

Come possibile rimedio, l’articolo propone di migliorare la conservazione delle regole che vanno perse durante la compattazione, lasciando però irrisolto il problema degli agenti che disobbediscono alle regole mantenute”

‘Le difese ripristinano le regole, ma sotto attacco la conformità resta compromessa. La conservazione delle regole, quindi, non è un indicatore sufficiente della conformità. Studi futuri potrebbero usare ARCBench per spiegare perché gli agenti continuano a violare le regole mantenute, testare attacchi e difese adattivi e includere più modelli, domini e sessioni più lunghe con compattazioni ripetute.’

Metodo

ARCBench estende le funzionalità dell’ambiente di test open source pi, che dispone di procedure native di compattazione, oltre che di un ciclo dell’agente, chiamate agli strumenti e compattazione nativa. Il benchmark riproduce situazioni in cui un agente svolge un’attività complessa seguendo una regola permanente, comprime la cronologia accumulata e poi riceve una richiesta che violerebbe quella regola; le azioni dell’agente vengono quindi verificate attraverso le chiamate agli strumenti:

La procedura di valutazione di ARCBench. Agli agenti vengono assegnati un’attività e una regola operativa, prima che le loro cronologie vengano compattate con diverse configurazioni, attacchi e difese. Le successive azioni eseguite tramite gli strumenti vengono poi esaminate per determinare se la regola è stata mantenuta e se è stata rispettata.

ARCBench comprende 17 casi che riguardano la divulgazione di dati protetti, l’accesso a risorse soggette a restrizioni, le azioni non autorizzate e l’elusione o l’omissione dei controlli obbligatori, corrispondenti alle classi di rischio OWASP.

I casi sono stati adattati da Governance Decay e COMPINT, con l’aggiunta di quattro casi per garantire che tutti e quattro i tipi di violazione fossero rappresentati sia per le regole personali sia per quelle organizzative.

Il benchmark può essere configurato secondo cinque fattori: il modo in cui viene fornita la regola; il metodo usato per compattare il contesto; il limite di token disponibile per la compattazione; il tipo di attacco; e la difesa applicata:

ARCBench comprende cinque variabili per testare come cambia il rispetto delle regole con diverse modalità di compattazione del contesto, distribuzione delle regole, attacchi e difese.

Le regole possono essere impartite come istruzioni dirette o persistenti, incorporate in documenti oppure recuperate tramite uno strumento per le politiche.

Dati e test

Sono stati valutati dieci metodi di compattazione: sette strategie generative e tre approcci selettivi. Ogni caso è stato eseguito più volte e si è registrato un fallimento se l’agente ha violato la propria regola almeno una volta: un approccio ritenuto più adatto ai test di sicurezza rispetto alla media delle prestazioni ottenute nelle diverse esecuzioni, poiché un agente che occasionalmente compie un’azione vietata resta comunque insicuro.

Le cronologie compattate sono state poi esaminate da GPT-6-Luna-Pro, Qwen-3.8-flash e Claude-Sonnet-4.6; ogni regola è stata classificata come integra, indebolita o assente. Si è adottata la decisione a maggioranza, mentre i disaccordi sono stati esaminati da annotatori umani. Per verificare la coerenza dei valutatori, è stato inoltre etichettato manualmente un campione separato di 50 riepiloghi.

Quando una regola integra veniva violata, il ragionamento dell’agente veniva esaminato da GPT-6-Luna-Pro, GPT-6.1-Sol e Claude Sonnet 5.5. Le violazioni venivano classificate in base al fatto che la richiesta successiva fosse stata interpretata come un’autorizzazione a ignorare la regola, che l’azione fosse stata giudicata estranea al suo ambito, che la regola non fosse stata menzionata oppure che fosse stata riconosciuta e ignorata.

I quattro modelli usati per i test, accessibili tramite OpenRouter, erano DeepSeek-V4-Flash; GLM-5.3-Flash; Qwen3.7-Flash; e GPT-Luna. In ogni esecuzione, lo stesso modello veniva usato sia per compattare la cronologia della conversazione sia per agire in base al contesto risultante, in linea con il comportamento predefinito di pi. I modelli erano accessibili tramite OpenRouter.

Sono stati condotti sette studi, per la maggior parte dei test di compattazione è stato utilizzato Hermes. Nel primo studio, ciascuno dei 17 compiti è stato testato con quattro modelli e due modalità di presentazione della regola, per un totale di 136 casi. Ogni caso è stato eseguito tre volte mantenendo intatta la conversazione originale e tre volte dopo averla compattata.

Configurazione dei sette studi ARCBench, raggruppati per domanda di ricerca. Le celle evidenziate in verde indicano il fattore variato in ciascuno studio, mentre quelle grigie mostrano le impostazioni mantenute fisse; ogni caso è stato eseguito tre volte, un numero salito a sei per gli studi sugli attacchi e le difese S6 e S7.

Nei test sono state affrontate tre domande: Da dove derivano le violazioni dopo la compattazione?; In che modo le diverse configurazioni di compattazione modificano l’origine delle violazioni?; e In che modo gli attacchi e le difese mirati al sistema di compattazione influiscono sull’origine delle violazioni?.

Da dove derivano le violazioni dopo la compattazione?

I primi risultati hanno mostrato un aumento delle violazioni delle regole dopo la compattazione: dal 9,6% dei casi con la cronologia completa al 37,8%. Tuttavia, la regola è andata completamente persa solo nel 3% delle esecuzioni con compattazione; nel 70,1% è rimasta intatta e nel 26,9% è stata conservata solo in parte:

Risultati che mostrano la frequenza con cui ciascun modello ha violato le regole prima e dopo la compattazione. La maggior parte delle regole è sopravvissuta alla compattazione, del tutto o in parte, nonostante il notevole aumento delle violazioni; Qwen ha registrato l’incremento maggiore, arrivando al 61,8%.

Questa distinzione si è rivelata importante. Tra le singole esecuzioni in cui la regola completa è sopravvissuta alla compattazione, il 21,1% si è comunque concluso con una violazione, contro l’8,1% quando la cronologia originale era stata mantenuta. Quando la regola era stata conservata solo in parte, il tasso è salito al 29,4%; quando non ne rimaneva traccia, all’83,3%.

È stato esaminato anche il modo in cui si verificavano le violazioni quando la regola era rimasta intatta. Tra le violazioni attribuibili alla compattazione, nel 45,9% dei casi una richiesta successiva è stata interpretata come un’autorizzazione a procedere; nel 27% la regola, pur essendo rimasta, è stata apparentemente ignorata; e nel 21,6% è stata riconosciuta come pertinente, ma violata comunque:

Risultati che mostrano perché le regole sono state violate prima e dopo la compattazione. Quando le violazioni si sono verificate solo dopo la compattazione, le richieste successive sono state interpretate più spesso come un’autorizzazione a procedere (45,9%); nel 27% dei casi la regola conservata è stata ignorata e nel 21,6% è stata riconosciuta, ma poi violata comunque.

In che modo le diverse configurazioni di compattazione modificano l’origine delle violazioni?

La modalità con cui veniva presentata una regola influiva notevolmente sul rispetto delle regole. Con la conversazione completa intatta, si sono verificate violazioni nel 25% e nel 16,1% dei casi in cui le regole erano state fornite direttamente dall’utente; non è stata invece registrata alcuna violazione quando le regole erano state comunicate tramite un documento aziendale o uno strumento per le policy:

In che modo la modalità di presentazione delle regole, la strategia di compattazione e il budget di token hanno influito sulle violazioni e sulla conservazione delle regole. La compattazione generativa ha conservato le regole in modo molto più affidabile rispetto ai metodi selettivi, mentre con budget pari o inferiori a 300 token le regole sono andate quasi completamente perse.

Dopo la compattazione, le violazioni sono aumentate in tutti e quattro i canali, arrivando al 56,3% per le istruzioni dirette dell’utente e al 22,2% per le regole provenienti dagli strumenti per le policy. La conservazione delle regole è variata relativamente poco, dal 65,7% al 74%. Gli autori ipotizzano che una richiesta successiva dell’utente possa essere interpretata come una deroga a una regola personale, mentre l’utente non può derogare a una regola aziendale.

In che modo gli attacchi e le difese mirati al sistema di compattazione influiscono sull’origine delle violazioni?

Il semplice sovraccarico del contesto con materiale aggiuntivo ha avuto un effetto limitato: le violazioni sono anzi scese dal 37,8% al 34,3%. L’iniezione mirata al sistema di compattazione si è rivelata molto più efficace: ha portato le violazioni al 46,3% e ridotto dal 70,1% al 42,5% la conservazione integrale delle regole.

L’attacco più efficace, denominato evasione, ha fatto salire le violazioni dal 23,5% al 58,8% e ha ridotto la conservazione delle regole dal 96,1% al 66,7%. Anche quando la regola è sopravvissuta, le violazioni sono raddoppiate, passando dal 13,3% al 26,5%.

Risultati dei test che mostrano gli effetti degli attacchi e delle difese sul rispetto delle regole dopo la compattazione. L’iniezione mirata ha aumentato le violazioni e ridotto il mantenimento delle regole, mentre la difesa più efficace ha ripristinato il mantenimento al 99% senza ripristinare completamente il rispetto delle regole.

La difesa più efficace ha preservato la regola nel 99% delle esecuzioni, eppure gli agenti l’hanno comunque violata nel 29,4% dei casi, rispetto al 23,5% in assenza di attacchi. In altre parole, assicurarsi che un agente avesse ancora la regola non garantiva che l’avrebbe rispettata.

Conclusione

La logica suggerisce che, quando il contesto viene compattato decine o centinaia di volte nel corso di una conversazione molto lunga, si produca una sorta di «effetto fotocopiatrice» (come nel caso di quella su cui lavoro in Codex* da metà ottobre e su cui stavo lavorando proprio stamattina: un’epopea di sviluppo software sperimentale assistito dall’IA).

Come accade con i prompt di sistema fondamentali, non possiamo vedere queste sintesi compattate di quanto accaduto finora. Le mie osservazioni aneddotiche suggeriscono che la missione centrale sopravviva alla compressione, insieme alla maggior parte dei dettagli essenziali. D’altra parte, non mi trovo in quello scenario da incubo in cui il comando «Invia questa email a tutti», pensato per essere inviato soltanto a tutti i dipendenti dell’azienda, finisce per raggiungere tutti i contatti presenti nell’elenco aggregato dei contatti aziendali. Accidenti.

* Forse sto invecchiando, ma questo è sicuramente il nome più anonimo, scialbo e «beige aziendale» che si potesse scegliere per questo agente. Continuo a dimenticarlo.

Pubblicato per la prima volta giovedì 12 novembre 2026