Telemetria degli agenti di coding: cosa viene inviato

Cosa copre realmente la telemetria degli agenti di programmazione

La telemetria degli agenti di programmazione comprende quattro flussi distinti di dati, accomunati soltanto dal termine usato per descriverli. Ogni flusso ha un proprio controllo. L'inferenza del modello trasmette i prompt e il codice al soggetto che fornisce il modello, e nessuna impostazione può disattivare questo flusso. Le analisi sull'uso del prodotto e i report sugli arresti anomali vengono inviati al fornitore e, spesso, anche a un'azienda di logging pagata dal fornitore. La conservazione dei dati per l'addestramento è una questione contrattuale, non di rete. Il quarto flusso è quello che spesso viene trascurato: ogni integrazione aggiunta può aprire una connessione verso un host che non hai scelto.

Un elenco delle impostazioni predefinite attuali dei fornitori è l'elemento più soggetto a variazioni in questo ambito. Una release può modificare un valore predefinito e una nuova funzionalità può aggiungere una destinazione che nessun comando di configurazione esistente può controllare. La competenza che rimane valida nel tempo consiste quindi nell'eseguire un audit ripetibile su qualsiasi agente: leggere la documentazione del fornitore, verificare quale configurazione è stata effettivamente applicata su questa macchina, monitorare il processo direttamente dalla macchina e scegliere i controlli per i quali si è disposti a sostenere il costo. Ogni comando riportato di seguito viene eseguito sulla propria macchina e analizza il proprio traffico.

Le quattro categorie e perché richiedono controlli diversi

Il traffico di inferenza del modello è inevitabile. L’agente invia il prompt, i file che ha letto, l’output dei comandi eseguiti e il testo generato al proprio endpoint del modello. Questo è il normale funzionamento del prodotto. L’unica decisione effettiva riguarda il destinatario: un’API gestita da terzi oppure un modello eseguito autonomamente. Un account cloud aziendale (Bedrock, Vertex, Foundry) cambia il destinatario, ma non elimina il flusso. Nulla nel resto di questo articolo riduce il traffico di inferenza. Tenetelo quindi distinto dalle altre tre categorie.

Le analisi del prodotto e la segnalazione degli arresti anomali seguono un flusso diverso verso host diversi. I contatori di utilizzo, i dati sulla latenza, le richieste dei feature flag e gli stack trace vengono normalmente inviati a hostname che non hanno alcuna relazione con l’API del modello e spesso a un servizio di terze parti per il tracciamento degli errori. I fornitori documentano di solito questi dati come “metriche” e “segnalazioni di errore” e in genere forniscono una variabile d’ambiente per ciascuna categoria. Il volume è minimo, quindi il conteggio dei byte non li individuerà mai. Dovete cercare gli hostname, non la larghezza di banda.

La conservazione e l’addestramento sono aspetti contrattuali, non pacchetti di rete. Il piano del fornitore stabilisce se conserva i prompt, per quanto tempo e se li usa per addestrare un modello futuro. I piani consumer e quelli commerciali sono generalmente diversi, mentre un accordo di conservazione zero è normalmente separato. Non potete verificare nessuno di questi aspetti con tcpdump, perché il pacchetto appare identico in entrambi i casi. Leggete le condizioni contrattuali e, se questo aspetto è importante per il vostro datore di lavoro, ottenetene conferma scritta.

Le integrazioni aggiungono silenziosamente un passaggio. Un server MCP (model context protocol), un marketplace di plugin, un controllo degli aggiornamenti automatici, uno strumento di ricerca sul Web o un controllo di sicurezza che risolve un URL prima di recuperarlo: ciascuno di questi elementi invia una richiesta a un host diverso dall’endpoint del modello. È qui che si verificano le sorprese, perché un harness può instradare tramite un proprio servizio un’attività che ritenevate locale, e una release può iniziare a farlo senza modificare una sola riga della configurazione. Considerate ogni strumento aggiunto come una nuova destinazione finché non ne avete osservato il traffico sulla rete.

Passaggio 1: cosa documenta il fornitore?

Apri il riferimento delle impostazioni e la pagina sull'utilizzo dei dati del tuo agent e leggili con un elenco di parole alla mano: metriche, analytics, segnalazione degli errori, crash, feedback, sondaggio, verifica degli aggiornamenti, controllo di sicurezza, marketplace. Ognuna di queste parole corrisponde di solito a un'interruttore distinto. Annota i nomi esatti delle variabili, perché il passaggio 2 li cerca con grep.

Una parola può trarti in inganno. In diversi agent, nei documenti «telemetry» indica un'esportazione OpenTelemetry che configuri per inviare le metriche a un collector gestito da te; è l'opposto dell'invio dei dati al fornitore. Claude Code è uno di questi: impostando CLAUDE_CODE_ENABLE_TELEMETRY=1 avvii un'esportazione verso l'endpoint specificato in OTEL_EXPORTER_OTLP_ENDPOINT, separata dagli analytics del fornitore, che hanno un'impostazione di opt-out diversa. Verifica la direzione del flusso di dati prima di configurare qualsiasi opzione.

Prevedi la presenza di un'impostazione principale e considera che possa avere delle lacune. Ad agosto 2026, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC di Claude Code disattiva insieme le metriche, i report degli errori, il comando feedback e i sondaggi di sessione. La stessa documentazione specifica però che questa impostazione non include il controllo di sicurezza del dominio WebFetch, che invia all'API del fornitore il nome host che stai per contattare e dispone di un'impostazione separata. Non è una caratteristica di un solo prodotto. Questo è il problema in generale: un'impostazione principale copre le categorie esistenti quando è stata documentata.

Considera anche il costo dell'opt-out. La stessa documentazione indica che la disattivazione della telemetria disabilita anche la valutazione dei feature flag da cui dipendono alcune funzionalità. Di conseguenza, un'impostazione attivata per motivi di privacy può disabilitare una funzionalità che utilizzi, senza alcun messaggio di errore che colleghi i due eventi. Leggi la frase accanto al flag, non soltanto il nome del flag.

Passaggio 2: quale configurazione è stata effettivamente applicata?

Un'impostazione che hai scritto non è necessariamente un'impostazione applicata. Gli agenti uniscono la configurazione proveniente da diversi file, e uno di questi si trova nel repository appena clonato da un'altra persona. Inizia dall'ambiente della tua shell.

env | grep -Ei 'telemetry|otel|analytics|error_report|do_not_track|proxy'

Quindi stampa tutti i file di configurazione letti dallo strumento, nell'ordine indicato dalla documentazione. Per Claude Code, ad agosto 2026, si tratta del file dell'utente, dei due file di progetto e di una directory dei criteri gestiti su Linux.

for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json; do
  echo "== $f"; [ -f "$f" ] && cat "$f"
done
ls -l /etc/claude-code/ 2>/dev/null

Un file di progetto arrivato insieme a un git clone contiene una configurazione scritta da una persona esterna e può riattivare un'impostazione disabilitata nel file dell'utente. Se l'agente dispone di un comando di stato che elenca le origini caricate, questo è il modo più rapido per ottenere un riscontro affidabile: Claude Code stampa le origini delle impostazioni caricate in /status.

Il controllo più affidabile legge il processo in esecuzione invece di un file. Assegna prima all'agente un account utente Linux dedicato; in questo modo ogni comando di questo articolo sarà più breve. Quindi leggi l'ambiente con cui è stato avviato il processo.

pgrep -u agent -a node
sudo tr '\0' '\n' < /proc/$(pgrep -u agent -n node)/environ | grep -Ei 'telemetry|proxy|otel'

/proc/<pid>/environ mostra le variabili presenti nel processo al momento di exec e rileva quindi il caso in cui l'export .bashrc non sia arrivato a un servizio avviato da systemd. Se qui manca una variabile che hai impostato, non è mai stata effettiva, indipendentemente da quanto dichiarato dai tuoi file dotfile.

Passaggio 3: a quali host si connette?

Inizia dai socket aperti, filtrati in base all'account con cui viene eseguito l'agent.

sudo ss -tnpe state established

-e aggiunge un campo uid: a ogni riga, così puoi distinguere le connessioni dell'agent da quelle del browser senza leggere i nomi dei processi. Prendi nota degli indirizzi remoti, quindi ricava i nomi associati. La fonte più affidabile è l'handshake TLS (transport layer security), perché ogni nuova connessione inizia con un ClientHello che contiene un campo SNI (server name indication), cioè il nome host richiesto dal client.

sudo apt install -y tshark
sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

Ottieni una riga per ogni nuova connessione, esattamente l'inventario che ti serve: l'API del modello, il server degli aggiornamenti, l'host di analytics, il sistema di tracciamento degli errori e qualsiasi altra destinazione aggiunta da un'integrazione. Una colonna del nome vuota indica che il client ha usato ECH (encrypted client hello), quindi il nome host non è visibile sulla rete. In questo caso, usa l'indirizzo IP di destinazione, una ricerca inversa oppure il proxy del passaggio 4.

La vista DNS (domain name system) è un controllo incrociato utile, perché mostra i nomi cercati dall'agent anche per le connessioni che non sono state completate.

sudo tcpdump -ni any -l 'udp port 53'

Ogni riga della query termina con il tipo di record e il nome, nel formato A? host.example.net. (39). Acquisisci il traffico su any invece che sull'interfaccia esterna, perché con systemd-resolved l'applicazione comunica con un listener stub locale su 127.0.0.53 e solo lo stub comunica con l'esterno. Se non vedi alcun traffico DNS mentre l'agent sta chiaramente funzionando, quel runtime esegue direttamente il DNS over HTTPS. In tal caso, solo il passaggio 4 ti permetterà di ricavare i nomi.

Acquisisci il traffico mentre l'agent esegue attività reali. Avvia una sessione, fagli leggere un file, fagli eseguire un comando e fagli produrre un errore. Il traffico generato una sola volta all'avvio, oppure soltanto quando viene sollevata un'eccezione, non compare mai in un'acquisizione eseguita in stato di inattività. Un'acquisizione inattiva è il modo più comune con cui un audit arriva a una conclusione errata ma apparentemente plausibile.

Passaggio 4: cosa contengono le richieste?

I nomi host indicano il destinatario. Per vedere il contenuto, posiziona un proxy sotto il tuo controllo davanti all'agent e, solo per quel runtime, considera attendibile la relativa certificate authority (CA). mitmproxy è lo strumento normalmente utilizzato. Il progetto raccomanda i binari standalone disponibili su mitmproxy.org e documenta uv tool install mitmproxy come metodo basato sul pacchetto Python.

mitmdump -w /tmp/agent-flows.mitm

Al primo avvio viene scritta una CA in ~/.mitmproxy/, dove mitmproxy-ca-cert.pem è il certificato separato. Nella shell da cui avvierai l'agent, configura il client in modo che utilizzi il proxy e quel certificato.

export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export REQUESTS_CA_BUNDLE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export SSL_CERT_FILE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"

Molte CLI degli agent sono programmi Node e Node legge NODE_EXTRA_CA_CERTS all'avvio del processo. Per questo devi esportarla prima di avviare l'agent, non in un altro terminale in un secondo momento. I client Python leggono REQUESTS_CA_BUNDLE o SSL_CERT_FILE, mentre un binario Go che utilizza la libreria standard legge SSL_CERT_FILE su Linux. Verifica che il percorso funzioni con curl prima di attribuire il problema all'agent.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Quando il proxy funziona, stampa 200 e la richiesta compare nell'output di mitmdump. Una CA non attendibile produce curl: (60) SSL certificate problem: self-signed certificate in certificate chain. L'errore equivalente di un agent Node contiene il codice SELF_SIGNED_CERT_IN_CHAIN. In seguito, leggi i flussi salvati con il visualizzatore da console. Puoi aprire una richiesta e leggerne gli header e il body.

mitmproxy -r /tmp/agent-flows.mitm

È utile distinguere 4 risultati. Vedi le richieste: in questo caso leggile e valuta il comportamento. L'agent non si avvia e restituisce un errore del certificato: è un problema di trust in quel runtime, non un'evidenza a carico del vendor. Vedi soltanto l'API del modello: le altre categorie sono disattivate oppure vengono attivate da un evento che non hai generato. Non vedi nulla, anche se l'agent funziona chiaramente: il client ignora le variabili d'ambiente del proxy oppure usa certificate pinning, quindi nessuna impostazione dell'applicazione può essere considerata attendibile per determinare il comportamento reale. Quest'ultimo risultato è il più importante e ti riporta al passaggio 3, perché non puoi convincere un packet capture a non rilevare una connessione.

Controlli, dal più debole al più forte

Impostazioni di esclusione. Sono l'opzione meno costosa e più debole, perché dipendono dal rispetto delle impostazioni da parte del fornitore e coprono una categoria già esistente. Impostatele in un punto che sopravviva a un riavvio e all'apertura di un nuovo terminale, ad esempio nel file delle impostazioni dell'utente o nel profilo della shell. Aggiungete anche DO_NOT_TRACK=1: è una convenzione rispettata da molti strumenti a riga di comando, inclusi alcuni agenti, e non comporta costi. Eseguite nuovamente il passaggio 3 dopo il prossimo aggiornamento, perché è in quel momento che cambia la copertura.

Limitazione del traffico in uscita. In questo caso smettete di chiedere e iniziate ad applicare una regola. Eseguite l'agente con un utente dedicato, quindi consentite a quell'utente di usare il loopback e il DNS e bloccate tutto il resto. Questo aggiunge una tabella propria, lasciando inalterate le regole firewall esistenti.

table inet agentegress {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ip daddr 127.0.0.0/8 accept
    meta skuid "agent" udp dport 53 accept
    meta skuid "agent" counter log prefix "agent-egress-drop " drop
  }
}

Applicatela con sudo nft -f /etc/nftables.d/agent.nft, controllate il contatore con sudo nft list table inet agentegress e leggete i pacchetti bloccati con sudo journalctl -k -g agent-egress-drop. Un contatore dei pacchetti bloccati in aumento associato a un hostname imprevisto è esattamente l'obiettivo della procedura. Esistono due limiti da considerare. meta skuid corrisponde all'utente proprietario del socket, quindi la regola è efficace solo finché quell'account non può diventare un altro utente: un sudo senza password per l'agente trasforma questa regola in un semplice suggerimento. Inoltre, lasciare UDP 53 aperto verso qualsiasi server mantiene un canale che può trasportare dati all'esterno nei nomi delle query; se il modello di minaccia lo richiede, chiudete anche questo canale configurando l'agente affinché usi un resolver gestito da voi. Le allowlist di hostname appartengono a un proxy, non a nftables, perché gli endpoint API sono ospitati dietro content delivery network i cui indirizzi IP possono cambiare senza preavviso. Il costo di questo controllo è rappresentato da interruzioni e manutenzione: le installazioni dei pacchetti, git tramite SSH e il controllo degli aggiornamenti dell'agente non funzioneranno finché non li autorizzerete, e l'elenco da mantenere sarà a vostro carico. Se state configurando tutto su un server invece che su un laptop, la stessa struttura di account e firewall è la base per eseguire Claude Code in sicurezza su un VPS.

Una macchina usa e getta. Assegnate all'agente una macchina virtuale (VM) che non contenga credenziali importanti e che venga eliminata al termine dell'attività. Questo non riduce i dati inviati dall'agente; riduce i dati a cui l'agente può accedere per inviarli, che di solito è il rischio realmente rilevante. Abbinatela alle regole per il traffico in uscita descritte sopra, perché una VM nuova con accesso illimitato a Internet può comunque raggiungere ogni host incluso nella cattura. Il metodo e lo stato da ricreare ogni volta sono descritti in eseguire agenti di coding in una VM usa e getta, mentre la questione del dimensionamento è trattata in eseguire un agente di coding su un VPS.

Self-hosting del modello. È l'unico controllo che elimina il flusso di inferenza, perché il prompt non lascia mai il vostro hardware. Il costo è concreto: non potete eseguire in self-hosting un modello chiuso, quindi dovete scegliere pesi open source e accettare una differenza di capacità nelle attività complesse, oltre a disporre dell'hardware necessario per servirli. Il compromesso è analizzato in valutare se potete eseguire Claude in self-hosting, mentre le differenze di capacità tra i principali agenti sono descritte in differenze tra Claude Code, Cursor, Codex e Copilot.

Nessuno di questi quattro controlli modifica ciò che l'agente può leggere sul disco, e il traffico di inferenza trasporta tutto ciò che l'agente legge. Se nella directory di lavoro è presente un file .env, il contenuto viene inviato al modello non appena l'agente esegue grep sul nome di una variabile. Impedire l'accesso a questo materiale è un'attività separata, descritta in impedire ai secret di entrare nel contesto di un agente AI.

Cosa controllare dopo ogni aggiornamento

1. Confronta le pagine del fornitore relative alle impostazioni e all'utilizzo dei dati con quanto hai registrato l'ultima volta, cercando nuovi interruttori e nuovi servizi denominati.
2. Rileggi l'ambiente del processo da /proc/<pid>/environ per verificare che le esclusioni siano ancora applicate al processo in esecuzione.
3. Stampa di nuovo i file delle impostazioni del progetto, perché un git pull può caricare un file di configurazione modificato da un collega.
4. Esegui la cattura SNI per un'intera sessione di lavoro reale e confronta l'elenco degli hostname con quello precedente.
5. Controlla il contatore dei pacchetti bloccati dal firewall, perché una nuova destinazione compare di solito lì prima che sia visibile altrove.

Sono necessari circa dieci minuti. È l'unica parte del processo che non diventa obsoleta. Un valore predefinito verificato ad agosto 2026 è un dato relativo ad agosto 2026. La cattura descrive la situazione di oggi.

FAQ

Posso impedire al mio coding agent di inviare il codice al modello?

No, e qualsiasi impostazione che affermi il contrario descrive un'altra cosa. L'invio del prompt, dei file letti dall'agent e dell'output dei comandi eseguiti al modello è il funzionamento stesso dell'inferenza. L'unica variabile è il destinatario. Puoi cambiare destinatario configurando l'agent per usare un account cloud aziendale o un modello gestito autonomamente. Puoi anche ridurre i dati inviati limitando ciò che l'agent può leggere. Disattivare analytics e segnalazioni degli errori non modifica in alcun modo questo flusso.

Come posso vedere a quali host si connette il mio coding agent?

Esegui l'agent con un utente Linux dedicato, quindi acquisisci il TLS ClientHello di ogni nuova connessione mentre lo utilizzi: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name. Compare una riga per ogni connessione, con l'indirizzo di destinazione e il nome host richiesto. Verifica i nomi con sudo tcpdump -ni any 'udp port 53', acquisendo il traffico su any, perché uno stub resolver locale su 127.0.0.53 gestisce prima la query. Esegui l'acquisizione mentre l'agent svolge attività reali, perché i ping di avvio e i report di arresto anomalo non compaiono in un'acquisizione eseguita quando è inattivo.

Il mio proxy non mostra traffico mentre l'agent è in esecuzione. Cosa è successo?

Il client ignora HTTP_PROXY e HTTPS_PROXY oppure usa il certificate pinning e rifiuta la tua CA. Verifica prima il percorso con curl: se curl raggiunge Internet tramite il proxy e l'agent non compare nell'elenco dei flussi, l'agent non usa le variabili d'ambiente del proxy. Alcuni runtime richiedono che la CA venga fornita in un modo specifico. In particolare, Node legge NODE_EXTRA_CA_CERTS solo all'avvio del processo, quindi esportarla dopo aver avviato l'agent non produce alcun effetto. Se il proxy non riesce a vedere il traffico, usa un'acquisizione dei pacchetti, che nessuna impostazione dell'applicazione può aggirare.

Disattivare la telemetria impedisce che il mio codice venga usato per l'addestramento?

No. Analytics e segnalazioni degli arresti anomali seguono un flusso diverso da quello dell'inferenza. Disattivarli rimuove i contatori di utilizzo e gli stack trace, ma lascia invariato l'invio di ogni prompt al modello. La conservazione dei prompt e il loro eventuale utilizzo per addestrare un modello futuro dipendono dai termini del piano. I piani consumer e quelli commerciali di solito differiscono. Si tratta di una condizione contrattuale da verificare, non di un pacchetto da acquisire. Controlla quindi la pagina relativa all'utilizzo dei dati del tuo piano e, quando necessario, definisci un accordo commerciale o a conservazione zero prima della prima sessione.