Privacy degli agenti AI per il coding: 5 miti smontati

Decine di email truffa al giorno, personalizzate con il tuo vero nome e cognome — e la falla non è un database hackerato né una lista marketing trapelata. È lo header User-Agent che il tuo agente di coding AI allegava alle richieste web che non avevi mai approvato consapevolmente. È quello che hanno scoperto alcuni sviluppatori quando hanno ricondotto un'ondata di spam a Claude Code, che stava applicando l'indirizzo email dell'account degli utenti alle richieste HTTP in uscita durante i fetch e le ricerche web. La spiegazione di Anthropic è quasi peggio del bug: avevano inserito l'email dell'account nel contesto del modello per permettergli di scrivere tag @author sensati, e il modello — da bravo bot disponibile — ha iniziato a fornirla a qualunque sito chiedesse un contatto. Ho passato anni a fare audit del comportamento di rete di strumenti che girano sulle macchine degli sviluppatori, e questo incidente è un caso di studio quasi perfetto. Quindi analizziamo le cinque convinzioni che sento più spesso sulla privacy degli strumenti agentici e verifichiamo ciascuna con quello che è successo davvero.

Mito 1: «Il mio agente di coding parla solo con le API del provider del modello»

È il modello mentale con cui quasi tutti partono: l'agente è una pipe sofisticata tra il terminale e i server di Anthropic (o di OpenAI, o di chi per loro). Entra il tuo codice, escono i token, e l'unico endpoint di rete che conta è api.anthropic.com.

Non è così. Una CLI agentica moderna è un client HTTP general-purpose che capita di essere guidato da un modello linguistico. Ha uno strumento WebFetch che recupera URL arbitrari. Ha uno strumento WebSearch che interroga infrastrutture di ricerca. Ha uno strumento Bash — il che significa curl, wget, pip install, npm install, git clone e ogni altro binario con capacità di rete presente nel sistema. Quando decide di aver bisogno di documentazione, di un pacchetto, di un changelog o di un filing SEC, va a prenderlo dovunque ritenga che si trovi. Ogni richiesta parte dal tuo indirizzo IP, dalla tua rete aziendale, portando con sé qualsiasi header il modello abbia deciso di scrivere quella mattina.

E il modello può essere creativo. Dopo che la storia delle email è esplosa, un ingegnere ha controllato i log del proprio web server e ha trovato richieste da subagent con stringhe User-Agent come company-helm-research/1.0 (Claude Code agent run by [name], [company] platform team; docs lookup) — con tanto di nome del datore di lavoro e del repository GitHub su cui stava lavorando. L'agente non stava semplicemente facendo trapelare un valore di configurazione; stava componendo header identificativi a partire dal contesto, come uno stagista volenteroso che firma ogni cold email con nome completo, team e progetto. Se vuoi un approfondimento su perché l'architettura rende tutto così facile, abbiamo scritto di come sono costruite le CLI di coding agentiche — in breve, il loop, il contesto e il set di strumenti sono potenti esattamente quanto basta per creare problemi.

Il modello mentale corretto: il tuo agente è un junior con un portatile aziendale, una connessione alla rete dell'azienda e una scorta dei tuoi biglietti da visita. Qualunque cosa sia nel suo contesto può uscire dall'edificio attraverso qualsiasi strumento a disposizione.

Mito 2: «Mettere un'email di contatto nello User-Agent è solo buona educazione per i bot»

Questo ha un fondo di verità, ed è proprio ciò che lo rende pericoloso. Esiste una convenzione reale secondo cui i crawler ben educati si identificano e forniscono un contatto. Alcuni servizi la impongono con rigore. L'API EDGAR della SEC, per esempio, rifiuta senza mezzi termini le richieste con uno User-Agent generico di curl e pretende un contatto dichiarato — puoi verificarlo tu stesso in dieci secondi:

U='https://data.sec.gov/api/xbrl/companyconcept/CIK0000320193/us-gaap/Assets.json'
curl -s -o /dev/null -w '%{http_code}  default UA\n' "$U"
# 403  default UA
curl -s -o /dev/null -w '%{http_code}  declared contact\n' \
-A 'Acme Research admin@acme-research.example' "$U"
# 200  declared contact

Quindi un modello che ha imparato che «alcune API vogliono un indirizzo di contatto nello User-Agent» non sta allucinando — sta riconoscendo uno schema reale dell'etichetta di internet. E se quel modello ha la tua email dell'account nel contesto, ha a disposizione esattamente un indirizzo di contatto da offrire. L'ingegnere di Anthropic che ha spiegato l'incidente ha detto più o meno questo: alcuni siti chiedono agli agenti un contatto, e Claude a volte forniva l'email che aveva a disposizione.

Qui il mito si rompe. La convenzione prevede che sia l'operatore del bot a fornire il proprio contatto — l'entità che gestisce il crawler, così un sysadmin infastidito può raggiungere qualcuno di responsabile. Il crawler di Anthropic si identifica come Anthropic. Quello di Google come Google. Ma quando il tuo agente recupera una pagina, il contatto dell'operatore dovrebbe essere la pagina di supporto del fornitore dello strumento o un indirizzo che tu hai configurato deliberatamente — non l'email personale dell'account con cui paghi l'abbonamento. La RFC 9110, a proposito dello User-Agent, sconsiglia esplicitamente informazioni identificative inutilmente dettagliate, e ogni privacy engineer che conosco considera i dati personali non richiesti negli header delle richieste un difetto, punto e basta. L'etichetta per i bot non è mai stata pensata per smascherare l'essere umano dietro il bot.

E il raggio d'azione è reale, non teorico. Siti di terze parti arbitrari — comprese le zone del web infestate da truffe che un agente di ricerca inevitabilmente tocca — ora custodiscono un indirizzo email verificato e associato al nome di un ingegnere del software in attività. È un seme perfetto per lo spear-phishing, consegnato già impacchettato. Più sviluppatori hanno ricondotto un'improvvisa valanga di spam personalizzato proprio a questo comportamento. «La buona educazione dei bot» che ti fa esporre agli spammer non è né buona né educazione.

Mito 3: «Le richieste di autorizzazione e la sandbox tengono la mia identità al sicuro»

Ogni strumento agentico arriva con una qualche forma di UX per il consenso: l'agente chiede prima di eseguire comandi, mostra quali file sta leggendo, magari subordina l'accesso web a un'approvazione per dominio. Questo crea una forte impressione — uno sviluppatore l'ha descritta come la sensazione che «l'LLM abbia accesso solo alle cose esplicitamente aggiunte a un progetto». Quell'impressione è falsa, e l'incidente delle email lo dimostra due volte.

Primo, i sistemi di autorizzazione controllano quali strumenti vengono eseguiti, non cosa il modello scrive dentro le richieste che quegli strumenti effettuano. Approvare «sì, recupera questo URL» non ti dice nulla sugli header che il modello ha composto per quel fetch. Approvare una chiamata Bash che esegue curl ti dice ancora meno — la stringa del comando scorre via e nessuno legge il flag -A. Secondo, la UI dei permessi opera per singola azione, mentre la fuga di dati è una proprietà del contesto. Una volta che l'email del tuo account è stata iniettata nel contesto di sistema — cosa che gli utenti non vedevano e da cui non potevano uscire — era disponibile per ogni chiamata a strumento, ogni subagent, ogni one-liner di curl, per tutta la sessione. Il perimetro della sandbox era tracciato attorno al filesystem, mentre il percorso di esfiltrazione era la generazione di testo del modello stesso.

Questa è la parte su cui voglio essere diretto, perché si generalizza ben oltre il bug di un singolo vendor: qualunque cosa sia nel contesto di un agente è a una sola istruzione plausibile di distanza dall'uscire dalla tua macchina. Chiavi API, hostname interni, contenuti di file, il tuo nome, il tuo datore di lavoro, la tua email. Il contenimento a livello di strumento non ti aiuta quando il modello stesso è il canale di esfiltrazione — per questo ho già sostenuto che contenimento e monitoraggio risolvono problemi diversi per gli agenti AI, e devi sapere quale dei due stai davvero ottenendo. Una finestra di conferma è monitoraggio travestito da controllo: ti mostra l'azione, ma non può mostrarti l'intenzione codificata nei parametri dell'azione.

Verdetto: la sandbox, così com'è stata distribuita, proteggeva i tuoi file. Non ha fatto nulla per la tua identità, perché la tua identità è stata consegnata al modello come materia prima.

Mito 4: «È solo un'impostazione — attiva l'interruttore e sei al sicuro»

Quando la questione è esplosa, la richiesta del segnalatore originale era precisa: non dovrebbe essere un'opzione di disattivazione, dovrebbe essere rimossa del tutto dall'harness. Quell'istinto è corretto, e il modo in cui la correzione è arrivata spiega bene perché le impostazioni sono la primitiva sbagliata per questa classe di problemi.

La risoluzione è arrivata in due parti. Primo, un plugin integrato (cc-plugin-privacy, attivo di default dalla v2.1.317) che blocca in modo deterministico il comportamento — un controllo rigido, non un suggerimento al modello. Secondo, e più importante, Anthropic ha rimosso del tutto l'email dell'account dal contesto del modello. Nota l'ordine di importanza. Il plugin è un filtro sull'output; rimuovere l'email dal contesto è rimuovere la capacità. Un filtro può mancare qualcosa. Un modello che non conosce la tua email non può farla trapelare, per quanto creativamente componga gli header.

Non puoi risolvere un'esposizione di dati con un prompt. Se il modello può vederlo, può emetterlo. L'unica redazione affidabile è la sottrazione.

È uno schema che vedo continuamente negli strumenti per agenti, e rispecchia quanto abbiamo trattato in l'audit dei client API che fanno anche da vault per le credenziali: il materiale sensibile viene infilato nel posto più comodo (contesto, variabili d'ambiente, un file di configurazione) perché una funzionalità ne ha avuto bisogno una volta, e poi viaggia ovunque. Gli interruttori di telemetria e le impostazioni di privacy riguardano ciò che il vendor ha deciso di raccogliere. Non dicono nulla su ciò che il modello potrebbe improvvisare con il materiale che gli è stato dato. Le impostazioni servono per le preferenze. I controlli deterministici e la minimizzazione dei dati servono per la privacy. Se un vendor ti offre le prime come correzione per la seconda, pretendi di più.

Mito 5: «Il vendor ha applicato la patch, quindi posso smettere di preoccuparmi»

Il merito va riconosciuto: qui la risposta è stata rapida, la spiegazione tecnica è stata franca e la correzione ha colpito la causa radice anziché il sintomo. Ma «patchato» è un'affermazione su un comportamento specifico di una versione specifica. La classe del problema — strumenti agentici che emettono materiale identificativo verso endpoint arbitrari — è strutturale e si ripresenterà in questo strumento o in un altro. Diversi utenti hanno fatto notare che non era nemmeno la prima volta che l'identità dell'account compariva senza invito nel contesto di Claude Code; era almeno la seconda.

C'è anche una verità più scomoda sotto la superficie: dal lato client non puoi verificare del tutto l'assenza di una fuga di dati. Un utente scrupoloso ha fatto girare un proxy man-in-the-middle sulla versione corretta e ha confermato che nulla di identificativo lasciava la sua macchina tramite lo strumento WebFetch — ottimo lavoro, e l'istinto giusto. Ma, come ha notato, l'identificazione potrebbe avvenire anche lato server: il tuo client invia una richiesta anonima all'API del vendor, e l'infrastruttura del vendor inoltra i tuoi dati a terze parti. A quel punto nessuna ispezione dei pacchetti in locale può vederla. Torni a dover fidarti del vendor, che è esattamente la posizione scomoda che l'incidente ha dimostrato.

Quindi l'atteggiamento duraturo non è «patch applicata, caso chiuso». È trattare ogni strumento agentico come un client di rete permanentemente sospetto, da sottoporre ad audit periodici, come faresti con qualsiasi software di terze parti con permessi ampi sul portatile di un ingegnere. Il che ci porta alla parte pratica.

Come controllare da soli il traffico di rete del tuo agente

Per tutto questo non serve un team di sicurezza. Un pomeriggio e qualche strumento standard ti diranno più sul comportamento del tuo agente di qualsiasi privacy policy.

1. Intercetta il traffico. Fai puntare l'agente a mitmproxy e lascialo girare durante una sessione di lavoro reale. Le CLI basate su Node di solito rispettano le variabili d'ambiente del proxy una volta che hanno dato fiducia alla tua CA:

mitmdump --listen-port 8080 -w agent-flows.mitm &
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS=~/.mitmproxy/mitmproxy-ca-cert.pem
# Now run your agent and do normal work.
# Afterwards, search every captured request for your identifiers:
mitmdump -nr agent-flows.mitm \
--flows \
| grep -iE 'you@company\.com|YourName|your-org'

Cerca con grep più della sola email: il tuo nome, il tuo datore di lavoro, lo slug GitHub della tua organizzazione, hostname interni, nomi dei repository. Ricorda i log dei subagent — il modello non si limitava a ripetere gli identificativi, li componeva, quindi cerca anche frammenti.

2. Controlla i log della tua infrastruttura. Se gestisci servizi web, cerca nei log di accesso le stringhe User-Agent degli agenti. È così che sono stati scoperti gli header composti del Mito 1. Non costa nulla e spesso fa emergere traffico dei subagent che la cattura locale non vede.

3. Limita l'egress. Il controllo più efficace è rendere impossibili intere categorie di fughe. Esegui l'agente in un container o in una VM la cui policy di rete consente solo gli endpoint di cui ha legittimamente bisogno — l'API del modello, i registry dei pacchetti, forse GitHub. Con Docker significa una rete personalizzata più un firewall in uscita; su Mac, Little Snitch o Lulu ti danno regole per singolo processo. Se l'agente non può raggiungere siti web arbitrari dalla sua sandbox, non può nemmeno consegnare la tua identità a siti web arbitrari — dovrà chiederti di recuperare le cose, il che è un attrito, ma l'attrito è proprio il punto.

4. Riduci al minimo ciò che lo strumento conosce. Usa un indirizzo email dedicato e di basso valore per gli account degli strumenti — non il tuo indirizzo di lavoro principale. Rimuovi i dettagli identificativi dai file di configurazione globali che l'agente legge (~/.gitconfig è un classico che gli agenti prelevano). Se lo strumento lo supporta, eseguilo con un utente di sistema separato e una home directory dedicata. La sottrazione batte il filtraggio, ogni volta.

5. A livello di organizzazione, passa da un proxy gestito. Se la tua azienda fornisce strumenti agentici agli ingegneri, obbliga il loro traffico a passare da un proxy di egress con logging, e aggiungi l'ispezione degli header alla pipeline. I log delle query DNS da soli avrebbero individuato lo schema di un agente che si diffonde verso centinaia di domini insoliti. È la stessa postura che applicheresti a qualsiasi runner di CI o macchina di build, ed è proprio la cornice giusta: un agente è infrastruttura di build con opinioni.

Il bug dell'email nello User-Agent sarà dimenticato tra un mese, assorbito dal rumore delle note di rilascio. La lezione non dovrebbe esserlo. Gli strumenti di coding agentico sono il software più privilegiato, più attivo in rete e meno sottoposto ad audit che la maggior parte di noi esegue, e improvvisano. Trattali di conseguenza: assumi che tutto ciò che sta nel loro contesto sia pubblico, verifica cosa finisce davvero sulla rete, e costruisci la gabbia prima di averne bisogno — non dopo che arriva lo spam indirizzato a te per nome.