Copilot Cloud Agent İçin Kurumsal Firewall: Kontrol Sizde
Geçen hafta bir müşteri toplantısında yine aynı cümleyi duydum: “Copilot’u açacağız ama internet erişimi biraz ürkütüyor.” Açık konuşayım, bu çekince boş değil (eh, fena değil). Ajan tabanlı sistemlerde mesele sadece ne ürettiği değil, nereye baktığı ve hangi kapıdan dışarı çıktığı. İşte GitHub’ın Copilot cloud agent için organizasyon seviyesinde firewall ayarlarını getirmesi, tam da bu yüzden önemli.
Ben bunu ilk kez bir bankacılık projesinde, 2024 sonlarında çok net hissettim. Repository bazında bırakılmış güvenlik kararları büyüdükçe dağınık hâle geliyor; biri allowlist ekliyor, diğeri kapatıyor, üçüncüsü “şimdilik böyle kalsın” diyor. Sonra işler karışıyor. Organizasyon düzeyinde kontrol gelince iş biraz toparlanıyor… hatta baya toparlanıyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Asıl değişen şey ne?
Copilot cloud agent zaten kendi içinde bir agent firewall ile geliyor. Bu firewall’un görevi basit gibi görünüyor ama kritik: Copilot’un internete nasıl çıkacağını sınırlamak, prompt injection riskini azaltmak ve veri sızıntısı ihtimalini düşürmek. Yanı ajan kafasına göre her yere bakmasın; sadece izin verilen yerlere gitsin.
Bence, Önceden bu ayarlar repository admin’lerinin elindeydi. Küçük ekipler için fena değildi, iş görüyordu. Ama enterprise tarafta düşünün: yüzlerce repo, farklı ekipler, farklı güvenlik ihtiyaçları… Orada repository bazlı yönetim bir noktadan sonra yetmiyor. Azure tarafında yıllardır gördüğüm klasik problem bu aslında: merkezî politika olmadan ölçek büyüyünce kontrol dağılır.
Bunu biraz açayım.
Yeni gelen organizasyon ayarlarıyla GitHub admin’leri artık tüm repolar üzerinde ortak bir temel belirleyebiliyor. İstersen firewall’u herkes için açıp kapatıyorsun, istersen repo kararına bırakıyorsun. Aynı mantık recommended allowlist için de geçerli. Bir de üstüne organizasyon genelinde custom allowlist ekleyebiliyorsun; mesela iç paket registry’si gibi kaynaklar için.
Kurumsalda en büyük rahatlık şu: güvenlik politikası tek tek repolarda unutulmuyor, organizasyon düzeyinde standartlaşıyor. Bu küçük gibi dürüyor ama sahada gün kurtarıyor.
Neden şimdi önemli öldü?
İşin aslı şu ki ajanlar yaygınlaştıkça ağ erişimi meselesi daha görünür hâle geldi. Kod yazan bir yardımcıdan bahsetmiyoruz sadece; gerektiğinde araçlara erişen, dış servislere bakan, veri çeken bir yapıdan söz ediyoruz. Böyle olunca “internet açık mı kapalı mı?” sorusu çocuk oyuncağı olmaktan çıkıyor.
Bi saniye — Benzer bir konuyu geçen yıl İstanbul’da bir üretim firmasında yaşadık (ciddiyim). Copilot benzeri akıllı otomasyonlarla test senaryosu üretmek istiyorlardı ama dış bağlantılar konusunda hukuk ve güvenlik aynı anda frene bastı. O projede öğrendiğim şey netti: iyi niyetli kullanım bile yanlış sınırlarla risk yaratabiliyor.
Bence, Bir de saldırı tarafı var tabiî. Prompt injection dediğimiz şey artık teori değil; kötü niyetli içerik ajanı kandırıp önü istenmeyen yerlere yönlendirebiliyor. Eğer firewall ve allowlist düzgün kurulmazsa ajan sizin fark etmediğiniz kaynaklara uzanabiliyor… sonra açıklaması zor oluyor.
Küçük ekipte başka, enterprise’da başka
Küçük bir startup için default “her repo kendi karar versin” yaklaşımı yeterli olabilir. Çünkü ekip azdır, repo sayısı sınırlıdır ve değişiklikler hızlı takip edilir. Hatta bazen fazla merkezileştirme işleri yavaşlatır; bunu da söyleyeyim.
Enterprise tarafta işe tablo değişiyor. Finans kuruluşu, telekom veya kamu tarafında merkezî policy olmazsa her ekip kendi mini evrenini kuruyor (buna dikkat edin). Bir süre sonra uyumluluk raporu çıkarmak eziyete dönüşüyor. AZ-305 çalışırken bu tarz tasarım kalıplarını çok düşünmüştüm: kontrol noktası nerede olmalı? Cevap çoğu zaman kullanıcıya yakın değil, yönetime yakın oluyor. Daha fazla bilgi için GitHub Copilot CLI Kullanımını Artık Kişi Bazında Görmek Mümkün yazımıza bakabilirsiniz.
- Tüm repolarda aynı güvenlik tabanı isteniyorsa
- İç servisler için ortak allowlist kullanılacaksa
- Repo admin’lerinin istediği gibi kural eklemesi sınırlandırılacaksa
- Pilot sonrası kontrollü yaygınlaştırma planlanıyorsa
Yönetim modeli nasıl çalışıyor?
Küçük bir detay: GitHub burada üç ana alan açıyor gibi düşünün: (en azından benim deneyimim böyle) Daha fazla bilgi için Microsoft Agent Framework 1.0: Ajanlar Artık Ciddileşti yazımıza bakabilirsiniz.
| Ayar | Ne yapıyor? | Saha yorumu |
|---|---|---|
| Firewall açık/kapalı | Ajanın internet erişimini temel seviyede kontrol eder | En sert ve en net politika katmanı |
| Recommended allowlist | Tavsiye edilen erişimleri topluca yönetir | Denge arayan ekipler için iyi başlangıç |
| Custom allowlist + repo yetkisi | Kurum genelinde ya da repo bazında özel izin verir | Mikro hizmet dünyasında kurtarıcı olabilir ama dikkat ister |
Bence burada en güzel detay şu: varsayılan davranış değişmiyor, yanı her şey yine repo bazında karar verilebilir hâlde başlıyor (inanın bana). Bu iyi haber çünkü mevcut yapıları aniden kırmıyor. Kötü haber mi? Şimdilik çok dramatik yenilik bekleyenler için “devrim” değil; daha çok düzgün bir kurumsallaştırma hamlesi. Google Vids’e Gelen Yapay Zekâ Hamlesi: Ücretsiz Video Üretimi yazımızda bu konuya da değinmiştik.
Bunu Azure Policy’ye benzetiyorum biraz — önce serbest bırakılır, sonra üst katmanda sınırlar çizilir, en sonunda da istisnalar yönetilir. Tabiî birebir aynı şey değil ama mantık akraba.
Sahada ben bunu nasıl okurum?
Lafı gevelemeden söyleyeyim: bu özellik tek başına güvenliği çözmez ama operasyonu kolaylaştırır. Güvenlik ekibiyle platform ekibi arasındaki tartışmayı biraz daha teknik zemine çekiyor.
Logosoft’ta geçtiğimiz aylarda bir SaaS müşterisinde benzer şekilde merkezî governance ihtiyacı çıktı. Ekipler yeni AI destekli iş akışlarını denemek istiyordu ama “kim neyi görebiliyor?” sorusu net değildi. Orada öğrendiğim ders şuydu: önlem erken alınmazsa ölçek büyüdüğünde politika koymak iki kat zorlaşıyor.
E tabiî burada bir hayal kırıklığını da not düşeyim: UI tarafında bazı kurumsal admin ekranları hâlâ fazla kuru geliyor insana (sanki hep aceleye gelmiş gibi). Ayarın kendisi iyi olabilir ama yönetim deneyimi pürüzlü olursa benim gözümde puan kırılıyor.
Kimin işine yarar?
- Siber güvenlik ekipleri: internet çıkışlarını standardize etmek isteyenler.
- Platform mühendisleri: Copilot Cloud Agent’i ölçekli yaymak isteyenler.
- Uyumluluk ekipleri: denetimde “hangi repo neye erişiyor?” sorusuna hızlı cevap vermek isteyenler.
- Küçük ekip liderleri: isterlerse esnekliği koruyup yalnızca birkaç hayatı domain’i izin listesine almak isteyenler.
Bir şey dikkatimi çekti: Küçük startup senaryosunda ben olsam önce dar kapsamlı başlarım; mesela internal package registry dışında hiçbir şeyi açmamaya çalışırım (işin tadı burada kaçabilir ama güvenlik böyle). Sız hiç denediniz mi? Enterprise’da işe önce ortak policy çıkarır, sonra istisnaları yönetirim diye düşünüyorum.
Bunu hangi Copilot haberleriyle birlikte okumalı?
GitHub Copilot Cloud Agent İçin Runner Kontrolü: Kurumsal Düzen Daha fazla bilgi için Copilot SDK: Ajanları Kendi Uygulamana Taşırken Ne Değişiyor? yazımıza bakabilirsiniz.
Copilot Cloud Agent Artık İmzalı Commit Atıyor: Neyi Değiştiriyor? Daha fazla bilgi için GitHub Actions Nisan 2026 Güncellemeleri: Üç Kü… yazımıza bakabilirsiniz.
Daha açık söyleyeyim, bi saniye — GitHub Copilot Verisi Değişiyor: Ne Toplanıyor, Ne Toplanmıyor?
Bunları birlikte okuyunca resim daha net oturuyor aslında… runner kontrolü ayrı bir katman, imzalı commit ayrı bir güven sinyali veriyor. Şimdi firewall ayarıyla birlikte ajanın çevre davranışı daha okunur hâle geliyor. Tek tek bakınca küçük duran parçalar, yan yana gelince baya anlamlı oluyor.
Nerede güçlü, nerede eksik?
Güçlü taraf: merkezî yönetim getiriyor. Kurumsalda standart oluşturmayı kolaylaştırıyor.
Zayıf taraf: fazla merkezî kurgu bazı ekiplerin hızını kesebilir.
Denge noktası: policy’yi sert tutup kilit repolara kontrollü istisna vermek.
# Örnek düşünce modeli
Organization Policy:
Firewall = Enabled
Recommended Allowlist = Enabled
Custom Allowlist = Org-wide
Repo Admin Custom Entries = Disabled
# Pilot grubu:
# — Sadece birkaç takım
# — İç servis domain'leri
# — Loglama ve audit takibi açık
}
Peki pratikte ne öneririm?
- Pilotu küçük tutun; her repoda açmaya çalışmayın.
- Kritik iç servislerin listesini önceden çıkarın.
- Erişim taleplerini ticket süreciyle bağlayın (rastgele whitelist istemeyin).
- Audit log’ları ilk günden izleyin; sonradan bakınca geç kalmış oluyorsunuz. (bu kritik)
- Ekiplere neden bu kuralın geldiğini anlatın; yoksa herkes bunu “gereksiz engel” sanıyor.
AZ-500 hazırlığında öğrendiğim en faydalı şeylerden biri buydu zaten: teknik kontrol tek başına yetmez, süreç de onun kadar önemli (ben de ilk duyduğumda şaşırmıştım). Güvenlik politikası uygulamaya dökülmediyse kağıt üstünde kalır… o kadar basit maalesef.
Sıkça Sorulan Sorular
Copilot cloud agent firewall nedir?
Copilot cloud agent’in internete hangi koşullarda çıkacağını kontrol eden yerleşik güvenlik katmanıdır (şaşırtıcı ama gerçek). Prompt injection ve veri sızıntısı riskini azaltmaya yardım eder.
Organizasyon adminsiz eski yapı devam eder mi?
Ne yalan söyleyeyim, Evet, varsayılan olarak her repo kendi kararını verebilir şekilde davranış korunuyor. Yanı mevcut düzen hemen bozulmuyor; isterseniz aşamalı geçiş yapabilirsiniz.
Tüm repolar için aynı allowlist zorunlu mu?
Zorunlu değil ama organizasyon genelinde custom allowlist tanımlayabilirsiniz. İhtiyacınıza göre repo bazında serbest bırakma ya da merkezî zorlama seçebilirsiniz.
Bunu küçük ekiplerde kullanmak mantıklı mı?
Neyse, küçük bir detay: Mantıklı olabilir; özellikle iç servis erişimini standardize etmek istiyorsanız işe yarar.Bazen küçük ekiplerde bile hata payını düşürmek değer yaratır.
Büyük kurumlarda en kritik fayda ne olur?
Bence en büyük fayda politika tutarlılığıdır.Bir kere doğru model kurulunca hem denetim kolaylaşır hem de farklı ekiplerin ayrı telden çalması azalır.
Kaynaklar ve İleri Okuma
GitHub Blog duyurusu: Organization firewall settings for Copilot cloud agent
GitHub Docs: Customizing the agent firewall for Copilot cloud agent
Microsoft Learn: Zero Trust security guidance
Bu tip duyurular bana hep aynı şeyi hatırlatıyor: AI araçlarını büyütmek kadar onları doğru çerçevede tutmak da önemli.
Kalabalıkta kaybolmayan sistem kazanıyor.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder