Özet: GitHub Copilot uygulaması ve Copilot CLI, 2 Eylül 2026’dan itibaren kurumların içerik hariç tutma kurallarına uyuyor. Bu değişiklik hassas dosyaların ajan bağlamına girmesini azaltıyor; ancak kural, sır yönetiminin veya erişim kontrolünün yerine geçmiyor.

Bir yapay zekâ kodlama aracına “bu depoyu incele” dediğinizde asıl güvenlik sorusu modelin ne kadar iyi kod yazdığı değildir. Aracın hangi dosyalara bakabildiği, hangi parçaları bağlam olarak taşıdığı ve hangi işlem modunda çalıştığı daha önemlidir. Gizli anahtarın kendisi silinmiş olsa bile müşteri eşleştirmeleri, üretim yapılandırmaları, fiyatlandırma mantığı veya henüz duyurulmamış ürün dosyaları gereksiz yere bağlama girebilir.

GitHub’ın 2 Eylül 2026 tarihli duyurusuna göre Copilot uygulaması ve Copilot CLI artık enterprise, organization ve repository yöneticilerinin tanımladığı content exclusion politikalarını uyguluyor. Özellik Copilot Business ve Copilot Enterprise müşterilerine sunuluyor. Bu, özellikle ajanların birden fazla dosyayı kendiliğinden taradığı iş akışlarında önemli bir sınır.

Content exclusion tam olarak neyi değiştiriyor?

GitHub’ın kavram belgesi, hariç tutulan içeriğin satır içi önerilerde kullanılmaması, başka dosyalardaki önerileri beslememesi, Copilot yanıtlarına girmemesi ve Copilot code review tarafından incelenmemesi hedefini açıklıyor. Yeni duyurunun farkı, bu politikanın Copilot uygulaması ve komut satırı istemcisine de yayılması.

Bir Türkiye merkezli yazılım şirketi için pratik örnek düşünelim. Depoda production/, sözleşme şablonları, müşteri bazlı yapılandırmalar ve iç denetim notları bulunuyor. Geliştirici Copilot CLI’dan test yazmasını istediğinde bu klasörlerin bağlama girmesine ihtiyaç yoksa, yönetici bunları merkezi politikayla dışarıda bırakabilir. Böylece güvenlik kararı her çalışanın prompt disiplinine bırakılmaz.

Bu bir “veri asla çıkmaz” garantisi değildir

En kritik ayrım burada. GitHub’ın content exclusion sınırlamaları, bazı semantik bilgilerin IDE tarafından dolaylı biçimde sağlanabileceğini; sembolik bağlantılar ile uzak dosya sistemlerindeki depoların mevcut kapsam dışında kalabildiğini söylüyor. Ayrıca IDE’lerdeki Edit ve Agent modları için destek durumu istemciye göre değişiyor. Dolayısıyla “kuralı açtık, artık tüm risk bitti” sonucu çıkarılamaz.

Content exclusion bir bağlam filtresidir. Kasadaki sırları şifrelemez, yanlışlıkla commit edilmiş anahtarı döndürmez, depo yetkilerini daraltmaz ve dışarı sızmış bir değeri geçersiz kılmaz. Hassas değerler yine secret manager’da tutulmalı; üretim kimlik bilgileri kaynak kod deposuna hiç girmemeli; ajanların yazma ve çalıştırma yetkileri ayrıca sınırlandırılmalıdır. Bu yaklaşım, uygulama izinlerinde en az yetki ilkesinin kod ajanlarına uyarlanmış hâlidir.

Hangi dosyalar aday olmalı?

Her şeyi hariç tutmak aracı işlevsiz bırakır; hiçbir şeyi hariç tutmamak ise gereksiz bağlam açar. Dosyaları isimlerine göre değil, içerdikleri risk ve geliştirme ihtiyacına göre sınıflandırın:

  • Kesin dışarıda: gerçek müşteri verisi, üretim anahtarı, özel sertifika, bordro, hukuk yazışması ve olay müdahale notları.
  • Varsayılan dışarıda: canlı ortam yapılandırması, henüz açıklanmamış yol haritası, fiyatlandırma kuralları ve güvenlik test çıktıları.
  • Koşullu: sentetik veri, şema, API örneği ve anonimleştirilmiş log; görev için gerçekten gerekliyse açılabilir.
  • Genellikle açık: herkese açık dokümantasyon, test iskeleti, kod standardı ve örnek proje.

Kurulumdan sonra yapılacak 20 dakikalık test

  1. Test deposuna benzersiz fakat gerçek olmayan bir işaret cümlesi içeren restricted-test/ klasörü ekleyin.
  2. Klasörü repository veya organization düzeyindeki hariç tutma kuralına alın.
  3. Politikanın yayılmasını bekleyin. GitHub, IDE’lerde değişikliğin etkili olmasının 30 dakikaya kadar sürebileceğini belirtiyor; gerekirse istemciyi yeniden yükleyin.
  4. Copilot uygulaması ve CLI’da, yasaklı cümleyi veya dosyanın içeriğini gerektiren masum bir soru sorun. Araç içeriği aktarmamalı.
  5. Aynı deneyi izin verilen bir test dosyasıyla yapın. Böylece “araç çalışmıyor” ile “kural çalışıyor” durumlarını ayırın.
  6. Sembolik bağlantı, uzak çalışma alanı ve IDE Agent modu kullanıyorsanız bunları ayrı test vakası olarak kaydedin.

Gerçek sırla test yapmayın. Denetim için benzersiz sentetik bir dize yeterlidir. Sonucu ekran görüntüsünden ibaret bırakmak yerine tarih, istemci sürümü, politika kapsamı ve test komutuyla birlikte kayıt altına alın.

Politika sahipliğini de belirsiz bırakmayın. Repository yöneticisi yalnız kendi deposunu, organization ve enterprise sahipleri daha geniş kapsamı yönetebilir. Kuralı değiştirebilen hesaplarda güçlü kimlik doğrulama kullanın ve son değişikliği düzenli inceleyin. Yeni bir depo şablonu oluşturulduğunda hassas klasör kalıplarının otomatik gelmesi, sonradan elle düzeltme ihtiyacını azaltır. Buna karşılık genel bir config/** kuralı, geliştiricinin görev için gerekli örnek yapılandırmayı da görünmez kılabilir. Bu nedenle her istisnanın güvenlik gerekçesi ve iş etkisi birlikte yazılmalıdır.

Türkiye’de ekip yöneticisi için kısa kontrol listesi

KVKK kapsamındaki kişisel veriler, müşteri sözleşmeleri ve kurum içi ticari sırlar aynı depoda bulunuyorsa önce veri mimarisini düzeltin; hariç tutma kötü bir depo düzenini güvenli yapmaz. Copilot koltuğu atanan ekipleri, yetkili yöneticileri ve depoları üç ayda bir gözden geçirin. Kural değişikliklerinin kim tarafından yapıldığını denetim kaydından kontrol edin.

Son ölçüt basittir: Bir ajan yalnız görev için gereken en küçük bağlamı görebilmeli. Content exclusion bu hedefe yaklaşmak için yararlı bir yönetim katmanı oldu. Fakat sağlam güvenlik; veri minimizasyonu, depo yetkisi, sır taraması, çalışma aracı izinleri ve düzenli sentetik testlerin birlikte uygulanmasıyla oluşur.