enclave 0.8.0, opt-in güvenlik boşluğunun ardından LLM agent'ları için default-deny egress'i scaffold'a taşıyor

Default-deny egress scaffold'a taşınıyor

Otonom LLM agent'ları için Apache-2.0 lisanslı sandbox bir runtime olan enclave, 0.8.0 sürümünü yayınladı; bu sürüm, bakımcıların “etkin görünürken aslında devre dışı kalan bir güvenlik kontrolü” olarak tanımladığı bir hata modunu düzeltiyor. dev.to'daki duyuru yazısına göre, projenin çekirdek seviyesindeki default-deny egress güvenlik duvarı hiçbir zaman resmi olarak kapatılmadı — ancak yalnızca dört adımlı manuel bir kurulum prosedürünün ardından etkinleşiyordu, dolayısıyla bu adımları atlayan dağıtımlar hiçbir egress zorlaması olmadan çalışıyordu. Yeni sürüm, default-deny yapılandırmasını enclave new komutunun bir parçası olarak otomatik olarak üretiyor ve operatörlerin bundan çıkmak için artık açıkça --unsafe-network bayrağını geçmeleri gerekiyor.

Yazıda anlatıldığı şekliyle zorlama mekanizması, agent'ın ağ namespace'ini sahiplenen ve bir DNS proxy'sini, trafiği izin verilmedikçe reddeden nftables kurallarıyla eşleştiren bir sidecar. Bakımcılar, bunun tanıdık bir yöntemi kapattığını söylüyor: Bu yöntemde bir shell komutu engellenmiş bir hostname'i bir değişken içinde birleştiriyor, böylece literal komut dizilerini eşleştiren bir filtre hedef adresi hiç görmüyordu.

Secret'lar bir pod'un ihtiyacına göre kapsamlandırılıyor

İkinci bir değişiklik kimlik bilgisi (credential) maruziyetini hedefliyor. Yazıya göre bir secrets dizinini read-only bağlamak yanıltıcı bir rahatlık sunuyor: Bu bayrak yazmayı engelliyor ama okumaya karşı hiçbir şey yapmıyor; yani ele geçirilmiş veya prompt injection'a uğramış bir agent, görebildiği her credential dosyasını hâlâ okuyabiliyordu. 0.8.0'da SECRETS_DIR ayarı mount'ın kapsamını belirliyor ve yeni SECRETS_SCOPE değişkeni her pod'a, tüm secrets deposunu verilmek yerine ihtiyaç duyduğu belirli credential'ları bildirme imkânı sunuyor.

Sürümdeki diğer sağlamlaştırmalar

Aynı temayı izleyen üç küçük düzeltme daha var:

• Gömülü web_chat sunucusu artık auth token ayarlanmamışken non-loopback bir adrese bağlanılması durumunda, bind değişkeninin yalnızca ayarlanmamış olduğu durumlar dahil, başlatılmayı reddediyor. Yazıda açıklandığı gibi sunucu container'ının içinde zorunlu olarak 0.0.0.0'a bağlanıyor; dolayısıyla Docker publish ayarı, değiştirilen bir bind yapılandırması ile izinleri “dangerous” olarak ayarlanmış bir agent'a kimlik doğrulamasız kontrol yüzeyi açılması arasında tek engeldi.
• .publish-audit-allow adında bir allowlist dosyası, hiç uygulanmamış bir audit tarayıcısı için gönderilmişti; yazıya göre kod tabanında yapılan bir arama, dosyanın yalnızca kendisi tarafından referans verildiğini ortaya koydu. Tarayıcı artık var, CI'da çalışıyor ve eksik bir allow dosyasını hata olarak değerlendiriyor.
• Görsel yetenek ön kontrolü (image capability preflight) daha önce API anahtarı dosyası mevcut olduğu sürece başarı bildiriyordu; yani 401 yanıtlarıyla reddedilen bir anahtar yine de yeşil bir “image: ok” durumu üretiyor, çözülen bir engel ise günlerce açık olarak listelenmeye devam ediyordu. Kontrol artık sağlayıcının ücretsiz anahtar doğrulama uç noktasını — ücretlendirilen bir üretim yapmadan — çağırıyor ve çalışan anahtarları mevcut ama geçersiz olanlardan ayırıyor.

Neden önemli

Daha geniş ders tek bir projenin ötesine genelleniyor. Yalnızca bir opt-in prosedüründen sonra devreye giren bir kontrol, bir durum panosunda etkin bir kontrolden ayırt edilemez; ve bir dosyanın gerçekten çalışıp çalışmadığını değil yalnızca var olup olmadığını doğrulayan sağlık kontrolleri de aynı yanlış güvence kategorisine giriyor. Container'larda LLM agent çalıştıran ekipler için — prompt injection'ın saldırgana fiilen container'ın credential'larını ve ağ erişimini teslim edebildiği ortamda — zorlanmayan bir egress politikası bir evrak sorunu değil, canlı bir risk.

Göz önünde bulundurulması gereken uyarılar da var. Bu dev.to'daki birinci elden bir duyuru: Egress duvarı ve audit araçlarına ilişkin iddialar, kendi canlı agent filosunda public bir alpha çalıştıran bakımcıların kendilerinden geliyor ve bağımsız olarak incelenmemiş durumda. Sürüm ayrıca iki bağımsız yardımcı araç içeriyor: prompt'ların, dosyaların ve diff'lerin token maliyetini ölçen bir npm paketi olan tokenscope ile bir pull request'in token maliyeti değişimini tahmin eden ve gerilemede build'i düşüren bir GitHub Action olan ci-guardrail. İkisi de projenin şu çerçevesini yansıtıyor: maliyet kontrolü ve güvenlik aynı şekilde başarısız oluyor — biri kontrol edene kadar sorunsuz görünen varsayılanlar yoluyla.