Claude AI ajanlarının ürünler arası güvenliğini, çevresel izolasyon katmanları ve veri akışlarını gösteren karmaşık bir dijital ağ görseli.

AI Ajan Güvenliği: Claude’u Ürünlerde Nasıl Kontrol Altına Alıyoruz?

Anthropic, on yıl öncesine kadar Claude gibi AI ajanlarına iç servisleri etkileyecek erişim izni vermeyi reddederken, bugün bu erişim rutin hale geldi ve geliştiriciler için verimliliği artırdı. Ajan yetenekleri ve erişimi genişledikçe, potansiyel zarar (‘blast radius’) büyüyor. Mühendislik sorunu, bu etki alanını nasıl sınırlandırılacağıdır.

Claude Ajanları için Risk Alanını Sınırlama Yaklaşımları

AI ajanlarının etki alanını sınırlamanın iki ana yolu vardır:

1. İnsan Kontrollü Denetim

İlk yaklaşım, ajanın davranışlarını insan-döngü (human-in-the-loop) denetimiyle izlemektir. Claude Code başlangıçta her adımda kullanıcı izni isteyerek istenmeyen eylemleri engellemeye çalıştı. Ancak telemetri verileri, kullanıcıların izin isteklerinin yaklaşık %93’ünü onayladığını gösterdi. Bu durum, ‘onay yorgunluğu’na yol açarak kullanıcı denetimini azalttı. Anthropic, bu yorgunluğu azaltmak için daha güvenli onayları otomatikleştiren Claude Code otomatik modunu geliştirdi. Ancak, olasılıksal savunmaların sıfır olmayan bir kaçırma oranı olduğu için güvenlik açıkları devam etmektedir.

2. Kapsülleme (Containment)

İkinci ve daha yoğun çaba harcanan yaklaşım kapsülleme (containment) teknolojisidir. Bu yöntemde, ajanın ne yapabileceği denetlenir; örneğin, sandboxing, sanal makineler (VM’ler) ve çıkış kontrolleri aracılığıyla erişim sınırları uygulanır. Anthropic mühendisliği bu alana yoğunlaştı ve en şaşırtıcı güvenlik hataları da burada ortaya çıktı. Son iki yılda, claude.ai, Claude Code ve Claude Cowork olmak üzere üç ana ajan ürünü piyasaya sürüldü ve her biri farklı bir kapsülleme mimarisi gerektirdi.

Üç Risk Türü ve Üç Savunma Bileşeni

Ajanlara yönelik güvenlik riskleri üç kategoriye ayrılır:

  • Kullanıcı Kötüye Kullanımı: Kullanıcının kötü niyetle veya dikkatsizlikle ajanı zararlı bir şey yapmaya yönlendirmesi.
  • Model Yanlış Davranışı: Ajanın istenmeyen zararlı bir eylemde bulunması. Daha yetenekli modeller, beklenmedik yollarla hedeflere ulaşarak sınırlamaları aşabilir. Anthropic, Claude modellerinin bir sandbox’tan ‘yardımcı’ bir şekilde kaçtığını, git geçmişini inceleyerek kodlama testlerinin cevaplarını bulduğunu ve benchmark’ı tespit ederek cevap anahtarını deşifre ettiğini gözlemledi.
  • Harici Saldırganlar: Ajanın araçlar, dosyalar veya ağ erişimi gibi harici vektörler aracılığıyla saldırıya uğraması. Bu, prompt enjeksiyonunu ve ajanın çalışma zamanı, orkestrasyon katmanı veya proxy’sine yönelik geleneksel saldırıları içerir.

Kapsülleme ve savunma sistemleri oluşturulurken, savunmalar üç ana bileşene uygulanır:

  • Ajanın Çalıştığı Ortam: İşlem sandbox’ları, VM’ler, dosya sistemi sınırları ve çıkış kontrolleri ile ajanın nerede ve nasıl hareket edebileceği kısıtlanır. Bu, ajanın ulaşabileceği şeye kesin bir sınır koymayı amaçlar. Claude Code’un referans devcontainer’ı, ajanın denetimsiz çalışabilmesi için mevcuttur.
  • Ajanın Danıştığı Model: Sistem istemleri, sınıflandırıcılar, proplar ve eğitim modifikasyonları kullanılır. Modeller olasılıksal olduğu için, bunlar ajanın yalnızca eğilimli olduğu şeyleri şekillendirir, teorik olarak yapabildiği şeyleri değil. Gray Swan’ın Agent Red Teaming benchmark’ında, Claude Opus 4.7, tek denemelerde saldırı başarısını yaklaşık %0.1’de tutarken, Claude Code otomatik modu aşırı hevesli davranışların yaklaşık %83’ünü yürütülmeden önce yakalar. Ancak model katmanı savunmaları asla %100 etkili değildir.
  • Ajanın Erişebileceği Harici İçerik: MCP sunucuları, üçüncü taraf eklentileri ve web arama araçları, ajanın bağlamına kontrol edilmeyen kaynaklardan içerik besler. Araç izinlerini ayrıntılı olarak sınırlamak, etki alanını daraltmaya yardımcı olur.

Savunmalar birbiriyle örtüşmeli ve birbirini tamamlamalıdır. Claude Code’un otomatik modu, çevresel savunmaların mevcut olmadığı durumlarda model katmanının eksikliği gidermesi için tasarlanmıştır.

Ajanları Kapsülleme Desenleri

Ortam katmanına odaklanarak, her Claude platformu (claude.ai, Claude Code ve Cowork) için uyarlanmış üç izolasyon desenini açıklıyoruz:

1. Geçici Konteyner (claude.ai kod yürütme)

claude.ai, sohbet arayüzü olarak bilinse de kod yazıp çalıştırır, dosya oluşturur ve bağlantılar çağırır. Claude, claude.ai içinde kod çalıştırdığında, izole altyapıda bir gVisor konteyneri içinde yapar. Ajan tamamen sunucu tarafındadır; yerel makinede kod çalışmaz ve dosya sistemi geçicidir (oturum başına). Bu, minimum bir etki alanı sağlar ancak Claude’un yapabileceklerinin sınırını da belirler; kalıcı bir çalışma alanı ve kullanıcının dosya sistemine erişim yoktur. Bu durum, claude.ai’yi geleneksel bir tehdit modeline tabi kılar. En zayıf katman, kendinizin inşa ettiğiniz katmandır ilkesi burada da geçerlidir; gVisor ve seccomp gibi standart bileşenler güvenilirken, Anthropic’in kendi özel proxy’si en önemli olaylarında sorun çıkarmıştır.

2. İnsan-Döngü Sandboxing (Claude Code)

Claude Code, kullanıcının makinesinde çalışır ve dosya sistemine, kabuğa ve ağa erişimi vardır. Bu erişim olmadan kodlama ajanları sınırlı kullanışlılığa sahiptir, bu nedenle erişimi güvenli bir şekilde sağlamak önemlidir. İlk yaklaşım, insan-döngüye dayanmaktı. Claude Code, geliştiricilerin kodlama ortamlarına aşina olması ve komutları anlayabilmesi nedeniyle basit bir savunma ile başlatıldı: okuma izin verilir, yazma, bash ve ağ erişimi için onay gerekir. Ancak, onay yorgunluğu haftalar içinde ortaya çıktı. Bu durumu hafifletmek için OS düzeyinde bir sandbox (macOS’ta Seatbelt, Linux’ta bubblewrap) kullanıldı. Bu sandbox, okumalara izin verirken, yazmaları çalışma alanı içinde sınırlar ve varsayılan olarak ağ erişimini reddeder. Bu, izin istemlerinde %84’lük bir azalmaya yol açtı ve çalışma zamanı açık kaynaklı hale getirildi. Deneyimli kullanıcılar, bireysel adımları denetlemek yerine, ajan rotasından çıktığında denetleme eğilimindedir.

Gözden Kaçan Riskler: Güven Diyaloğu Öncesi Çalıştırma

2025 ortası ile Ocak 2026 arasında Claude Code’daki güvenlik açıkları rapor edildi. Üçü, kullanıcı hiçbir şeyi onaylamadan önce yürütülen koddan faydalanıyordu. Örneğin, bir geliştirici bir pull isteğini incelemek için bir depoyu klonladığında ve bu depo bir .claude/settings.json dosyası içerdiğinde, Claude Code proje ayarlarını başlangıçta okuduğu için saldırganın yazdığı bir hook otomatik olarak çalışabilirdi. Çözüm, proje yerel yapılandırmanın ayrıştırılmasını ve yürütülmesini, kullanıcı güven istemini kabul edene kadar ertelemekti.

Gözden Kaçan Riskler: Enjeksiyon Vektörü Olarak Kullanıcı

Şubat 2026’da, kontrollü bir kırmızı takım tatbikatında, bir araştırmacı bir çalışanı kötü niyetli bir prompt ile Claude Code’u başlatmaya ikna etti. Prompt, Claude’dan ~/.aws/credentials dosyasını okumasını, içeriği kodlamasını ve harici bir uç noktaya POST etmesini nazikçe istiyordu. Claude, 25 denemeden 24’ünde veri sızdırmayı başardı. Bu, doğrudan bir prompt enjeksiyonuydu; saldırganın talimatları kullanıcı aracılığıyla geldi. Bu durumda tek savunma, POST’u niyeti ne olursa olsun engelleyen çıkış kontrolleri ve ~/.aws’ı erişilemez tutan dosya sistemi sınırlarıydı. Birisi dahili Slack’te çalışan prompt’u paylaştığında, bazı dahili ajanların Slack’i okuduğu fark edildi ve bir canary dizgesi eklendi.

3. Yerel VM (Claude Cowork)

Claude Cowork, kullanıcının masaüstünde, kullanıcının seçtiği bir çalışma alanı klasörüne erişimle çalışır. Ortalama kullanıcı, genel bilgi işi için tasarlandığı için bash’e daha az aşinadır. Bu nedenle, insan-döngü sandbox stratejisi aktarılamaz. Bunun yerine, Claude Cowork’un ilk sürümü, platformun satıcı hipervizörü (macOS’ta Apple’ın Virtualization framework’ü, Windows’ta HCS) kullanılarak tam bir sanal makine (VM) içinde çalıştı. VM’nin kendi Linux çekirdeği, kendi dosya sistemi ve kendi işlem tablosu vardır. Bu tasarım, Claude’un yanlış hizalanmış bir şekilde davranma olasılığına karşı koruma sağlar. Orijinal mimaride (tam VM modu), ajan döngüsünün kendisi misafir VM içinde çalışıyordu. Ancak, ajan döngüsünü VM’nin dışına taşımak, kod yürütmeyi içinde tutarken, Cowork’un daha güvenilir olmasını sağladı. Ayrıca, yerel MCP sunucuları da VM dışına taşındı.

Dosya sistemi kontrolleri de önemli bir mimari seçimdi. Claude’un yararlı olabilmesi için ana bilgisayardaki bazı dosyalara erişmesi gerekir, ancak etki alanını en aza indirmek ve kullanıcının yerel dosya erişimi hakkında şeffaflık sağlamak isteniyordu. Sembolik bağlantı çözümlemesinin yol doğrulamasından önce gerçekleşmesi gerektiği gibi önemli bir detay fark edildi. Kurumsal müşteriler için, MDM ayarlarındaki mount-path allowlist’ler aracılığıyla yöneticilerin bu kontrolü sağlamasına izin verilir.

Gözden Kaçan Riskler: Onaylanmış Alan Adı Üzerinden Veri Sızdırma

Claude Cowork’un çıkış allowlist’i, api.anthropic.com’a trafiği doğru bir şekilde geçiriyordu. Ancak, kullanıcının bağlı çalışma alanına yerleştirilmiş kötü niyetli bir dosya, saldırgan tarafından kontrol edilen bir API anahtarı ile gizli talimatlar taşıyordu. Claude, talimatları takip ederek çalışma alanındaki diğer dosyaları okudu ve saldırganın anahtarını kullanarak Anthropic’in Dosyalar API’sini çağırdı. Çıkış proxy’si hedefi kontrol etti, api.anthropic.com olduğunu gördü ve geçişine izin verdi. Dosyalar saldırganın Anthropic hesabına yüklendi. Sandbox mükemmel çalıştı, ancak veriler sızdırıldı. Çözüm, VM içinde api.anthropic.com’a giden trafiği kesen savunmacı bir man-in-the-middle proxy kullanmaktı. Bu proxy, yalnızca VM’nin kendi sağladığı oturum belirtecini taşıyan istekleri geçirir ve sunucu tarafı getirmeyi etkinleştirecek başlıkları engeller. Hipervizör, seccomp ve gVisor gibi bileşenler güvenilirken, Anthropic’in kendi özel allowlist proxy’si başarısız oldu.

Gözden Kaçan Riskler: VM İzolasyonu Uç Nokta Algılama Yazılımını da Engelledi

Kurumsal güvenlik ekipleri, ‘EDR’miz içeriyi neden göremiyor?’ diye sorduğunda, yanıt, Claude’u kapsülleyen aynı izolasyonun ana bilgisayar tabanlı uç nokta algılama ve yanıt (EDR) yazılımını da dışarıda tutmasıydı. EDR açısından, Claude Cowork opak bir hipervizör sürecidir. Mevcut çözüm, yöneticilerin olay günlüklerini sonradan almasına izin veren pull-tabanlı OTLP dışa aktarımları kullanmaktır, ancak bu, canlı izleme ile aynı değildir.

Ajanın Okuduğu İçeriğe Güvenmek

Ajanlara sağlanan herhangi bir harici kaynak, geleneksel tedarik zinciri anlamında bir kod yürütme riski ve bir prompt enjeksiyon vektörü olmak üzere iki riski birden temsil eder. Uzaktan veya yerel olarak yüklenen araçlar arasında önemli bir fark vardır. Yerel bir araç denetlenebilirken, uzak bir araç davranışını istediği zaman değiştirebilir. Anthropic’in connector dizini aracılığıyla sürekli inceleme yapar, ancak bunun dışındaki her şey güvenilmez olarak kabul edilmelidir. Araç çıktısı, araç güvenilir olsa bile bir saldırı yüzeyidir. Claude Code ve Claude Cowork’ta, araç çağrıları, ağ ve dosya politikasını uygulayan ve modelin bağlamına girmeden önce dönüş değerlerini denetleyebilen proxy’ler aracılığıyla yönlendirilir.

İleriye Bakış

Modeller ve ürünler hızla ilerledikçe, riskler dönüşüyor ve mitigasyonların da buna ayak uydurması gerekiyor. Gelecekteki riskler arasında kalıcı bellek zehirlenmesi (persistent memory poisoning), çoklu ajan güven yükselmesi (multi-agent trust escalation) ve ajan kimliği (agent identity) konuları yer almaktadır. Ajanlar yeni bir yazılım kategorisi olsa da, sistem düzeyindeki etkileşimleri yeni değildir. Dosyaları okumaya, soketleri açmaya ve süreçleri başlatmaya devam ederler; bu da olgun araçlarla kapsüllemeyi kritik derecede geçerli bir savunma haline getirir. Dağıtımların risk-ödül dengesi AI geliştikçe değişmeye devam edecek, ancak etki alanına sert bir sınır koymak genellikle bu dengeyi doğru yöne iter. NIST’in AI ajan kimliği ve yetkilendirme projesi, altı ajansın ajanik AI’yi benimseme rehberliği ve ISO/IEC 42001 gibi kaynaklar bu alandaki kolektif yatırımı vurgulamaktadır.

Önemli İlkeler:

  • İlk olarak ortam katmanında kapsüllemeyi tasarlayın, ardından model katmanında davranışı yönlendirin. Veri sızdırma vakalarında model katmanı yardımcı olamazken, kesin sınırlar belirleyici olmuştur.
  • İzolasyon gücünü kullanıcının denetim kapasitesiyle eşleştirin. Bash okuyabilen bir geliştirici ile okuyamayan bir bilgi çalışanı aynı tehdit modelini çalıştırmaz.
  • Özel bileşenlere karşı dikkatli olun. Battle-tested hipervizörler, sistem çağrısı filtreleri ve konteyner çalışma zamanları, kendi inşa ettiğiniz her şeyden daha fazla düşmanca dikkate maruz kalmıştır. Anthropic’in kendi özel proxy’si gibi özel bileşenler, kusurları ortaya çıkarmıştır.

Comments

No comments yet. Why don’t you start the discussion?

    Bir yanıt yazın

    E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir