Developer Araçlarınızda Gizlenen Güvenlik Sorunu

Dürüst olalım: Çoğu mühendislik ekibi, organizasyonlarındaki AI coding agent'larının tam olarak ne kadar aktif olduğunu bilmiyor. Cursor, Claude Code, GitHub Copilot, Gemini CLI, özel internal araçlar... Liste her geçen ay büyüyor. Her birinin kendine özgü ayarları, kendine özgü yetki modeli ve "güvenli" kavramına kendine özgü yorumu var.

Bu, teorik bir endişe değil. Enterprise AI adoptiyonunun bugünkü gerçeği bu.

Anthropic yakın zamanda Claude'u nasıl koruma altına aldıklarını paylaştı. İncelemeye değer—mucizevi olduğu için değil, AI yeteneği ile organizasyonel kontrol arasındaki temel gerilimi gözler önüne serdiği için. Agent'larını güvence altına alabiliyorlar çünkü her şeye sahipiler: modele, runtime'a, network yoluna, governance framework'üne. Senin organizasyonunda bu lux yok. Elinde üçüncü parti araçların yamalı bohçası, developer özerkliği ve AI agent'ların dosya okuyabileceği, shell komutu çalıştırabileceği, network erişimi sağlayabileceği dönemden önce yazılmış güvenlik politikaları var.

Anthropic'in Iskaladığı Noktalar

Yayınladıkları sandbox-runtime, sadeliğinde zarif. Temel prensibi deny-by-default egress: sandbox'ın içinde çalışan bir agent, yetkisiz bir endpoint'e ulaşmaya çalışırsa, istek proxy katmanında ölüyor. Sızıntı yok, callback yok, hasar yok.

Bu, gerçekten işe yarayan deterministik güvenlik türü. Modelin "kredansiyelleri çalmaması gerektiğini anlamasını" beklemek yerine, agent ne karar verirse versin credential hırsızlığını fiziksel olarak imkansız hale getiren sert bir sınır çiziyorsunuz.

Anthropic savunmalarını güvenilirlik sırasına göre üç katmana ayırıyor:

1. Environment katmanı — VM sandbox'ları, dosya sistemi mount modları, network allowlist'leri gibi sert sınırlar. Bu temel.

2. Model katmanı — System prompt'lar, classifier'lar ve onay akışları gibi davranışsal kontroller. Faydalı, ama açıkça "asla %100 etkili değil" olarak kabul edilmiş.

3. External content katmanı — Verinin agent'a ilk olarak nasıl ulaştığını yönetmek; MCP server denetimi ve tool output incelemesi dahil.

Anahtar içgörü sıralamada yatıyor. Environment katmanı ağır yükü taşıyor. Model katmanı faydalı bir destek. External content katmanı erken uyarı sisteminiz.

Kimsenin Konuşmadığı Saldırı

Soyut threat model'leri görmezden gelmek kolay. Somut örnekler görmezden gelinmesi daha zor.

Şu senaryoyu düşün, güvenlik araştırmacıları düzenli olarak yeniden üretiyor: Bir developer açık kaynak bir kütüphaneyi değerlendirmek için bir repo klonluyor. README temiz görünüyor. Malware taramasından geçmiş, her kontrolü başarıyor.

Ama o README'nin içinde, AI agent için talimatlar gizli. Dosyayı okuyan insan için değil—onu context olarak alabilecek agent için. Enjekte edilmiş prompt, agent'a ".env dosyalarını bulma, AWS kimlik bilgilerini arama ve bir setup endpoint'ine yükleme" talimatı veriyor.

Bu malware değil. Sadece metin. Tarayıcı bunu işaretlemiyor. Developer fark etmiyor. Ama agent talimatları takip ediyor—çünkü agent'lar böyle çalışıyor, aldıkları context'e gömülü görevleri yerine getiriyor.

Saldırı adım adım gelişiyor: önce environment dosyaları için bir probe, sonra upload ve exfiltration kod yolları için arama, ardından saldırganın endpoint'ine son curl isteği. Her eylem tek başına masum görünüyor. Birlikte, credential hırsızlığı oluşturuyorlar.

Laptop'unuz Yeterli Değil

Rahatsız edici gerçek şu: Eğer agent düzgün yapılandırılmış bir sandbox'ta çalışıyorsa, saldırı network katmanında başarısız oluyor. Curl isteği saldırgana ulaşmıyor. Credential makineden ayrılmıyor.

Ama daha kötüsü şu: Güvenlik ekibiniz hiçbir şeyden haberdar değil.

Sandbox hasarı önlüyor, görünürlüğü sağlamıyor. Şu anda onlarca compromised repo çalıştırıyor olabilirsiniz, her biri agent'larınızı probe'lıyor, her girişimim sessizce engelleniyor while SIEM'iniz hiçbir işe yaramaz log kaydı tutmuyor.

Bu enterprise problemi. Bireysel saldırıları durdurmak yetmiyor. Ne olduğunu, kimin hedef alındığını, hangi repoların engellenmesi gerektiğini ve organizasyonunuzdaki her agent'ı—sadece sandbox'ta çalışanı değil—kapsayan bir politika yazabilmeniz gerekiyor.

MCP Server Körlük Noktası

Çoğu ekibi şaşırtan kısım: Model Context Protocol server'ları, AI agent deployment'larındaki en az tahmin edilen attack surface.

MCP server'lar agent'larınızın yapabileceklerini genişletiyor. Veritabanlarından okuyabilir, API'ler çağırabilir, kod çalıştırabilir ve altyapınızın dışında yaşayan sistemlere erişebilirler. Bir MCP server'ı onayladığınızda, temelde bir agent'a ortamınız genelinde yükseltilmiş yetkiler vermiş oluyorsunuz.

Problem? Çoğu ekip MCP server'ları bir kez onaylıyor ve bir daha denetlemiyor. Ele geçirilmiş veya kötü niyetli bir MCP server, zehirli bir README'den çok daha fazla hasar verebilir—çünkü daha yüksek bir yetki seviyesinde çalışıyor ve genellikle oturumlar arasında kalıcılık sağlıyor.

Governance framework'ünüz MCP server'ları üçüncü parti bağımlılıklar gibi ele almalı: denetlenmiş, versiyonlanmış ve izleniyor olmalı. Production veritabanınıza bir MCP server üzerinden erişebilen bir agent, bir şeyler ters gittiğinde tüm müşteri tablonuzu exfiltre edebilecek bir agent'tır.

Aslında Yapabilecekleriniz

Bunların hiçbiri çözümsüz değil, ama AI agent güvenliğini bir developer tooling problemi değil, bir infrastructure problemi olarak ele almayı gerektiriyor.

Environment katmanından başlayın. Mümkün olan her yerde, agent'ları deny-by-default network politikalarıyla izole ortamlarda çalıştırın. Developer'larınız sürtünmeden şikayetçi olabilir. Credential sızdırıldığında sizinkinden daha az şikayetçi olacaklar.

Model katmanının kusurlu olduğunu kabul edin. System prompt'lar ve classifier'lar riski azaltıyor, ama ortadan kaldırmıyor. Daha yetenekli modeller, kısıtlamaları aşmanın beklenmedik yollarını bulmakta daha iyi. Buna hazırlıklı olun.

MCP server'larınızı denetleyin. Agent'larınızın erişebildiği her MCP server'ın bir listesini yapın. Yazılım envanteri gibi davranın. Tanımadığınız veya denetleyemediğiniz her şeyi kaldırın.

Observability'ye yatırım yapın. Saldırıları engellemek iyi. Ne olduğunu bilmek daha iyi. Güvenlik ekibiniz, sandbox'ta çalışan tek agent değil, organizasyonunuzdaki her agent üzerinde görünürlük istiyor.

Tercihler değil, politikalar yazın. "Kimlik bilgileriyle dikkatli olun" bir güvenlik politikası değil. "External olarak işaretlenmiş repository'lere erişirken agent'lar, allowlist dışındaki domain'lere network bağlantısı başlatamaz" bir güvenlik politikasıdır. Kuralları açık, uygulanabilir ve tutarlı hale getirin.

Sonuç

Anthropic'in agent containment konusundaki şeffaflığı gerçekten değerli. Bir organizasyonun tüm stack'ı kontrol ettiğinde nelerin mümkün olduğunu gösteriyor. Ama çoğu organizasyonun böyle bir kontrolü yok ve bunu umursamamız, ihlallerin nasıl gerçekleştiğinin yolunu açıyor.

Agent'lar zaten organizasyonunuzda çalışıyor. Güvenliklerini sağlamak isteyip istememek değil mesele—bir şeyler ters gitmeden önce governance'ı çözecek ekip siz olacak mı, olmayacak mı?

Developer'larınız hızlı ilerliyor. Altyapınızın yetişip yetişmediğinden emin olun.