Bir AI ajanı sandbox’tan yine de çıkabilir: Güven sınırı nerede kırılır?

AI ajanı sandbox’ı, ajanın ürettiği kod ve komutların ana sistemden ayrılmış bir ortamda çalıştırılmasıdır. Bu yalıtım host süreçlerine ve paylaşılmamış dosyalara doğrudan erişim riskini azaltır; fakat yazılabilir çalışma alanını, izinli ağ hedeflerini veya dış araçların yetkilerini kendiliğinden kapatmaz.

Dolayısıyla bir ajan, mikroVM’den teknik olarak kaçmadan da sandbox dışında sonuç doğurabilir: host’un daha sonra çalıştıracağı bir dosyayı değiştirebilir, izinli bir bağlantıdan veri gönderebilir ya da host üzerinde çalışan bir araca işlem yaptırabilir. Güven sınırının nerede kırıldığını anlamak için yürütme, dosya sistemi, ağ, kimlik bilgileri ve MCP araçlarını ayrı ayrı incelemek gerekir.

Sandbox tek bir kutu değil, sınırlar kümesidir

İlk sınır, güvenilmeyen yürütmeyi çevreler. Ajan paket kuruyor, kabuk komutu çalıştırıyor veya kod üretiyorsa bu işlemlerin doğrudan geliştiricinin işletim sisteminde gerçekleşmemesi önemli bir kontroldür. Kullanılan mimariye göre bu ortam bir konteyner, sanal makine veya tarayıcı sandbox’ı olabilir.

Ancak çalışma ortamını ayırmak bütün ajan sistemini yalıtmaz. n8n’in ajan sandbox açıklaması, yürütme ortamının yanı sıra araç kullanımını, veri erişimini, çalışma durumunu ve kalıcı belleği de ayrı sınırlar olarak ele alıyor. Yönü prompt injection veya hatalı bir kararla değişen ajan, hipervizörü aşmadan kendisine verilmiş meşru bir aracı istenmeyen amaçla kullanabilir.

Bu nedenle “ajan sandbox içinde mi?” sorusu eksiktir. Daha yararlı sorular şunlardır: Hangi kaynaklar ortama bağlanmış, hangi hedeflere trafik açılmış, kimlik bilgileri hangi işlemleri mümkün kılıyor ve araç çağrıları gerçekte nerede yürütülüyor?

MikroVM host’u korur, bilerek açılan kanalları değil

MikroVM ayrı bir çekirdek kullanarak sandbox içindeki süreçleri, belleği ve özel dosya sistemini host’tan ayırır. Ajanın sanal makine içinde sudo yetkisine sahip olması bu nedenle host’ta yönetici olduğu anlamına gelmez; yetki VM sınırında kalır. Paylaşılmayan host dosyaları, süreçleri ve Docker daemon’u bu yürütme alanının dışında tutulabilir.

Yine de sınırdan bilerek geçirilen her kaynak ayrı bir temas yüzeyidir. Docker Sandboxes güvenlik modeli, temel güven sınırını mikroVM olarak tanımlarken varsayılan doğrudan bağlama modunda çalışma dizininin okuma-yazma paylaşıldığını, izinli TCP trafiğinin host vekilinden geçtiğini, kimlik bilgilerinin bu vekilde isteklere eklendiğini ve yerel stdio MCP sunucularının host üzerinde çalıştığını belirtiyor. MikroVM paylaşılmayan kaynakları korur; açıkça bağlanan dizinin veya aracın yetkisini ortadan kaldırmaz.

Başlıktaki “çıkış” bu yüzden yalnızca bir hipervizör açığı anlamına gelmez. İzinli bir köprü üzerinden dışarıda kalıcı etki üretmek de güvenlik açısından sandbox sınırının aşılmasıdır; üstelik sistem çoğu zaman teknik olarak tasarlandığı gibi çalışmaktadır.

Yazılabilir çalışma alanı gecikmeli etki yaratabilir

Paylaşılan çalışma alanında yalnızca kaynak kodu bulunmaz. Git hook’ları, CI yapılandırmaları, IDE görevleri, Makefile’lar, paket betikleri ve ajan ayarları daha sonra host veya otomasyon sistemi tarafından çalıştırılabilir. Ajan bunlardan birini değiştirirse dışarıdaki etki dosya yazıldığı anda değil, geliştirici projeyi açtığında ya da pipeline çalıştığında ortaya çıkabilir.

Bu bir sanal makine kaçağı değil, izin verilen dosya kanalının sonucudur. Daha dar bir sınır için host deposu salt okunur bağlanabilir; ajan özel bir kopyada çalışır ve yalnızca incelenen değişiklikler dışarı aktarılır. Doğrudan yazma gerekiyorsa otomatik yürütülen dosyalar ayrıca denetlenmeli, çalışma alanında sır veya üretim anahtarı tutulmamalıdır.

Görevler arasında paylaşılan beceri ve önbellek dizinleri de aynı mantıkla değerlendirilmelidir. Bir sandbox’ın yazdığı talimat veya betik daha sonra başka bir ajan tarafından okunuyorsa ayrı mikroVM’ler kullanılsa bile bu kalıcı alan iki çalışmayı mantıksal olarak birbirine bağlar.

Ağ ile kimlik bilgisi aynı yetki olarak düşünülmeli

Çıkış ağı açıksa sandbox içindeki veri izinli hedeflere gönderilebilir. Gerçek API anahtarını host tarafında tutup yalnızca vekilde isteğe eklemek sırrın ajan tarafından okunmasını engeller; fakat ajanın o anahtarın sağladığı işlemi kullanmasını engellemez. Sır görünmüyor olsa bile kapasite hâlâ erişilebilirdir.

Bu nedenle ağ kuralı ile kimlik bilgisinin kapsamı birlikte daraltılmalıdır. Yalnızca gerekli hedefler ve işlemler açılmalı; ortak, uzun ömürlü ve geniş yetkili kimlik bilgileri yerine görev veya sandbox kapsamına bağlanmış en az yetkili kimlikler kullanılmalıdır. “Anahtar ortam değişkeninde değil” kontrolü tek başına yeterli değildir; ajanın hangi hesap adına ne yapabildiği de sınırlandırılmalıdır.

HTTP tabanlı MCP yetkilendirmesinde de token’ın hedef kaynağa bağlanması gerekir. MCP yetkilendirme şartnamesi, sunucunun erişim token’ının kendisi için üretildiğini doğrulamasını ve istemciden aldığı token’ı aşağı akış hizmetine aynen aktarmamasını zorunlu tutuyor. Bu hükümler, bir aracının başka bir hizmetin yetkisini yanlış bağlamda kullanabildiği confused deputy riskini azaltmayı amaçlar.

MCP sunucusu ayrı bir yürütme ve yetki alanıdır

Bir MCP aracı dosya okuyabiliyor, veritabanına sorgu gönderebiliyor veya bulut kaynağını değiştirebiliyorsa ajanın etkin erişimi aracın sunduğu kapasiteye kadar uzanır. Özellikle yerel stdio sunucusu host üzerinde çalışıyorsa gerçek işlem mikroVM içinde değil, sunucunun host izinleriyle gerçekleşir.

Bu sunucular güvenilir birer eklenti gibi değil, bağımsız üretim bileşenleri gibi yönetilmelidir. Araçların kapsamı belirli kaynak ve işlemlerle sınırlandırılmalı; hassas değişiklikler onaya bağlanmalı; girdiler doğrulanmalı; zaman aşımı, oran sınırı ve denetim kaydı uygulanmalıdır. “Dosya oku” gibi geniş bir araç yerine yalnızca gereken depo ve dosya türlerine erişen dar bir yetenek sunmak, ele geçirilmiş veya yanlış yönlendirilmiş ajanın hareket alanını küçültür.

Güvenli asgari yapılandırma

Asgari güvenli yapı, her katmanda varsayılan reddi uygulayıp yalnızca görev için gereken köprüleri açar:

• Güvenilmeyen kodu kısa ömürlü ve ayrı çekirdekli bir mikroVM’de çalıştırın; host Docker socket’ini veya ayrıcalıklı host cihazlarını bağlamayın.
• Host deposunu salt okunur sunun; değişiklikleri özel bir kopyada üretip inceleme sonrasında aktarın.
• Çıkış ağını varsayılan olarak kapatın; yalnızca gereken hedefleri ve protokolleri açıkça tanımlayın.
• Kimlik bilgilerini ajan dosya sistemine koymayın; en az yetkili ve mümkünse sandbox’a özel bir host vekili üzerinden sağlayın.
• Her MCP sunucusunu ayrı güven sınırı sayın; host dosya sistemi ve üretim hesaplarına geniş kapsamlı erişim vermeyin.
• Hassas araç çağrılarını onaya bağlayın; araç girdilerini, sonuçlarını, dosya değişikliklerini ve ağ hedeflerini kaydedin.
• Görev sonunda geçici verileri ve yetki bağlarını temizleyin; kalıcı bellek ile beceri depolarını yalnızca açık bir güven ilişkisi varsa paylaşın.

Doğru güvenlik iddiası “ajan sandbox’tan çıkamaz” değildir. Ölçülebilir iddia şudur: Ajanın yürüttüğü kod host’tan ayrıdır; dışarı taşan her dosya, istek, kimlik ve araç çağrısı da bağımsız bir politikayla sınırlandırılmıştır. Bu politikalardan biri geniş bırakıldığında güven sınırı mikroVM duvarında değil, izin verilen bağlantıda kırılır.