Un dettaglio passato quasi inosservato sul subreddit dedicato all’intelligenza artificiale ha acceso un faro su una pratica tanto ingegnosa quanto potenzialmente problematica: secondo quanto segnalato da un utente, Claude Code, lo strumento di Anthropic pensato per assistere gli sviluppatori nella stesura di codice, starebbe utilizzando la steganografia per marcare ogni richiesta inviata. Nessuna dichiarazione ufficiale è ancora arrivata, ma la notizia solleva un velo su un meccanismo che, se confermato, potrebbe riscrivere le regole della fiducia negli strumenti di coding basati su LLM.

La tecnica: nascondere dati dove nessuno guarda

La steganografia, a differenza della crittografia, non rende illeggibile un messaggio: lo occulta in bella vista, inserendolo all’interno di un contenitore innocuo. Nel contesto di un assistente di codice, questo può tradursi nell’aggiunta di caratteri a larghezza zero, spaziature anomale nei commenti, o sequenze apparentemente inutili all’interno di stringhe e nomi di variabili. L’obiettivo dichiarato di pratiche simili è spesso il watermarking per identificare l’origine di un testo o, in questo caso, del prompt che ha generato una porzione di sorgente. Claude Code, stando alla segnalazione, applicherebbe tale marcatura alle richieste prima ancora che il codice venga prodotto, creando così una traccia invisibile ma persistente.

Dal punto di vista tecnico, questo tipo di intervento è estremamente leggero dal lato computazionale e non richiede modifiche all’architettura del modello. La marca può essere codificata con pochi byte e passare del tutto inosservata a uno sviluppatore che non esegua un’ispezione approfondita. Per un LLM in fase di inference, il segnale aggiuntivo non altera la qualità del completamento, ma rappresenta una forma di capitale informativo che permane nel codice generato e, potenzialmente, in tutti i sistemi che lo adotteranno.

Sovranità dei dati e la trappola del codice assistito

Per chi lavora in ambienti dove la sovranità digitale è un requisito irrinunciabile – banche, difesa, sanità, pubblica amministrazione – la scoperta ha un peso specifico notevole. Il codice prodotto con l’aiuto di strumenti cloud, se marchiato in modo occulto, potrebbe fungere da vettore per la fuoriuscita di metadati sensibili. Non si tratta soltanto di una questione di proprietà intellettuale: l’esistenza di un identificatore nascosto consentirebbe di risalire all’utente o all’organizzazione che ha originato la richiesta, annullando di fatto l’anonimato garantito dalle policy sulla privacy e violando potenzialmente i vincoli GDPR.

L’utilizzo di marcatori steganografici sposta l’attenzione dalla protezione del dato in transito a quella del dato “a riposo” nel codice, un aspetto spesso trascurato nei processi di audit. Se un pezzo di software finisce in produzione in un ambiente on-premise air-gapped, la presenza di tali marche crea un ponte informativo fra il cloud e il sistema isolato, scavalcando di fatto qualsiasi firewall fisico. La trasparenza, in uno scenario simile, non è più una scelta di comunicazione ma una variabile strutturale dell’architettura.

Strumenti di watermarking: tra sicurezza e lock-in nascosto

L’industria degli LLM sta esplorando da tempo tecniche di filigrana per distinguere i contenuti sintetici da quelli umani. Tuttavia, applicare la steganografia alle richieste di codice introduce un elemento inedito: il meccanismo di tracciamento è attivo a monte del completamento, influenzando il processo prima ancora che il genere di output venga scelto. Questo ribalta la prospettiva abituale sulle difese anti-abuse – spesso concentrate sull’output – e mette in luce il potenziale per un tracciamento granulare delle sessioni di sviluppo.

C’è poi il rischio di un lock-in poco evidente. Un’azienda che basi una parte significativa della propria codebase su suggerimenti marchiati potrebbe trovarsi in una posizione di dipendenza dal fornitore per ogni futura verifica di compliance o per la rimozione delle marche stesse. Senza una dichiarazione preventiva sulla presenza di metadata nascosti, il produttore del servizio detiene un vantaggio informativo asimmetrico che contrasta con i principi di controllo richiesti dai deployment self-hosted.

Oltre il singolo tool: ripensare la pipeline di sviluppo on-premise

L’episodio di Claude Code è lo spunto per una riflessione più ampia su come integrare gli assistenti AI nelle pipeline di sviluppo che puntano al controllo totale sui dati. Per chi valuta deployment on-premise di LLM, la questione della trasparenza delle marche e della possibilità di disattivarle diventa centrale tanto quanto le prestazioni in termini di token al secondo o la dimensione della finestra di contesto. Non si tratta di demonizzare uno strumento, ma di allineare le scelte tecniciche ai requisiti di sicurezza che rendono obbligatoria, in certi settori, l’assenza di qualsiasi canale informativo non documentato verso l’esterno.

AI-RADAR ha già analizzato in precedenza i trade-off fra soluzioni cloud e stack self-hosted, mettendo in luce come la gestione dei metadati sia spesso l’anello debole della catena. Questo nuovo tassello – la marcatura steganografica nelle richieste – aggiunge una dimensione ulteriore: non basta più auditare il modello, bisogna scrutare ogni singola interazione con il servizio. L’alternativa non è rifiutare l’innovazione, ma pretendere che la sua architettura sia ispezionabile e che ogni marcatura venga dichiarata, disattivabile e non introduca vettori di tracciamento non autorizzati.