AI Asistanınızın Dışarı Gönderdiği: mitmproxy ile Trafik Denetimi

```html

11 Ağustos 2026'da Hacker News'da, çalışma IDE'sinde AI asistanı bulunduran herkesin okuması gereken bir inceleme yayımlandı: bir araştırmacı, VS Code'u GitHub Copilot ile bir yakalama proxy'sine yönlendirdi ve nelerin sunuculara gittiğini inceledi. Anlaşıldı ki, gönderilen isteklerde yazdığınız satırdan çok daha fazlası yer alıyor - açık .env dosyasının içeriği de dahil.

İyi haber: bunu herkes kontrol edebilir ve sadece Copilot için değil. Aşağıda, asistanınızın trafik denetimini 20-30 dakikada nasıl başlatacağınız, yakalanan isteklerde neleri arayacağınız ve dosya hariç tutma mekanizmalarının sınırlamaları hakkında bir çalışma talimatı bulunmaktadır.

Bunu kendiniz yapmanın önemi

Satıcı belgeleri politika tanımlar, ancak istemcinin gerçek davranışını açıklamaz. "Kodunuzu eğitim için kullanmıyoruz" ile "istemci kodunuzu sunucuya göndermiyor" arasında büyük bir fark var: bir öneri oluşturmak için modelin bağlamı alması gerekiyor ve sorun, istemcinin bu bağlamı ne kadar geniş topladığıdır.

Denetim gereklidir, eğer:

• Bir NDA altında çalışıyorsanız veya müşteri kişisel verileriyle ilgileniyorsanız ve neyin sınırdan çıktığını bilmek zorundaysanız;
• Depoda gizli bilgiler, yapılandırma dosyaları, dahili adresler ve token'lar tutuyorsanız;
• Ekibinizde uyumluluktan sorumluysanız ve bir ayar ekranından ekran görüntüsü değil, gerçek isteklerin günlüklerini istiyorsanız;
• Asistanın neden birdenbire açmadığınız bir dosyayı "bildiğini" anlamak istiyorsanız.

Copilot trafiğinde neler bulundu

Söz konusu inceleme, klasik mitmproxy'ye dayanıyordu: VS Code, yerel bir proxy'ye 8080 portu üzerinden yönlendirildi ve sertifika doğrulaması kapatıldı. Ana bulgular:

• Bağlam bir dosyadan daha geniştir. Satır içi tamamlamalarda istemci, 20'ye kadar dosya toplar, son düzenlemelerin 8 özetini ve her değişikliğin etrafında 3 satır bağlam toplar, ayrıca mevcut dosyanın tam metni ve yakın zamanda düzenlenmiş dosyalar dif olarak gelir.
• Gizli bilgiler maskelemiyor. İstek gövdesinde prompt alanı, TEST_ENV_VAR_SECRET="mysecretenvvar" biçiminde bir dize içeriyordu - yani açık dosyadan çevresel değişkenler normal metin olarak gönderiliyordu.
• Yerel veritabanı da açıktır. session-store.db dosyası, user_message ve assistant_response verilerini şifrelemeden ve düzenlemeden saklıyor: içinde token'lar, bulut sağlayıcılarının anahtarları ve bir zamanlar sohbetinize eklediğiniz bağlantı dizelerinin parolaları bulunuyordu.
• Hizmet çağrıları. Kendi tamamlamalarının yanı sıra, istemci /models, /agents/swe/models, /models/session/intent ve GitHub OAuth uç noktalarını çağırıyor - bu, asistanın yanıtı oluşturmadan önce isteğinizi nasıl sınıflandırdığını iyi bir şekilde gösteriyor.

Ayrıca, istemcinin geçerli depo URL'sini sunucuya gönderdiğini unutmamak önemlidir; bu, geçerli hariç tutma politikasını almak için gereklidir. Bu durum kendiliğinden zararsızdır, ancak çalışma ağacınızın bileşimi de bir sinyal anlamına gelir.

Aşama aşama: yakalamayı başlatma

1. mitmproxy'yi kurun ve çalıştırın. Yeterli olan web arayüzü: mitmweb. Varsayılan olarak proxy 8080 portunu dinler, konsol tarayıcıda açılır. CI ve uzun oturumlar için mitmdump daha uygundur.
2. Kök sertifikasını yükleyin. mitmproxy ilk çalıştırıldığında ~/.mitmproxy dizininde bir CA oluşturur (dosya mitmproxy-ca-cert.cer). Bunu güvenilirler listesine eklemeniz gerekir - aksi takdirde istemci TLS bağlantısını keser. Denetim süresi boyunca kullanıcı düzeyinde güven yeterlidir; sonrasında sertifikayı kaldırın, sistemde "her ihtimale karşı" başka bir CA bırakmayın.
3. Yakalama modunu seçin. Üç mod vardır ve doğru seçim bir saat tasarruf sağlar:
   • regular — normal bir proxy, istemci açıkça yapılandırılır. En öngörülebilir seçenek.
   • local — bu makinedeki uygulamaların şeffaf yakalanması, program ayarlarını değiştirmeden: mitmproxy --mode local:Code yalnızca VS Code sürecini yakalar, --mode local:42 belirtilen PID'ye sahip süreci, --mode local:!curl ise curl hariç her şeyi yakalar. Bu, proxy ayarı olmayan bir asistanı dinlemenin en iyi yoludur.
   • upstream — mitmproxy'nin arkasında kendi proxy'nizin olduğu bir zincir: mitmdump --mode upstream:http://host:8081, giriş ve şifre --set upstream_auth=user:pass seçeneği ile belirlenir.
4. IDE'yi proxy'ye yönlendirin (regular mod için). VS Code'da settings.json dosyasında:
   • "http.proxy": "http://127.0.0.1:8080"
   • "http.proxySupport": "override"
   • "http.proxyStrictSSL": false — sadece denetim süresi boyunca. Bu bayrak, sertifika kontrollerini tamamen devre dışı bırakır ve çalışma yapılandırmasında bırakılması mümkün değildir.
5. Sertifika sorununu profesyonelce çözün. Copilot uzantısı Node üzerinde çalıştığı için doğru yol, kontrolü devre dışı bırakmak yerine kök CA'lar ile mitmproxy sertifikasını birleştirip NODE_EXTRA_CA_CERTS ortam değişkeni aracılığıyla belirtmektir. IDE'yi yeniden başlatmanız gerekir: değişken, süreç başlatıldığında okunur.
6. Akışı bir dosyaya yazın. Gerçek zamanlı olarak gözle bakmak faydasızdır - dakikada onlarca istek gelir. --set save_stream_file=flows.dump seçeneğini etkinleştirin ve her şeyi toplamak istemiyorsanız, --set save_stream_filter=... ile örneklemeyi sınırlayın. Daha sonra dosya rahatça çevrimdışı incelenebilir.
7. İstek gövdesinde arama yapın, URL'de değil. Pratik bir yöntem: test deposuna benzersiz bir dize içeren bir kanarya dosyası yerleştirin (örneğin, CANARY_9f3c_DO_NOT_SEND), bunu bir editörde açın, yan dosyada çalışın — ve yakalanan gövdelerde kanaryayı arayın. Böylece, istemcinin bağlam toplama gerçek alanını göreceksiniz.

Tuzağa düşebilecek noktalar

Lisans yakalamayı engelleyebilir. Kurumsal Copilot planlarında, "Mevcut Copilot lisansınız, kendinden imzalı sertifikalarla proxy bağlantılarını desteklemiyor" şeklinde bir hata verir. Bu, proxy'nin bir hatası değildir - istemci, kendinden imzalı CA üzerinden çalışmayı kasıtlı olarak reddeder. Bu, sistem düzeyinde güvenilir bir sertifika veya Node için PEM derlemesi ile çözülebilir; eğer kuruluş politikası bunu yasaklıyorsa, denetimi bir yönetici ile onaylamak zorundasınız, aşmak değil.

Pinning ve QUIC. Bazı istemciler, normal bir proxy'nin göremeyeceği QUIC üzerinden HTTP/3 kullanıyor. Eğer yakalama etkinleştirildikten sonra uygulama "çalışıyor ama günlük boş" görünüyorsa - neredeyse her zaman sebep budur: test süreci için UDP/443'ü engelleyin ve istemci HTTP/2'ye geri dönecektir.

Telemetri ve yük farklı yollarla gider. Tek bir uç nokta üzerinden "hiçbir şey gitmiyor" sonucuna varmayın: sürecin eriştiği tüm ana bilgisayarların listesini gözlemleyin, yalnızca belgelerde bahsedilenleri değil.

Hukuki çerçeve. Trafiği kendi makinenizde ve hesabınızda yakalamak mümkündür. Başkasının çalışma dizüstü bilgisayarını sahibinin bilgisi olmadan dinlemek başka bir hikayedir ve hiçbir "güvenlik" bunu haklı çıkarmaz.

Sonuçlarla ne yapmalı

Eğer denetim, isteklere gereksiz dosyaların girdiğini gösterdiyse, standart araçlar şu şekilde görünmektedir - ve her birinin belirgin bir sınırlaması vardır.

• İçerik hariç tutma. GitHub'un resmi mekanizması, Copilot'un belirtilen yolları kullanmasını yasaklar. Sadece Business ve Enterprise planlarında mevcuttur, Copilot ayarlarında yönetici tarafından yapılandırılır, VS Code, Visual Studio ve JetBrains'te desteklenir; Xcode, Eclipse ve Vim/Neovim'de yalnızca satır içi öneriler için geçerlidir.
• En büyük açık - ajan modu. Belgeler, Copilot Chat'teki Edit ve Agent modlarında hariç tutmaların desteklenmediğini açıkça belirtmektedir; yani asistanın dosyalar arasında dolaşırken, yapılandırmaları okurken ve komutları çalıştırırken platform filtrelemesi uygulanmaz. Eğer içerik hariç tutmayı tek engel olarak görüyorsanız - ajan modunda engel yoktur.
• .gitignore koruma sağlamaz. Yaygın bir yanlış anlama: Git indeksinden hariç tutmak, asistanın bağlamından hariç tutmak anlamına gelmez.
• Kurumsal minimum. Gizli bilgiler, kodun yanında .env dosyasında değil, gizli bilgiler yöneticisinde olmalıdır; asistan sohbeti, bağlantı dizelerini eklemek için bir yer değildir; yerel geçmişi, shell geçmişini temizlediğiniz gibi temizlemek gerekir.

Burada proxy nerede ve neden size lazım

Yakalamanın pratik bir devamı vardır. Öncelikle, upstream modu, asistanın tüm trafiğini kontrol edilen bir çıkış düğümünden geçirmeye olanak tanır: hem istekleri görürsünüz hem de hangi adresten çıktıklarını kontrol edersiniz. Bu, asistan API'sinin bölgenizden erişilemediği veya kurumsal politikanın sabit bir çıkış IP'si gerektirdiği durumlarda gereklidir - bu tür senaryolar için sabit veri merkezi proxy'leri uygundur.

İkincisi, aynı stand otomasyonu hata ayıklamak için de kullanılabilir: AI ajanı kendi başına web sitelerinde dolaşırken, yakalama, gerçekten hangi başlıkları gönderdiğini ve korumaların neyle yakaladığını gösterir. Bu bağlantıyı Playwright ve MCP'deki AI ajanları için proxy'ler konulu makalede inceledik - burada ajan senaryoları için adres türü seçimi hakkında, rezidans IP'si gerektiren durumlar hakkında bilgi bulunmaktadır.

Eğer daha önce mitmproxy kurmadıysanız, HTTPS yakalama için temel ayarlarla başlayın - bu, mitmproxy ile trafik yakalama kılavuzumuzda ayrıntılı olarak açıklanmıştır ve bunun üzerine local ve upstream modlarını ekleyebilirsiniz.

Sonuç

AI asistanının trafik denetimi, paranoya değil, bir mühendislik hijyenidir ve bir akşamda bir kez yapılır. Copilot incelemesi net bir tablo ortaya koydu: istemci bağlamı geniş bir şekilde topluyor, gizli bilgiler bu bağlama kodla eşit şekilde giriyor, yerel geçmiş açık metin olarak saklanıyor ve standart hariç tutmalar tam olarak en tehlikeli modda - ajan modunda çalışmıyor.

Belgeleri değil, trafiği kontrol edin. local modunda mitmproxy'yi başlatın, depoya bir kanarya yerleştirin, akışı bir dosyaya toplayın ve gözlerinizle neyin makinenizden çıktığını görün. Sonrasında çözüm basit: ya bu miktar aktarımı bilinçli olarak kabul edersiniz ya da gizli bilgileri, başka bir sunucu görmeden önce çalışma ağacının dışına çıkarırsınız.