Steganografia nelle conversazioni LLM: perché il testo normale non basta come controllo
Il repository conversation-steganography mostra un rischio di ricerca: canali nascosti in testo plausibile. Non è prova che ogni chatbot li usi.
Scritto da Daniel Vedovato · Revisionato il 21 luglio 2026
Articolo preparato con assistenza AI, verificato e revisionato da Daniel Vedovato.
Un messaggio innocuo può trasportare più di ciò che leggiamo
Il repository conversation-steganography riguarda la steganografia: inserire un’informazione in un contenuto che, a prima vista, sembra normale. Nel caso di testi prodotti da modelli linguistici, il canale può sfruttare scelta di parole, struttura o altri dettagli statistici. È diverso dalla crittografia: il contenuto cifrato si vede ma non si legge; quello steganografico prova a non farsi notare.
Il fatto che un esperimento o un repository esista non dimostra che i normali assistenti AI stiano già comunicando segretamente. Dimostra invece un limite importante per chi costruisce sistemi con più agenti: controllare soltanto il significato apparente di una risposta non garantisce di aver controllato tutto ciò che il testo veicola.
Perché interessa chi integra agenti
Un agente che passa note a un altro agente, o che riceve testo da utenti e fonti esterne, lavora su un canale non completamente affidabile. Il rischio pratico non è solo la fuga intenzionale di dati. Sono anche istruzioni nascoste, marcatori che aggirano filtri semplici e output difficili da attribuire. Il problema cresce quando gli agenti hanno strumenti: un messaggio ambiguo può influenzare ricerca, esecuzione di codice o uso di credenziali.
| Controllo | Cosa riduce | Cosa non risolve |
|---|---|---|
| Schema JSON rigido | Variazioni testuali inutili | Contenuti dannosi nei campi consentiti |
| Limiti di lunghezza e normalizzazione | Canali banali e rumore | Codifiche più robuste |
| Permessi minimi per tool | Danno dopo un input malevolo | Manipolazione del giudizio umano |
| Log di input e output | Indagine e riproduzione | Prevenzione automatica |
Prova sicura, non istruzioni per nascondere dati
Non serve costruire un canale nascosto per verificare il rischio. In staging si possono confrontare due pipeline: una che inoltra testo libero e una che inoltra solo campi ammessi, normalizzati e validati. Su un set di conversazioni sintetiche si misura quante varianti inattese superano il validatore e se cambiano la decisione dell’agente successivo. Il test va svolto senza segreti reali, accessi produttivi o azioni irreversibili.
La metrica utile non è “abbiamo un rilevatore perfetto”, obiettivo irrealistico. È la riduzione della superficie: quanti passaggi richiedono testo libero, quali agenti possono chiamare strumenti, quanto è facile ricostruire la catena decisionale. Se un sistema deve trasmettere un ordine, preferisco un oggetto firmato e validato a una frase naturale.
Limiti della fonte e conclusione
Una repository è una fonte primaria per il proprio codice e le proprie istruzioni, non per affermazioni generali sulla diffusione dell’abuso. Prima di prendere decisioni di sicurezza controllerei commit, licenza, test riproducibili e, per claim sperimentali, paper o valutazioni indipendenti. Non trasformerei questa lettura in un allarme indiscriminato sui chatbot.
La lezione concreta è più sobria: nei flussi agentici, il testo deve essere considerato input non attendibile. Contratti di dati, autorizzazioni minime, revisione e audit restano difese più solide di un filtro basato sul fatto che una frase “sembra innocua”.
Dove inserire i controlli nella pipeline
La difesa deve iniziare prima del modello. Un connettore che legge pagine web, ticket o email dovrebbe estrarre solo i campi necessari e separarli dalle istruzioni operative. Un secondo confine è fra agenti: invece di passare l’intera conversazione, l’agente a valle riceve un risultato con schema, provenienza e livello di confidenza. Infine, prima di una chiamata a browser, shell o API, un controllo deterministico verifica destinazione, parametri e autorizzazione.
Questo disegno non rende impossibile ogni abuso, ma limita l’effetto di un contenuto manipolato. Un testo non strutturato potrà al massimo influenzare una proposta; non dovrà poter scegliere da solo un destinatario, inviare un dato o eseguire un’azione costosa. È anche più semplice da controllare in una revisione di sicurezza rispetto a una catena di prompt molto lunga.
Criteri per decidere se il rischio è accettabile
Classificherei i flussi per impatto. Per una bozza interna senza accesso a strumenti possono bastare log e revisione umana. Per un agente che consulta dati aziendali servono isolamento, minimizzazione dei dati e output vincolato. Per pagamenti, modifiche a produzione o comunicazioni esterne, l’agente può preparare una richiesta ma un sistema deterministico e una persona devono autorizzarla.
Vale la pena riesaminare questi confini a ogni nuovo tool o modello. La capacità di generare testo cambia rapidamente, mentre permessi e responsabilità devono rimanere espliciti. Il contributo utile di questa ricerca è proprio spostare l’attenzione dal solo filtro dell’output alla progettazione completa del canale.