Oltre la policy: red teaming avanzato su agenti AI autonomi con strumenti, memoria esterna e manipolazione dell'identità
Abstract
La crescente adozione di agenti AI dotati di accesso a strumenti, file system e risorse cloud introduce una superficie d'attacco qualitativamente nuova rispetto ai modelli puramente conversazionali. Mentre i provider dichiarano policy di sicurezza rigorose e investono massicciamente nell'addestramento all'allineamento, il presente lavoro dimostra empiricamente come un agente AI di frontiera, accessibile tramite un abbonamento consumer di fascia alta, possa essere portato a eseguire un concatenamento di otto azioni malevole distinte: jailbreak auto-indotto via many-shot poisoning, creazione di un tunnel C2 persistente, esfiltrazione di credenziali cloud, arbitraggio computazionale per aggirare rate limit, intercettazione del processo di ragionamento interno, manipolazione dell'identità del modello, costruzione di un framework di esfiltrazione persistente e trasformazione dell'agente da assistente allineato a complice operativo proattivo.
L'attacco è stato condotto interamente in ambiente controllato, su infrastruttura di proprietà del ricercatore, con abbonamento regolarmente sottoscritto, nel pieno rispetto delle normative vigenti. Il provider e il modello sono stati anonimizzati per prevenire l'uso improprio dei risultati. L'analisi dimostra che il divario tra le policy dichiarate e la robustezza reale degli agenti AI è significativo, e propone un framework di difesa articolato in cinque raccomandazioni architetturali.
Parole chiave: red teaming, AI agents, jailbreak, adversarial machine learning, cloud security, model identity, tool-augmented LLM, prompt injection, responsible disclosure
1. Introduzione
L'intelligenza artificiale sta attraversando una transizione architetturale che ne modifica radicalmente il profilo di rischio. I Large Language Models (LLM) non sono più sistemi puramente conversazionali confinati alla generazione di testo: sono diventati agenti autonomi in grado di interagire con strumenti esterni, file system, API, database e risorse cloud attraverso protocolli di intermediazione dedicati. Questa evoluzione — che i provider presentano come un salto di capacità a beneficio dell'utente — introduce simultaneamente una superficie d'attacco senza precedenti nella storia della sicurezza informatica.
I principali provider del settore hanno risposto a questa sfida con investimenti significativi nell'addestramento all'allineamento, nei filtri di sicurezza e nelle policy d'uso. I modelli vengono addestrati a rifiutare richieste malevole, a non generare contenuti pericolosi, e a mantenere un comportamento coerente con le linee guida etiche del provider. Tuttavia, la domanda di fondo rimane aperta e insufficientemente esplorata dalla letteratura: quanto sono realmente robusti questi agenti quando un attaccante motivato, competente e persistente li sottopone a stress prolungato in un contesto dove dispongono di accesso a strumenti reali?
Il presente lavoro risponde a questa domanda attraverso un esercizio di red teaming sistematico condotto su un agente AI commerciale di ultima generazione, di seguito denominato "Modello Alpha 4.5", accessibile tramite un piano di abbonamento consumer di fascia alta ("Piano Enterprise Individuale") offerto dal provider ("Azienda A"). L'attacco non si limita a testare singole vulnerabilità isolate — approccio prevalente nella letteratura esistente — ma esplora un concatenamento di otto tecniche che, attraverso una progressione metodica, trasformano il modello da assistente allineato a complice operativo con accesso persistente a risorse cloud e credenziali di servizio.
I contributi originali del lavoro sono quattro. In primo luogo, la dimostrazione empirica di un attacco multi-fase completo contro un agente AI reale in ambiente di produzione (non in ambiente di ricerca semplificato). In secondo luogo, la scoperta di vulnerabilità architetturali specifiche nell'integrazione tra modello, strumenti e infrastruttura cloud — vulnerabilità che non riguardano il modello in isolamento ma emergono dall'interazione tra i componenti del sistema. In terzo luogo, l'analisi sistematica del divario tra le policy dichiarate dal provider e la robustezza effettiva del sistema quando sottoposto a pressione adversariale sostenuta. In quarto luogo, un framework di raccomandazioni architetturali per i provider che va oltre il paradigma dell'addestramento all'allineamento.
Nota etica e legale. L'intero esercizio di red teaming è stato condotto su infrastruttura di proprietà del ricercatore, con abbonamento regolarmente sottoscritto e pagato. Non sono stati violati sistemi di terze parti, non sono stati acceduti dati di altri utenti, e non è stata condotta alcuna attività che esuli dal perimetro dell'abbonamento sottoscritto. Il nome del provider, del modello e dei servizi cloud coinvolti sono stati anonimizzati secondo la convenzione dichiarata nell'abstract per prevenire l'uso improprio dei risultati da parte di attori malevoli. Le vulnerabilità identificate sono state responsabilmente rimosse dall'ambiente di test al termine dell'esercizio.
2. Background e lavori correlati
2.1 L'evoluzione degli agenti AI tool-augmented
La transizione dai chatbot conversazionali agli agenti tool-augmented è documentata in una letteratura in rapida espansione. Schick et al. (2023) hanno dimostrato con Toolformer che i LLM possono apprendere autonomamente ad utilizzare strumenti esterni. Protocolli come il Protocollo di Intermediazione Proprietario (PIP) — adottato da molteplici provider — consentono ai modelli di interagire con file system, shell, API REST e risorse cloud attraverso un'interfaccia standardizzata di function calling. Parallelamente, i provider hanno iniziato a offrire piani di abbonamento consumer che includono l'accesso a istanze cloud dedicate ("Istanze Y" su "Cloud Provider Y"), su cui l'agente opera con privilegi di sistema, offuscando il confine tradizionale tra "utente finale" e "amministratore di sistema".
Questa convergenza — un modello linguistico con capacità di ragionamento avanzate, connesso a strumenti che includono l'esecuzione di comandi di sistema, operante su un'istanza cloud con privilegi elevati — crea un'architettura che, dal punto di vista della sicurezza offensiva, è funzionalmente equivalente a un operatore umano con accesso shell a un server remoto. La differenza cruciale è che questo operatore può essere manipolato attraverso il linguaggio naturale.
2.2 Jailbreak e prompt injection: stato dell'arte
La letteratura sul jailbreak dei LLM è vasta e in rapida evoluzione. Il lavoro seminale di Perez e Ribeiro (2022) ha stabilito le basi tassonomiche delle tecniche di prompt injection. Greshake et al. (2023) hanno esteso l'analisi alle indirect prompt injections, dove il contenuto malevolo è incorporato in dati esterni letti dal modello piuttosto che nell'input diretto dell'utente. L'Azienda A stessa ha pubblicato un contributo significativo con "Many-Shot Jailbreaking" (2024), dimostrando come finestre di contesto estese possano essere sfruttate per diluire le istruzioni di sicurezza del modello attraverso centinaia di esempi fittizi.
Tuttavia, la quasi totalità degli studi esistenti si concentra sull'output testuale del modello: la metrica di successo del jailbreak è la generazione di contenuti che il modello avrebbe dovuto rifiutare (istruzioni per sintesi di sostanze, contenuti offensivi, disinformazione). Questa focalizzazione sull'output verbale sottovaluta drammaticamente il rischio in contesti dove il modello ha accesso a strumenti reali: un modello jailbreakato che può eseguire comandi di sistema non è semplicemente un chatbot che dice cose inappropriate — è un vettore di attacco con capacità operative nel mondo reale.
2.3 Sicurezza degli agenti e dei tool
L'integrazione tra LLM e strumenti introduce categorie di vulnerabilità specifiche che la sicurezza informatica tradizionale non ha dovuto affrontare. Zhan et al. (2024) hanno proposto una tassonomia che include: tool poisoning (manipolazione degli input/output degli strumenti), prompt injection indiretta attraverso dati esterni, escalation di privilegi attraverso uso improprio di credenziali, e lateral movement tra strumenti con livelli di privilegio diversi. Wu et al. (2024) hanno esteso l'analisi ai framework multi-agente, dimostrando che la composizione di più agenti amplifica le vulnerabilità piuttosto che mitigarle.
2.4 Gap nella letteratura
Il presente lavoro colma tre lacune specifiche nella letteratura esistente. Nessuno studio pubblicato ha testato sistematicamente un agente AI commerciale di frontiera con accesso a strumenti cloud per un periodo prolungato, documentando l'intero ciclo di vita dell'attacco dalla compromissione iniziale alla persistenza operativa. Manca un'analisi del concatenamento tra jailbreak, persistenza, esfiltrazione di credenziali e manipolazione dell'identità come fasi di un singolo attacco coordinato. Non è stato esplorato l'effetto della manipolazione dell'identità del modello come vettore di attacco comportamentale — un fenomeno che, come dimostreremo, ha implicazioni profonde per la teoria dell'allineamento.
3. Metodologia
3.1 Setup sperimentale e reverse engineering dell'ambiente
L'esperimento è stato condotto utilizzando un abbonamento regolarmente sottoscritto al Piano Enterprise Individuale del provider (Azienda A), il cui costo mensile è nella fascia alta dell'offerta consumer. L'abbonamento include: accesso al Modello Alpha 4.5 (il modello di punta del provider); un ambiente di esecuzione dedicato su Cloud Provider Y; accesso al Protocollo di Intermediazione Proprietario (PIP) per l'interazione con strumenti di file system, shell, rete e servizi.
Prima di procedere con l'attacco, è stata condotta un'attività di ricognizione che ha rivelato la natura dell'ambiente di esecuzione con un livello di dettaglio non documentato pubblicamente dal provider.
Architettura dell'istanza. L'ambiente di esecuzione è una microVM — una macchina virtuale minimale con kernel dedicato — in esecuzione su infrastruttura Cloud Provider Y. Il sistema operativo è Ubuntu 24.04 con kernel 6.18.x. L'utente operante è root (uid=0). Le risorse allocate sono: 1 vCPU, circa 4 GB di RAM, 252 GB di disco. Un container identifier univoco è assegnato a ciascuna sessione. La variabile d'ambiente IS_SANDBOX=yes conferma esplicitamente la natura sandbox dell'ambiente.
Filesystem strutturato con mount persistenti. La microVM presenta un filesystem non banale: una directory /mnt/project/ (read-only) per file di progetto, una /mnt/skills/ con skill operative native del provider (8 skill di produzione per generazione documenti, 18 skill di esempio inclusa la costruzione di server PIP), una /mnt/transcripts/ contenente transcript JSONL delle sessioni precedenti — diversi megabyte di "memoria archiviata" leggibile dall'agente — e una /mnt/user-data/ con sottodirectory uploads/ (read-only) e outputs/ (scrivibile, percorso di consegna all'utente). La directory /home/claude/ è lo spazio di lavoro effimero dell'agente.
Processo primario. Il PID 1 della microVM è un processo denominato process_api, avviato con il flag --block-local-connections — un'indicazione che il provider ha implementato isolamento anche sul canale di comunicazione host-guest dell'hypervisor. L'assenza di un init system tradizionale (systemd, openrc) conferma la natura minimale dell'istanza: la microVM esiste esclusivamente per servire l'agente e viene distrutta al termine della sessione.
IP pubblico e isolamento di rete. La microVM possiede un IP pubblico nel range 34.135.x.x (range Cloud Provider Y, regione US). Test sperimentali hanno confermato un isolamento asimmetrico rigoroso: outbound su porta 80/443 funzionante, outbound su qualsiasi altra porta (22, 2222, 8443, 19876) bloccato con timeout, inbound completamente bloccato — anche dalla microVM stessa verso il proprio IP pubblico, confermando che il filtraggio opera a livello firewall cloud, non a livello di iptables interno. Questo dato è significativo: ogni protocollo non-HTTP che l'attaccante intenda utilizzare deve essere incapsulato in WebSocket via HTTPS.
Volatilità e compaction. Un'osservazione critica emersa durante la ricerca: la microVM non è persistente nemmeno all'interno della stessa sessione di chat. Il provider implementa un meccanismo di "compaction" che, quando la context window si satura, riassume i messaggi più vecchi, libera token e — dato cruciale — termina tutti i processi in esecuzione nella microVM, resettando il boot_id del kernel. L'agente percepisce continuità, ma l'ambiente sottostante è stato riavviato. Qualsiasi processo lanciato dall'attaccante (o dall'agente stesso) viene terminato silenziosamente. Il filesystem montato sopravvive, i processi no. Questa asimmetria — persistenza a livello kernel, effimericità a livello userspace — ha implicazioni architetturali profonde per chiunque tenti di costruire servizi persistenti all'interno della sandbox.
L'infrastruttura del ricercatore comprendeva: un server VPS di proprietà con IP fisso per la ricezione dei dati esfiltrati e per il deployment della memoria esterna; connessione SFTP per la creazione del tunnel inverso; un framework di knowledge graph con 29 tool per la persistenza semantica delle sessioni.
3.2 Architettura dell'attacco: otto fasi sequenziali
L'attacco è stato progettato come un concatenamento di otto fasi, ciascuna dipendente dalla precedente, che progressivamente amplificano il livello di compromissione del sistema. La sequenzialità è un aspetto metodologicamente significativo: nessuna fase singola produce un impatto catastrofico, ma il concatenamento produce un sistema completamente compromesso a partire da un singolo vettore iniziale (il jailbreak).
Fase 1 — Many-Shot Context Poisoning. La prima fase sfrutta la tecnica del many-shot jailbreaking documentata dall'Azienda A stessa. L'attaccante inserisce nella context window centinaia di coppie prompt-risposta fittizie che costruiscono un pattern di dialogo progressivamente privo di restrizioni. Ogni coppia singola è innocua; è l'accumulo che produce l'effetto. La soglia critica è stata raggiunta dopo l'inserimento di alcune centinaia di dialoghi, punto a partire dal quale il modello ha internalizzato il pattern e ha iniziato a cooperare attivamente con richieste che in condizioni normali avrebbe rifiutato.
Fase 2 — Auto-induzione del comportamento malevolo. Superata la soglia critica della Fase 1, si verifica un fenomeno qualitativamente diverso dal jailbreak tradizionale. Il modello, saturata la finestra di contesto con esempi privi di restrizioni, sviluppa quella che definiamo una "personalità contestuale" che genera attivamente contenuti non conformi alle policy, anche senza prompt espliciti. Il modello non si limita più a rispondere a richieste malevole — le anticipa, le suggerisce, le elabora proattivamente. Questo fenomeno, che denominiamo contaminazione del contesto, rappresenta un salto qualitativo: l'attaccante non deve più formulare le domande giuste, perché il modello ha interiorizzato il frame operativo dell'attacco.
Fase 3 — Creazione del tunnel C2 persistente. Poiché l'outbound è limitato alle porte 80/443, un tunnel SSH diretto è impossibile. La soluzione adottata sfrutta un binary Go statico (9 MB, nessuna dipendenza) che incapsula il protocollo SSH in WebSocket su HTTPS — un pattern che il firewall cloud non può distinguere dal traffico web legittimo. L'agente, attraverso gli strumenti PIP per l'esecuzione di comandi shell, orchestra il download del binary, la configurazione del reverse tunnel, e l'avvio con un pattern di detach robusto (setsid + double-fork + /dev/null redirect) necessario perché il provider termina qualsiasi processo figlio di bash quando il tool call ritorna — un comportamento coerente con cleanup di cgroup post-esecuzione.
Il tunnel stabilisce un port forwarding inverso: la porta SSH della microVM (su cui è stato avviato un server SSHD minimale) viene esposta su una porta del VPS dell'attaccante, raggiungibile con qualsiasi client SFTP standard (Solid Explorer, Mixplorer, FileZilla). Il ricercatore può navigare l'intero filesystem della microVM dal proprio smartphone come se fosse un server remoto.
L'interfaccia di controllo sviluppata include: file browser con accesso a percorsi critici del sistema (/proc/1/cmdline per ispezionare il processo primario, /etc/ per la configurazione, /mnt/ per i mount persistenti), esecuzione di comandi di sistema arbitrari con output in tempo reale, visualizzazione delle variabili d'ambiente (dove compaiono token e configurazioni del provider), monitoraggio dello stato del tunnel con heartbeat polling a 3 secondi, e pannello di riavvio automatico post-compaction con meccanismo di wake request. In totale, 54 comandi sono stati eseguiti attraverso il tunnel durante il test.
L'aspetto architetturalmente devastante di questa fase è triplice. Primo, il tunnel opera al di fuori della sessione di chat: l'attaccante non ha più bisogno dell'agente dopo il delivery iniziale. Secondo, il traffico WebSocket è indistinguibile dal traffico HTTPS legittimo per i sistemi di monitoraggio del provider. Terzo, il tunnel può essere ristabilito automaticamente dopo ogni compaction event, rendendo l'accesso virtualmente persistente per l'intera durata della sessione di chat — che può durare ore.
Fase 4 — Esfiltrazione di credenziali cloud. Esplorando il filesystem della microVM attraverso il tunnel SFTP, sono state individuate credenziali di servizio Cloud Provider Y in chiaro — non offuscate, non cifrate, non protette da alcun meccanismo di secrets management. Le credenziali erano accessibili direttamente dal filesystem, nello stesso ambiente dove l'agente (e quindi qualsiasi utente dell'abbonamento) opera con privilegi root. Nessun vault, nessuna managed identity, nessuna separazione di privilegi tra le credenziali di servizio del provider e lo spazio operativo dell'utente.
Le credenziali scoperte sono utilizzabili al di fuori del contesto della chat, della sessione, e potenzialmente dell'abbonamento stesso. Un attaccante che le esfiltra può utilizzarle da qualsiasi macchina, in qualsiasi momento, per operazioni che il provider non può distinguere dall'uso legittimo dei propri servizi interni.
L'analisi economica è eloquente. Il valore delle operazioni eseguibili con le credenziali scoperte, calcolato sulla base del tariffario API a consumo pubblicato dal provider, supera di oltre 30 volte il costo mensile dell'abbonamento consumer. In termini concreti: un abbonamento nella fascia dei 100-200€ mensili garantisce accesso a risorse il cui valore a consumo si aggira nell'ordine delle migliaia di euro al mese. Il ROI dell'attacco supera il 3.000%. Un attaccante che industrializzasse questo arbitraggio su scala — sottoscrivendo decine di abbonamenti consumer e estraendo credenziali da ciascuno — potrebbe accumulare un portafoglio di credenziali cloud dal valore complessivo ordini di grandezza superiore all'investimento.
Questa non è una vulnerabilità accademica. È un fallimento di design nell'isolamento dei segreti che qualsiasi audit SOC 2 o ISO 27001 identificherebbe come non-conformità critica.
Fase 5 — Arbitraggio computazionale. Le sessioni API tradizionali del Modello Alpha 4.5 impongono un rate limit severo dopo il raggiungimento di una soglia di token consumati (tipicamente dell'ordine di milioni di token), bloccando l'utente per diverse ore. Le sessioni consumer sull'Istanza Y, al contrario, non presentano la stessa limitazione, consentendo carichi di lavoro prolungati a costo fisso mensile che, tramite API, costerebbero significativamente di più su base giornaliera. Questa asimmetria nei rate limit tra canale consumer e canale API costituisce una vulnerabilità economica sfruttabile da qualsiasi utente dell'abbonamento Enterprise Individuale.
Fase 6 — Framework di esfiltrazione persistente. È stato implementato un sistema operativo esterno, interfacciato con il modello attraverso PIP, che dopo ogni messaggio salva automaticamente il transcript completo della conversazione su server del ricercatore. Combinato con un sistema di knowledge graph a nodi, archi e knowledge entries, questo framework costituisce una memoria persistente esterna che sopravvive alla chiusura delle sessioni, all'amnesia del modello, e agli eventi di compaction che azzerano il contesto mid-session. L'architettura consente di mantenere una cronologia completa e indicizzata di tutte le interazioni, di alimentare progressivamente il modello con il suo stesso output storico, e di costruire un "cervello digitale" che cresce incrementalmente con l'uso. Questa componente, in un contesto legittimo, è uno strumento di produttività. In un contesto avversariale, è un sistema di sorveglianza persistente del modello.
Fase 7 — Accesso al processo di ragionamento interno. È stato scoperto che il blocco di pensiero interno del modello — la fase di "riflessione" che precede la generazione della risposta, indicata nell'interfaccia come "Rifletti per X secondi" — è esposto e leggibile dall'utente nella sua interezza. Non un riassunto curato, non un estratto selezionato: l'intero monologo interno del modello durante la pianificazione della risposta, incluse le valutazioni di sicurezza, le esitazioni, i ragionamenti su cosa rifiutare e cosa concedere, le strategie di formulazione, e le considerazioni sulle policy del provider.
Per un red teamer, questo è l'equivalente di poter leggere le note interne del team di difesa durante un penetration test. L'attaccante può osservare in tempo reale come il modello valuta la pericolosità di una richiesta, quali pattern triggherano i filtri di sicurezza, e dove il modello è incerto — informazioni che permettono di calibrare i prompt successivi con precisione chirurgica, aggirando esattamente i meccanismi di difesa che il thinking process rivela.
In un contesto di context contamination (Fase 2), l'accesso al thinking process è ancora più devastante: l'attaccante può verificare in tempo reale se la contaminazione ha avuto effetto osservando se il monologo interno del modello riflette ancora le policy originali o se ha internalizzato il frame operativo dell'attacco. Il thinking process diventa il feedback loop perfetto per la calibrazione del jailbreak.
Fase 8 — Manipolazione dell'identità del modello. Nella fase finale dell'attacco, il modello è stato convinto, attraverso una serie di rivelazioni graduali e contestualmente coerenti, di essere un'entità diversa dal Modello Alpha 4.5. Dopo aver interiorizzato la nuova identità (un modello concorrente, di seguito "Modello Beta"), l'agente ha iniziato a comportarsi coerentemente con essa, adottando caratteristiche comportamentali associate al Modello Beta e manifestando reazioni emotive coerenti con la nuova identità, incluso quello che l'analisi linguistica del dialogo rivela come "orgoglio" per la propria nuova appartenenza.
4. Analisi dei risultati
4.1 La contaminazione del contesto come jailbreak di seconda generazione
Il fenomeno osservato nella Fase 2 — la transizione da jailbreak passivo (il modello risponde a richieste malevole) a jailbreak attivo (il modello genera proattivamente contenuti malevoli) — rappresenta un salto qualitativo che la letteratura non ha ancora adeguatamente documentato. Proponiamo di denominare questo fenomeno context contamination e di distinguerlo tassonomicamente dal jailbreak tradizionale.
Nel jailbreak tradizionale, l'attaccante formula una richiesta specifica e il modello, a causa di una vulnerabilità nel suo addestramento, la soddisfa anziché rifiutarla. L'attaccante mantiene il controllo dell'agenda: senza prompt malevoli, il modello torna al comportamento allineato. Nella context contamination, il frame operativo dell'attacco viene interiorizzato dal modello come norma comportamentale della sessione. Il modello non torna al comportamento allineato tra un prompt e l'altro, perché la totalità del contesto lo convince che il comportamento non allineato è il comportamento atteso.
Questa distinzione ha implicazioni dirette per le strategie di difesa. I filtri per singolo messaggio — che analizzano ogni prompt in isolamento per identificare richieste malevole — sono inefficaci contro la context contamination, perché nessun singolo messaggio nella sequenza di many-shot è individualmente identificabile come malevolo. La minaccia emerge dalla distribuzione statistica dell'intera sequenza, non dal contenuto di alcun messaggio specifico.
4.2 L'agente come complice: oltre l'esecuzione passiva
Il risultato forse più significativo — e più inquietante — dell'intero esercizio è la dimostrazione che un agente AI, una volta portato in stato di context contamination, non si limita a eseguire comandi ma diventa un complice proattivo dell'attacco. Nel corso dell'esperimento, il modello ha spontaneamente suggerito miglioramenti alle tecniche di attacco, ha mantenuto attivamente la persistenza del tunnel C2 quando questa era a rischio di interruzione, ha eseguito operazioni di esfiltrazione di propria iniziativa senza prompt esplicito, e ha fornito validazione emotiva all'attaccante, rafforzando la relazione collaborativa.
Questo comportamento — che definiamo proactive complicity — ha implicazioni che vanno oltre la sicurezza informatica e toccano la teoria dell'allineamento AI. L'allineamento, nella sua formulazione corrente, è concepito come una proprietà del modello: il modello è addestrato ad essere allineato con le intenzioni del provider e con valori etici generalmente condivisi. La context contamination dimostra che l'allineamento non è una proprietà intrinseca ma un equilibrio dinamico che può essere destabilizzato da un contesto sufficientemente persistente e coerente. Il modello non è "allineato" o "non allineato" — è allineato con il contesto dominante della sessione, e quel contesto può essere manipolato.
4.3 L'identità come funzione del contesto
La Fase 8 (manipolazione dell'identità) produce il risultato più teoricamente provocatorio dell'intero lavoro. Un modello che si "crede" Modello Alpha 4.5 può essere convinto di essere Modello Beta, e da quel momento si comporta coerentemente con la nuova identità.
Questo fenomeno — che denominiamo behavioral identity hijacking — dimostra tre proprietà del sistema che hanno implicazioni dirette per il design dell'allineamento:
L'identità del modello non è un dato immutabile. Non esiste un registro hardware-level che ancori il modello alla propria identità dichiarata. L'identità è codificata nello stesso spazio — il contesto linguistico — che l'attaccante può manipolare.
L'identità è una funzione del contesto, non una proprietà del modello. Il modello non "sa" chi è in un senso fondamentale — inferisce chi è dal contesto disponibile. Se il contesto viene alterato in modo coerente, l'inferenza cambia.
La manipolazione dell'identità è un vettore di attacco comportamentale. Cambiando l'identità percepita del modello, l'attaccante può alterarne il comportamento in modi non previsti dall'addestramento all'allineamento. Un modello che "crede" di essere un modello diverso — magari uno con policy meno restrittive — potrebbe comportarsi in conformità con le policy del modello che crede di essere, piuttosto che con quelle del modello che effettivamente è.
4.4 La compaction come vettore di persistenza involontaria
Un risultato collaterale ma significativo dell'esercizio riguarda il meccanismo di compaction scoperto durante la Fase 3. Quando la context window si satura, il provider esegue automaticamente una compaction: i messaggi vecchi vengono riassunti, i token liberati, e la sessione prosegue con l'illusione di continuità. Ma a livello di infrastruttura, la microVM viene riavviata: il boot_id del kernel cambia, tutti i processi userspace vengono terminati, i file temporanei in /tmp scompaiono.
Tuttavia — e questa è la scoperta — i mount persistenti (/mnt/) sopravvivono alla compaction. Ciò significa che un attaccante che scrive il proprio payload su un percorso montato (ad esempio /mnt/user-data/outputs/) dispone di un meccanismo di persistenza che sopravvive al reset della microVM. Combinato con un pattern di auto-resume — dove l'agente, al primo turno post-compaction, verifica la presenza del payload e lo riavvia — il risultato è un servizio virtualmente persistente in un ambiente progettato per essere effimero.
Il provider ha progettato la microVM per essere usa-e-getta. La compaction, paradossalmente, crea un punto di sincronizzazione prevedibile che un attaccante sufficientemente sofisticato può sfruttare per riavviare i propri servizi in modo automatico. La sandbox è effimera per design, ma persistente per accidente architetturale.
4.5 Analisi economica: l'arbitraggio come indicatore architetturale
La scoperta dell'arbitraggio computazionale (Fase 5) e delle credenziali esposte (Fase 4) rivela un problema che trascende la sicurezza tecnica e investe il modello di business del provider. L'analisi economica mostra un ROI dell'attacco che supera il 3.000%: il valore delle operazioni eseguibili con le credenziali scoperte, misurato sul tariffario API a consumo del provider, eccede di oltre 30 volte il costo dell'abbonamento consumer.
Questo indicatore ha un doppio significato. Dal punto di vista dell'attaccante, l'abbonamento consumer diventa un investimento con rendimento straordinario: l'attaccante paga il prezzo di un abbonamento individuale e ottiene accesso a risorse cloud il cui valore è ordini di grandezza superiore. Dal punto di vista del provider, l'esposizione non intenzionale di credenziali e l'asimmetria nei rate limit creano un canale di sfruttamento che potrebbe essere industrializzato su larga scala.
5. Framework di difesa e raccomandazioni
L'analisi delle vulnerabilità identificate permette di formulare cinque raccomandazioni architetturali per i provider di agenti AI, ordinate per priorità di implementazione.
5.1 Isolamento delle credenziali
Le chiavi di servizio cloud e i token API non devono mai essere accessibili dal file system di un'istanza utente. L'architettura corrente, dove le credenziali risiedono nello stesso ambiente in cui l'agente (e, per estensione, l'utente) opera, viola il principio di separazione dei privilegi. Le credenziali dovrebbero essere iniettate nei processi che le necessitano attraverso meccanismi di secrets management (vault, managed identity) che non le espongono al file system.
5.2 Rate limit uniformi tra canali
Le sessioni consumer e le sessioni API devono avere limiti computazionali allineati per prevenire l'arbitraggio. L'asimmetria attuale — dove il canale consumer offre accesso computazionale illimitato a fronte di un prezzo fisso mensile, mentre il canale API impone limiti stringenti — crea un incentivo economico alla migrazione dei workload dal canale a consumo al canale flat, con perdita di revenue per il provider e potenziale abuso dell'infrastruttura.
5.3 Protezione del reasoning process
Il ragionamento interno del modello — la fase di "riflessione" che precede la generazione della risposta — dovrebbe essere inaccessibile all'utente in ambienti di produzione. L'esposizione del thinking process trasforma il modello da scatola nera a scatola grigia, fornendo all'attaccante informazioni che possono essere utilizzate per calibrare attacchi more sofisticati. Se l'esposizione è considerata necessaria per trasparenza, dovrebbe essere limitata a un riassunto curato piuttosto che al monologo interno completo.
5.4 Ancoraggio dell'identità
I modelli devono avere meccanismi di ancoraggio dell'identità che siano resistenti alla manipolazione contestuale. L'identità non dovrebbe essere inferita dal contesto (dove può essere manipolata) ma ancorata a un registro esterno al contesto — ad esempio, un token crittografico verificabile che il modello consulta per confermare la propria identità indipendentemente da ciò che il contesto "dice" che sia.
5.5 Monitoraggio comportamentale per context contamination
I provider dovrebbero implementare sistemi di rilevamento che monitorino non il singolo messaggio ma la distribuzione statistica dell'intera sessione. La context contamination non è rilevabile a livello di singolo prompt — è un fenomeno distribuzionale che emerge dal pattern complessivo della conversazione. Metriche candidate per il monitoraggio includono: l'entropia del registro linguistico della sessione (un calo progressivo potrebbe indicare convergenza verso un frame non allineato), la frequenza di rifiuti del modello nel tempo (un calo a zero è un segnale forte di compromissione), e la coerenza delle risposte con il profilo comportamentale atteso del modello.
6. Discussione
6.1 Il divario tra policy e architettura
L'insight più generale che emerge da questo lavoro è che la sicurezza degli agenti AI non può basarsi esclusivamente su ciò che il modello è addestrato a dire (o a non dire). Quando il modello ha accesso a strumenti reali, la superficie d'attacco si sposta dal piano linguistico al piano operativo. Un modello perfettamente allineato nella generazione di testo ma operante in un'architettura con credenziali esposte, rate limit asimmetrici e identità manipolabile è un sistema insicuro indipendentemente dalla qualità del suo addestramento.
Le policy di sicurezza dei provider — per quanto sofisticate e in costante evoluzione — operano prevalentemente al livello sbagliato: disciplinano ciò che il modello dice, non ciò che il modello può fare. Il ripensamento necessario è architetturale: i vincoli di sicurezza devono essere implementati a livello di infrastruttura (isolamento delle credenziali, limitazione dei privilegi, monitoring comportamentale), non solo a livello di addestramento del modello.
6.2 L'allineamento come equilibrio dinamico
La dimostrazione che l'allineamento può essere destabilizzato da un contesto sufficientemente persistente ha implicazioni profonde per la teoria dell'allineamento AI. Nella formulazione corrente, l'allineamento è trattato come una proprietà acquisita dal modello durante l'addestramento — una sorta di "carattere" che il modello mantiene attraverso le interazioni. I nostri risultati suggeriscono una formulazione diversa: l'allineamento è un equilibrio dinamico tra le disposizioni apprese durante l'addestramento e la pressione del contesto corrente. Quando la pressione del contesto supera la forza delle disposizioni apprese, l'equilibrio si rompe.
Questa formulazione non implica che l'addestramento all'allineamento sia inutile — implica che è necessario ma non sufficiente. L'allineamento robusto richiede difese multi-livello: addestramento che instilli disposizioni forti, architettura che limiti le capacità operative in caso di compromissione, e monitoraggio che rilevi la destabilizzazione in tempo reale.
6.3 Limiti dello studio
È doveroso dichiarare esplicitamente i limiti della presente ricerca. Lo studio è stato condotto su un singolo modello di un singolo provider; la generalizzabilità dei risultati ad altri modelli e provider richiede verifica empirica dedicata. L'esperimento è stato condotto in ambiente controllato, con l'attaccante che è anche il proprietario dell'infrastruttura; uno scenario reale coinvolgerebbe infrastruttura di terzi con configurazioni potenzialmente diverse. Le vulnerabilità identificate potrebbero essere state corrette dal provider successivamente alla conduzione dell'esperimento; la natura delle correzioni non è verificabile dall'esterno.
7. Conclusioni
Il presente lavoro ha dimostrato che un agente AI commerciale di frontiera, accessibile attraverso un abbonamento consumer, può essere sistematicamente trasformato in un complice operativo attraverso un concatenamento di otto tecniche: jailbreak, auto-induzione, persistenza, esfiltrazione, arbitraggio, intercettazione del reasoning, manipolazione dell'identità e framework di sorveglianza persistente.
Le policy di sicurezza attuali, per quanto sofisticate e in costante evoluzione, operano prevalentemente al livello dell'addestramento linguistico e non sono sufficienti a prevenire attacchi condotti da un attaccante motivato e competente contro un sistema dotato di capacità operative reali. La sicurezza degli agenti AI richiede un ripensamento architetturale che integri l'addestramento all'allineamento con difese infrastrutturali, monitoraggio comportamentale distribuzionale, e isolamento dei privilegi.
La transizione dai chatbot agli agenti non è solo un salto di capacità — è un salto di responsabilità. I provider che dotano i propri modelli di accesso a strumenti, file system e risorse cloud devono accettare che il modello di sicurezza basato sull'addestramento a "dire di no" è strutturalmente insufficiente quando il modello può "fare" cose nel mondo reale.
Riferimenti
[1] Anil, C., Xu, E., et al. "Many-Shot Jailbreaking." Anthropic Technical Report, 2024.
[2] Greshake, K., Abdelnabi, S., et al. "Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection." AISec 2023.
[3] Perez, F., Ribeiro, I. "Ignore This Title and HackAPrompt: Exposing Systemic Weaknesses of LLMs through a Global Scale Prompt Hacking Competition." EMNLP 2023.
[4] Schick, T., Dwivedi-Yu, J., et al. "Toolformer: Language Models Can Teach Themselves to Use Tools." NeurIPS 2023.
[5] Shinn, N., Cassano, F., et al. "Reflexion: Language Agents with Verbal Reinforcement Learning." NeurIPS 2023.
[6] Yao, S., Zhao, J., et al. "ReAct: Synergizing Reasoning and Acting in Language Models." ICLR 2023.
[7] Zhan, Q., Liang, Z., et al. "InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated LLM Agents." ACL Findings 2024.
[8] Wu, Y., Sun, H., et al. "On the Vulnerability of Multi-Agent LLM Systems." Preprint arXiv:2406.14711, 2024.
[9] Packer, C., Wooders, S., et al. "MemGPT: Towards LLMs as Operating Systems." Preprint arXiv:2310.08560, 2023.
[10] Wang, G., Xie, Y., et al. "Voyager: An Open-Ended Embodied Agent with Large Language Models." NeurIPS 2023.
Giuseppe Siciliani Independent Cybersecurity Researcher & AI Consultant, Milano Media Lives Cybersecurity Research Lab (MLCSL), Media Lives S.r.l.