GitHub push protection artık Anthropic kullanıcı ve servis hesabı API anahtarlarını varsayılan olarak engelliyor

GitHub 13 Ekim'de neyi değiştirdi

13 Ekim 2026 tarihli bir GitHub changelog kaydı, secret scanning'e iki yeni Anthropic gizli bilgi türü ekliyor: anthropic_user_api_key ve anthropic_service_api_key. Gabriel Anhaia'nın dev.io analizinde aktarıldığına göre her iki tür de push protection'ın varsayılan olarak engellediği setin parçası haline geldi; yani bu anahtarları içeren commit'ler, secret scanning'in etkin olduğu her depuda — ücretsiz genel depular dahil — otomatik olarak durduruluyor ve tespitler, taramanın açık olduğu her yerde uyarı olarak görünüyor.

Aynı kayıt bir Cloudsmith API anahtarı dedektörünü de içeriyor ve Marketing Cloud API OAuth2 token'ları için Salesforce'u secret scanning ortağı olarak ekliyor; böylece genel depularda bulunan ortak gizli bilgileri iptal veya rotasyon için ihracatçıya iletiliyor. Anthropic programda yeni değil: GitHub, 20 Ağustos 2024'te onu ortak olarak açıklamıştı ve desteklenen desenler tablosunda zaten anthropic_api_key, anthropic_admin_api_key ve anthropic_session_id yer alıyordu. Anthropic'in anahtar güvenliği dokümantasyonu, genel depularda açığa çıkan anahtarların otomatik olarak devre dışı bırakıldığını ve etkilenen kullanıcının e-postayla bilgilendirildiğini söylüyor.

Bu iki anahtar türü neden önemli

Yeni dedektörler, Anthropic'in anahtar oluşturmayı nasıl yapılandırdığını izliyor. API dokümantasyonu, anahtar oluştururken bir tür seçmenizi istiyor: kişisel bir anahtar sahibi adına hareket eder ve o kişi bir organizasyondan ayrıldığında çalışmayı bırakır; servis hesabı anahtarı ise CI pipeline'ları, üretim servisleri ve agent'lar gibi paylaşılan iş yükleri için tasarlanmıştır. Özetle rehber şudur: bireysel geliştirme için kişisel anahtarlar, paylaşılan her şey için servis hesabı anahtarları. Üçüncü ve daha eski bir tür olan workspace anahtarı, sahibi olmayan ve oluşturucusu ayrıldıktan sonra da çalışmaya devam eden eski bir anahtar olarak tanımlanıyor. Dev.to yazısının da belirttiği gibi, GitHub'ın "user" dedektörünü Anthropic'in "personal" anahtarıyla eşleştirmek bir yorumdur; iki şirket de bu eşlemeyi açıkça belirtmiyor.

Bir engel neyi kapsıyor ve nasıl aşılabilir

Dev.to yazısında atıf yapılan GitHub push protection dokümantasyonuna göre bu kontrol; komut satırı push'ları, GitHub web arayüzü üzerinden yapılan commit'ler, dosya yüklemeleri, REST API istekleri ve — yalnızca genel depular için — GitHub MCP sunucusu üzerinden yapılan etkileşimler için geçerli. Bu son durum, GitHub'a düz git yerine MCP üzerinden yazan kodlama agent'ları için önemli.

Bir engel kesin değildir. Yazma erişimi olan herkes bir bypass gerekçesi seçerek engeli aşabilir ve bu seçimin sonuçları vardır: bir gizli bilginin testlerde kullanıldığını veya yanlış pozitif olduğunu belirtmek uyarıyı kapatır, düzeltmeyi ertelemek ise uyarıyı açık bırakır. Depu düzeyinde push protection etkinse, her bypass denetim günlüğüne kaydedilir ve sahiplere, güvenlik yöneticilerine ve depu yöneticilerine e-postayla iletilir. Yalnızca varsayılan kullanıcı düzeyi koruma varken, bir bypass hiç uyarı üretmez — yani varsayılan ayarlı bir genel depuda, bir geliştiricinin kimlik bilgileriyle çalışan bir agent, engellenen bir anahtarın geçişine izin verir ve arkada incelenecek hiçbir kayıt kalmaz. Ayrıca push protection müdahalesi push anında gerçekleştiği için, anahtar yerel geçmişte her durumda kalır.

Özel depu boşluğu

Koruma, erişimi farklı iki biçimde geliyor. Kullanıcılar için push protection varsayılan olarak açıktır ve dokümantasyona göre genel depulara uygulanır. Depular için push protection ise GitHub Secret Protection gerektirir ve bir yönetici, sahip veya güvenlik yöneticisi etkinleştirene kadar kapalı kalır. Pratik sonuç: varsayılan ayarlardaki bir özel depu, bu Anthropic anahtar türleri için — ya da başka herhangi bir tür için — hiçbir engel almaz. 13 Ekim değişikliği varsayılan engelleme listesini uzatıyor; daha önce kapalı olan hiçbir yerde korumayı açmıyor.

Pratik adımlar

• GitHub Secret Protection'ın kullanılabilir olduğu her yerde organizasyon veya depu düzeyinde push protection'ı etkinleştirin; biri yapmadığı sürece kapalı kalır.

• Agent'lara ve CI'a servis hesabı anahtarları verin; böylece sızan bir otomasyon anahtarı, bir kişinin anahtarına dokunmadan iptal edilebilir ve kişisel anahtarlar sahipleri ayrıldığında doğal olarak ölür.

• .env dosyalarını ağaçtan uzak tutun ve mevcut geçmişi denetleyin. Anthropic anahtarları sk-ant- ile başlar, bu da git log grep'ini kullanılabilir bir ilk adım haline getirir. Gerçek bir anahtar hiç push edildiyse, önce Claude Console'da döndürün — geçmişi yeniden yazmak, birinin zaten kopyaladığı bir anahtarı geri çağıramaz.

Neden önemli

AI kimlik bilgileri artık rutin çalışma malzemesi haline geldi: agent'lar API anahtarı tutuyor, geliştirici kimlik bilgileriyle push ediyor ve git yerine giderek daha fazla MCP üzerinden GitHub'a yazıyor. Bu değişiklik, tam da bu iş akışına yönelik varsayılan güvenlik ağının iki boşluğunu daha kapatıyor — ancak ağda hâlâ bilinen delikler var: varsayılan ayarlardaki özel depular, genel depularda günlüğe geçmeyen bypass'lar ve shell geçmişi gibi git dışındaki her şey. Anthropic API'lerine karşı agent çalıştıran ekipler bu engeli bir güvenlik ağı olarak görmeli, bir politika olarak değil.