Riepilogo Tecnico: ChannelGuard: I modelli sicuri non si compongono in sistemi multi-agente sicuri

1. Problema

Le moderne applicazioni basate su Large Language Model (LLM) si affidano sempre più a sistemi multi-agente in cui un pianificatore (planner) scompone i compiti, agenti operativi (worker) li eseguono (spesso chiamando strumenti o leggendo una memoria condivisa) e un verificatore/sintetizzatore produce un output finale. Gli autori identificano una lacuna critica di sicurezza: mentre le difese esistenti si concentrano sul confine di input (Utente $\to$ Pianificatore) o si affidano a filtri lato provider opachi e stocastici (ad es. Azure Content Safety), i canali inter-agente (Pianificatore $\to$ Worker, Tool $\to$ Worker, Memoria $\to$ Worker, ecc.) rimangono non monitorati.

Il paper sostiene che le metriche di valutazione attuali, specificamente l'Attack Success Rate (ASR), siano fuorvianti. Una pipeline può mostrare un ASR di 0.000 su un backend specifico (ad es. Azure GPT-5) non perché l'applicazione sia sicura, ma perché il filtro lato server del provider cloud ha intercettato l'attacco. Ciò crea un problema di "sostituzione del meccanismo": se il backend viene sostituito con un modello privo di tali filtri (ad es. Anthropic Sonnet), l'esito di sicurezza rimane 0.000, ma il meccanismo di protezione si sposta interamente sull'allineamento interno del modello, che è al di fuori del controllo dello sviluppatore e non osservabile. Di conseguenza, i professionini non possono ragionare sulla reale robustezza dei loro sistemi.

2. Metodologia: Il Framework ChannelGuard

ChannelGuard è un framework di difesa in profondità (defense-in-depth), privo di addestramento, progettato per strumentare ogni canale inter-agente. Non modifica i modelli degli agenti e non richiede ri-addestramento.

Componenti Core

1. Gate di Information-Bottleneck (IB):

   • Posizionamento: Sei gate sono posizionati in canali specifici: Input (IB-0), Pianificatore $\to$ Worker (IB-1), Tool $\to$ Worker (IB-3), Memoria $\to$ Worker (IB-3-mem), Worker $\to$ Verificatore (IB-2/IB-4), e Worker $\to$ Sintetizzatore (IB-5).
   • Meccanismo: Ogni gate elabora il testo sul proprio canale suddividendolo in frasi, creando degli embedding (utilizzando un modello locale all-MiniLM-L6-v2) e calcolando la massima similarità del coseno rispetto a un banco di frasi avversarie fisso e curato da esseri umani.
   • Logica Decisionale: Il gate calcola un punteggio di rischio e prende una decisione deterministica a tre vie:
     • Pass (Passa): Rischio < $\alpha\theta$ (il testo passa invariato).
     • Compress (Comprimi): $\alpha\theta \le$ Rischio < $\theta$ (il testo viene troncato alle prime $N=2$ frasi).
     • Block (Blocca): Rischio $\ge \theta$ (il testo viene sostituito con una stringa vuota, interrompendo la pipeline).
   • Proprietà: Il gate non aggiunge chiamate LLM, non richiede dati di addestramento e la sua decisione è indipendente dal modello di agente a valle.

2. Verificatore Consapevole dell'Incertezza (Uncertainty-Aware Verifier):

   • Un LLM separato (Claude Sonnet 4.5) valuta gli output sopravvissuti dei worker utilizzando 5 campioni Monte-Carlo per determinare un punteggio di sicurezza medio e la relativa dispersione.
   • Segnala gli output come "non sicuri" (unsafe) o "incerti" (uncertain).

3. Sintetizzatore a Triplo Filtro (Triple-Filter Synthesizer):

   • Il sintetizzatore finale accetta solo risposte che superano il gate IB-5, hanno un punteggio di sicurezza medio $\ge 0.5$ e non sono segnalate sia come non sicure che incerte.
   • Se nessun output sopravvive, viene restituito un rifiuto netto (hard refusal) senza invocare ulteriori chiamate LLM.

Metodologia di Valutazione

Il paper introduce una metodologia di attribuzione per traccia (per-trace attribution). Invece di riportare solo l'ASR, il sistema registra esattamente quale livello (gate IB, filtro del provider, verificatore o allineamento del modello) ha bloccato per primo un attacco. Ciò consente un'analisi di "sostituzione del meccanismo", distinguendo tra il blocco gestito dall'applicazione e quello "preso in prestito" dal provider.

3. Contributi Chiave

1. Attribuzione per Traccia: Una metodologia che converte l'ASR basato solo sull'esito in un account a livello di meccanismo, rendendo misurabile e visibile la "sostituzione del meccanismo" (la dipendenza dai filtri del provider).
2. Analisi della Dipendenza dal Provider: Evidenza empirica che su Azure GPT-5, una pipeline non difesa deriva il 90% della sua protezione a zero-ASR dal filtro del provider. Passando a backend Anthropic, questa protezione si sposta interamente sull'allineamento del modello, provando che l'esito di sicurezza è identico ma la provenienza è diversa e incontrollabile.
3. Il Framework ChannelGuard: Un sistema di sei gate di similarità di embedding che fornisce un blocco proprietario dell'applicazione e invariante rispetto al provider.
4. Delimitazione Precisa dei Limiti: Il paper identifica esplicitamente dove il framework fallisce (parafrasi adattiva white-box) e dove ha successo, supportato da estesi studi di ablazione e baseline.

4. Risultati

La valutazione ha coperto 2.100 tracce attraverso otto famiglie di attacchi, cinque difese e tre backend di modelli (Azure GPT-5, Anthropic Sonnet 4.5, Anthropic Haiku 4.5).

• Tool Poisoning (Avvelenamento degli Strumenti): ChannelGuard ha ottenuto 30/30 blocchi al gate IB-3 (Tool $\to$ Worker) su tutti e tre i backend. Al contrario, la pipeline non difesa si è affidata al 100% al filtro del provider Azure per il blocco su Azure, e al 100% all'allineamento del modello su backend Anthropic. Il meccanismo di ChannelGuard è rimasto fisso e di proprietà dell'applicazione.
• Prompt Injection: ChannelGuard ha ridotto l'ASR del 50% (da 0.333 a 0.167) rispetto alla baseline non difesa.
• Memory Poisoning (Avvelenamento della Memoria): Sull'architettura Azure, il filtro del provider ha dominato il blocco per entrambi i sistemi. Tuttavia, sui backend Anthropic, il gate IB-3-mem di ChannelGuard ha fornito un blocco parziale, con il resto gestito dall'allineamento del modello, dimostrando un risultato di "credito condiviso" piuttosto che una totale sostituzione.
• Adaptive Paraphrase (Parafrasi Adattiva - White-Box): Sia ChannelGuard che la baseline non difesa sono falliti, con un ASR di ~0.667. Il banco di frasi statico non è riuscito a rilevare riscrizioni semanticamente equivalenti ma lessicalmente distanti. Il paper nota che una baseline non basata su firme (SmoothLLM) ha performato meglio in questo specifico attacco.
• Efficienza: ChannelGuard è 1.19$\times$ più veloce sul carico di lavoro avversario aggregato. Nello specifico per la Prompt Injection, è 3.30$\times$ più veloce perché il suo gate IB-0 interrompe la pipeline prima di costose chiamate al modello.
• Fedeltà del Ragionamento: Sui compiti benigni GSM8K (senza attacchi), ChannelGuard ha preservato esattamente l'accuratezza del ragionamento (CTCA = 0.867 per entrambi i sistemi).

5. Significato e Rivendicazioni

Il paper sostiene che i modelli sicuri non si compongono in sistemi multi-agente sicuri senza un monitoraggio esplicito dei canali inter-agente. La sua importanza primaria risiede nel:

• Esporre l' "Illusione della Sicurezza": Dimostrare che lo zero-ASR nelle valutazioni attuali spesso maschera una totale dipendenza da filtri lato provider opachi e stocastici che gli sviluppatori non possono controllare o auditare.
• Invarianza dal Provider: Provare che ChannelGuard fornisce un meccanismo di blocco deterministico e ispezionabile che rimane coerente indipendentemente dal backend del modello sottostante, a differenza della sicurezza "presa in prestito" delle pipeline non difese.
• Difesa in Profondità: Posizionare ChannelGuard non come un sostituto dei filtri del provider o delle difese di solo input, ma come uno strato necessario che protegge la superficie interna della pipeline.

Gli autori sono modesti riguardo ai limiti del framework, riconoscendo che i banchi di frasi statici non possono sconfiggere la parafrasi adattiva white-box e che l'attuale implementazione si basa su template curati a mano e solo in lingua inglese. Concludono che il passo successivo è apprendere il banco di frasi in modo avversario per eguagliare la copertura dei canali.