Cosa invia il tuo assistente AI: audit del traffico con mitmproxy

```html

L'11 agosto 2026, su Hacker News è emerso un'analisi che ogni persona che utilizza un assistente AI nella propria IDE dovrebbe leggere: un ricercatore ha configurato VS Code con GitHub Copilot tramite un proxy di intercettazione e ha osservato cosa veniva inviato ai server. È emerso che nella richiesta veniva inclusa una quantità significativamente maggiore di dati rispetto alla semplice riga che si sta digitando, inclusi i contenuti del file .env in chiaro.

Buone notizie: chiunque può verificarlo, non solo con Copilot. Di seguito è riportata una guida pratica su come, in 20-30 minuti, avviare un audit del traffico del proprio assistente, cosa cercare nelle richieste intercettate e quali sono le limitazioni dei meccanismi di esclusione dei file standard.

Perché farlo da soli

La documentazione del fornitore descrive la politica, non il comportamento effettivo del client. Tra "non utilizziamo il tuo codice per l'apprendimento" e "il client non invia il tuo codice ai server" c'è un abisso: per generare un suggerimento, il modello deve ricevere un contesto, e la questione è solo quanto ampiamente il client raccoglie questo contesto.

L'audit è necessario se:

• lavori sotto NDA o con dati personali dei clienti e devi sapere cosa esce dal perimetro;
• hai segreti, configurazioni di ambienti, indirizzi interni e token nel tuo repository;
• sei responsabile della compliance nel team e hai bisogno di un log delle richieste reali, non di uno screenshot delle impostazioni;
• vuoi semplicemente capire perché l'assistente "sa" improvvisamente di un file che non hai aperto.

Cosa abbiamo trovato nel traffico di Copilot

L'analisi in questione si basava su un classico mitmproxy: VS Code è stato indirizzato a un proxy locale sulla porta 8080 e la verifica rigorosa del certificato è stata disattivata. Ecco le scoperte chiave:

• Il contesto è più ampio di un file. Durante i completamenti in linea, il client raccoglie fino a 20 file, 8 riepiloghi delle ultime modifiche e 3 righe di contesto attorno a ciascuna modifica, oltre al testo completo del file corrente e ai file recentemente modificati in forma di differenze.
• I segreti non sono mascherati. Nel corpo della richiesta, il campo prompt conteneva una stringa del tipo TEST_ENV_VAR_SECRET="mysecretenvvar" — quindi le variabili d'ambiente dal file aperto venivano inviate come testo normale.
• Il database locale è anch'esso aperto. Il file session-store.db memorizza user_message e assistant_response senza crittografia e modifica: in esso si trovavano token, chiavi dei fornitori di cloud e password delle stringhe di connessione che avevi un tempo inserito nella chat.
• Chiamate di servizio. Oltre ai completamenti stessi, il client chiama /models, /agents/swe/models, /models/session/intent e gli endpoint OAuth di GitHub — da questi è chiaro come l'assistente classifichi la tua richiesta ancor prima di generare una risposta.

Vale la pena ricordare: il client invia al server l'URL del repository corrente per ottenere la politica di esclusione applicabile. Questo fatto di per sé è innocuo, ma significa che la composizione del tuo albero di lavoro è anch'essa un segnale.

Passo dopo passo: avviamo l'intercettazione

1. Installa mitmproxy e avvialo. È sufficiente l'interfaccia web: mitmweb. Per impostazione predefinita, il proxy ascolta sulla porta 8080 e la console si apre nel browser. Per CI e sessioni lunghe è più comodo mitmdump.
2. Installa il certificato radice. Al primo avvio, mitmproxy crea un CA nella cartella ~/.mitmproxy (file mitmproxy-ca-cert.cer). Deve essere aggiunto ai certificati di fiducia — altrimenti il client interromperà la connessione TLS. Durante l'audit, è sufficiente la fiducia a livello utente; successivamente, rimuovi il certificato, non lasciare un CA esterno nel sistema "per precauzione".
3. Scegli la modalità di intercettazione. Ce ne sono tre, e una scelta corretta ti fa risparmiare un'ora di lavoro:
   • regular — proxy normale, il client viene configurato esplicitamente. È l'opzione più prevedibile.
   • local — intercettazione trasparente delle applicazioni su questa stessa macchina, senza modificare le impostazioni del programma: mitmproxy --mode local:Code intercetterà solo il processo di VS Code, --mode local:42 — il processo con il PID specificato, --mode local:!curl — tutto tranne curl. Questo è il modo migliore per ascoltare un assistente che non ha impostazioni proxy.
   • upstream — una catena in cui dietro mitmproxy c'è il tuo proxy: mitmdump --mode upstream:http://host:8081, e login e password vengono impostati con l'opzione --set upstream_auth=user:pass.
4. Indirizza l'IDE al proxy (per la modalità regular). In VS Code in settings.json:
   • "http.proxy": "http://127.0.0.1:8080"
   • "http.proxySupport": "override"
   • "http.proxyStrictSSL": false — solo durante l'audit. Questo flag disabilita completamente la verifica dei certificati, e non deve rimanere nella configurazione di lavoro.
5. Affronta il problema del certificato in modo serio. L'estensione Copilot funziona su Node, quindi il modo corretto è non disabilitare la verifica, ma raccogliere PEM con i CA radice più il certificato mitmproxy e specificarlo tramite la variabile d'ambiente NODE_EXTRA_CA_CERTS. L'IDE deve essere riavviato: la variabile viene letta all'avvio del processo.
6. Scrivi il flusso in un file. Guardare a occhio in tempo reale è inutile — ci sono decine di richieste al minuto. Attiva --set save_stream_file=flows.dump, e per non raccogliere tutto indiscriminatamente, limita il campionamento tramite --set save_stream_filter=.... Poi il file può essere analizzato offline.
7. Cerca nel corpo della richiesta, non nell'URL. Un trucco pratico: metti in un repository di test un file canarino con una stringa unica (ad esempio, CANARY_9f3c_DO_NOT_SEND), aprilo nell'editor, lavora in un file vicino — e cerca il canarino nei corpi intercettati. In questo modo vedrai non il raggio teorico di raccolta del contesto, ma quello effettivo della tua versione del client.

Insidie

La licenza può bloccare l'intercettazione. Nei piani aziendali, Copilot restituisce un errore del tipo "La tua attuale licenza Copilot non supporta connessioni proxy con certificati autofirmati". Questo non è un bug del proxy — il client rifiuta intenzionalmente di funzionare tramite un CA autofirmato. Si risolve con un certificato di fiducia a livello di sistema o creando un PEM per Node; se la politica dell'organizzazione lo vieta, l'audit dovrà essere concordato con l'amministratore, non aggirato.

Pinning e QUIC. Alcuni client utilizzano HTTP/3 sopra QUIC, che un proxy normale non vedrà. Se dopo aver attivato l'intercettazione l'applicazione "funziona, ma il log è vuoto" — quasi sempre la causa è questa: blocca UDP/443 per il processo di test, e il client tornerà a HTTP/2.

La telemetria e il payload seguono percorsi diversi. Non trarre conclusioni "niente viene inviato" da un solo endpoint: guarda l'intero elenco degli host a cui il processo si rivolge, non solo quello menzionato nella documentazione.

Quadro giuridico. È possibile intercettare il traffico sulla propria macchina e sul proprio account. Ascoltare il laptop di qualcun altro senza il consenso del proprietario è un'altra storia, e nessuna "sicurezza" la giustifica.

Cosa fare con i risultati

Se l'audit ha mostrato che nelle richieste vengono inclusi file non necessari, gli strumenti standard appaiono così — e ognuno ha una limitazione significativa.

• Esclusione dei contenuti. Meccanismo ufficiale di GitHub che impedisce a Copilot di utilizzare i percorsi specificati. Disponibile solo nei piani Business ed Enterprise, viene configurato dall'amministratore nelle impostazioni di Copilot, supportato in VS Code, Visual Studio e JetBrains; in Xcode, Eclipse e Vim/Neovim — solo per suggerimenti in linea.
• La principale falla è la modalità agent. La documentazione afferma chiaramente che le esclusioni non sono supportate nelle modalità Edit e Agent in Copilot Chat, così come in Copilot CLI. Cioè proprio dove l'assistente accede ai file, legge le configurazioni e avvia i comandi, la filtrazione della piattaforma non viene applicata. Se ti affidi all'esclusione dei contenuti come unico barriera — in modalità agent non c'è barriera.
• .gitignore non protegge. Un comune malinteso: escludere dall'indice Git non significa escludere dal contesto dell'assistente.
• Minimo organizzativo. I segreti devono essere nel gestore dei segreti, non in .env accanto al codice; la chat dell'assistente non è il posto per inserire stringhe di connessione; il database locale della cronologia dovrebbe essere pulito così come pulisci la cronologia della shell.

Dove si inserisce il proxy e perché ti serve

L'intercettazione ha un'applicazione pratica. In primo luogo, la modalità upstream consente di far passare tutto il traffico dell'assistente attraverso un nodo di uscita controllato: puoi vedere simultaneamente le richieste e gestire da quale indirizzo vengono inviate. Questo è necessario quando l'API dell'assistente non è accessibile dalla tua regione o quando la politica aziendale richiede un IP di uscita fisso — per tale scenario sono adatti proxy di data center stabili con indirizzo fisso.

In secondo luogo, lo stesso ambiente sarà utile per il debug dell'automazione: quando l'agente AI naviga autonomamente nei siti, l'intercettazione mostra quali intestazioni invia realmente e su cosa vengono catturate le protezioni. Abbiamo analizzato questo collegamento nel materiale sui proxy per agenti AI su Playwright e MCP — lì si parla della scelta del tipo di indirizzo per scenari agenti, dove è necessario un IP residenziale, non server.

Se non hai mai avviato mitmproxy, inizia con la configurazione di base per l'intercettazione HTTPS — è descritta in dettaglio nella nostra guida all'intercettazione del traffico tramite mitmproxy, e poi sovrapponi le modalità local e upstream.

Conclusione

L'audit del traffico dell'assistente AI non è paranoia, ma una normale igiene ingegneristica che richiede una sola serata e una sola volta. L'analisi di Copilot ha mostrato un quadro chiaro: il client raccoglie il contesto in modo ampio, i segreti entrano in questo contesto insieme al codice, la cronologia locale viene memorizzata in chiaro, e le esclusioni standard non funzionano proprio nella modalità più pericolosa — quella agent.

Controlla non la documentazione, ma il traffico. Avvia mitmproxy in modalità local, metti un canarino nel repository, raccogli il flusso in un file e guarda con i tuoi occhi cosa esce dalla tua macchina. Poi la soluzione è semplice: o accetti consapevolmente questo volume di trasmissione, o sposti i segreti al di fuori dell'albero di lavoro prima che vengano visti da un server esterno.