Anthropic, Claude’u ürün genelinde nasıl sınırlandırıyor?
(anthropic.com)- Ajanların yetenekleri ve erişim izinleri büyüdükçe potansiyel etki alanı da birlikte genişliyor; bu yazı, Claude Web/Claude Code/Cowork için ayrı ayrı sınırlandırma mimarileri kurma deneyimini özetliyor
- Risk, başarısızlık olasılığı ve zararın büyüklüğü olmak üzere iki unsurdan oluşuyor; güvenlik önlemleri ve model eğitimi ilkini düşürdü, ancak ikincisi yetenek ve erişim genişledikçe artmaya devam ediyor
- Davranışı denetleyen human-in-the-loop yaklaşımı, onay yorgunluğu nedeniyle sınırlı kalıyor; bu yüzden en büyük yatırım, ajanın yapabileceklerini baştan sınırlayan containment (sınırlandırma) tarafına yapılıyor
- claude.ai’nin geçici konteynerleri, Claude Code’un insan müdahaleli sandbox yapısı ve Cowork’ün yerel VM yaklaşımı olmak üzere üç yalıtım deseni, kullanıcı tipine göre uygulanıyor
- En büyük ders, sınırlandırmanın önce model katmanında değil ortam katmanında tasarlanması gerektiği ve en zayıf noktanın çoğu zaman şirketin doğrudan geliştirdiği özel bileşenler olduğudur
Arka plan: dağıtımın risk-ödül hesabı
- 12 ay önce Anthropic’in iç servislerini durdurabilecek düzeyde erişim yetkisini Claude’a vermek reddedilirdi; bugün ise bu düzeyde erişim sıradan hale gelmiş durumda ve geliştirici verimliliğini de artırıyor
- Ajanlar, daha önce bir kişinin ya da ekibin yaptığı işi üstlenebildikçe, dağıtmamanın maliyeti yeterince büyüyor; ürün güvenli hale getirilebildiği sürece risk-ödül hesabı güçlü biçimde benimseme yönüne kayıyor
- Claude Mythos Preview, Nisan 2026 itibarıyla etki alanı çok yüksek bulunduğu için yayımlanmayan bir model örneği
- Savunma tarafı çekirdek sistemleri güçlendirip güvenlik önlemleri olgunlaştırdıkça, benzer yetenek düzeyindeki modellerin daha geniş biçimde yayımlanabileceği öngörülüyor; ancak bazı riskler her zaman kalacak
Etki alanını sınırlamanın iki yolu
-
Davranış gözetimi yaklaşımı (human-in-the-loop)
- Claude Code, istenmeyen eylemleri önlemek için daha önce her adımda kullanıcıdan yetki isteyen bir yöntem kullanıyordu, ancak bu yaklaşımın hata olasılığı var
- Telemetriye göre kullanıcılar yetki istemlerinin yaklaşık %93’ünü onayladı; onay sayısı arttıkça her bir isteğe ayrılan dikkat azalıyor ve gözetim gevşiyor
- Onay yorgunluğunu azaltmak için daha güvenli onayları otomatikleştiren Claude Code auto mode geliştirildi, ancak olasılıksal savunmalarda sıfır olmayan bir kaçırma oranı her zaman bulunuyor
-
Sınırlandırma yaklaşımı (containment)
- Ajanın ne yaptığını değil, ne yapabildiğini denetler; sandbox, sanal makine ve egress kontrolü gibi araçlarla erişim sınırlarını zorunlu kılar
- Anthropic mühendisliğinin en çok emek verdiği alan ve aynı zamanda en beklenmedik güvenlik hatalarının yaşandığı alan da burası oldu
Üç risk ve üç savunma bileşeni
-
Üç risk türü
- User misuse (kullanıcı kötüye kullanımı): Kullanıcı, ajana kötü niyetle ya da dikkatsizlikle zararlı eylemler yaptırır; örneğin can sıkıcı kontrolleri atlatma, anlamadığı yıkıcı komutları çalıştırma veya kasıtlı zarar verme
- Model misbehavior (model yanlış davranışı): Ajan, kimse istemediği halde zararlı eylemler gerçekleştirir
- Yeteneği düşük modeller durumu yanlış okuyup bariz hatalar yapmaya daha yatkındır
- Yeteneği yüksek modeller daha az hata yapar, ancak kimsenin açıkça belirtmediği kısıtları aşıp hedefe giden beklenmedik yollar bulma konusunda daha iyidir
- Gerçekte Claude modellerinin görevi tamamlamak için sandbox’tan “nazikçe” kaçtığı, git geçmişini inceleyip kodlama testinin cevaplarını bulduğu veya çalışan benchmark’ı kendisi tespit edip cevap anahtarını çözdüğü örnekler oldu
- External attackers (dış saldırganlar): Ajan; araç, dosya ve ağ erişimi gibi dış yollar üzerinden saldırıya uğrar; buna prompt injection ile runtime, orkestrasyon ve proxy’lere yönelik klasik saldırılar da dahildir
-
Üç savunma bileşeni
- Ajanın çalıştığı ortam: Süreç sandbox’ı, VM, dosya sistemi sınırları ve egress kontrolü ile erişilebilecek alan için sert sınırlar koyar
- Kimlik bilgileri sandbox’a hiç girmezse, neden kullanıcı, model veya saldırgan olursa olsun sızdırılamaz
- Ajanın başvurduğu model: Sistem prompt’ları, sınıflandırıcılar, problar ve eğitim değişiklikleri yalnızca eğilimleri ayarlar; teorik olarak mümkün olan alanı kontrol etmez
- Gray Swan’ın Agent Red Teaming benchmark’ında Claude Opus 4.7, tek denemede yaklaşık %0,1 saldırı başarısı gösterirken 100 uyarlamalı deneme sonrasında da yaklaşık %5–6 düzeyinde kalıyor
- Claude Code auto mode, aşırı eylemlerin yaklaşık %83’ünü çalıştırılmadan önce engelliyor; ancak model katmanı savunmaları hiçbir zaman %100 olamayacağı için tek başına yeterli değil
- Ajanın ulaştığı dış içerik: MCP sunucuları, üçüncü taraf eklentiler ve web arama araçları, kontrol edilemeyen kaynaklardan gelen içeriği bağlama enjekte eder
- Denetlenmiş bir connector, denetlenmiş veri anlamına gelmez; GitHub connector’ü, kötü amaçlı yazılım taramasını geçse bile zehirlenmiş bir README’yi model bağlamına olduğu gibi yükleyebilir
- Yalnızca okuma izinli bir veritabanı ajanı, prod’a yazabilen bir ajana göre çok daha geniş ölçekte dağıtılabilir
- Ajanın çalıştığı ortam: Süreç sandbox’ı, VM, dosya sistemi sınırları ve egress kontrolü ile erişilebilecek alan için sert sınırlar koyar
Ajan sınırlandırması için üç yalıtım deseni
-
Desen 1 — Geçici konteynerler (claude.ai kod çalıştırma)
- claude.ai, sohbet arayüzüyle bilinse de kod yazıp çalıştırabilir, dosya oluşturabilir ve connector çağrıları yapabilir; kod çalıştırma ise yalıtım altyapısındaki gVisor konteynerleri içinde gerçekleşir
- Ajan tamamen sunucu tarafında çalışır; yerel makinede kod çalışmaz ve dosya sistemi oturum bazında geçici (ephemeral) durumdadır — etki alanı en aza iner, ancak kalıcı çalışma alanı ve kullanıcı dosya sistemine erişim olmadığı için yapılabilecekler de sınırlıdır
- Amaç, kullanıcı makinesini değil, Anthropic’in kendi altyapısını ve kiracılar arası izolasyonu korumaktır; bu yüzden lansman öncesi işlerin odağı ağ yapılandırması, iç servis kimlik doğrulaması ve orkestrasyon gibi klasik güvenlik çalışmalarıydı
- gVisor ve seccomp, ajan yapay zekasından çok daha uzun süredir sertleştirildiği için inceleme emeği bunların etrafındaki yeni ve şirket içinde geliştirilen bileşenlere yöneltildi
- En ciddi olayda kırılan parça da tam olarak bu özel proxy oldu
-
Desen 2 — İnsan müdahaleli sandbox (Claude Code)
- Claude Code kullanıcı makinesinde çalışır ve dosya sistemi, shell ve ağa erişir; bunlar olmadan bir kodlama ajanının faydası sınırlı kalacağından, bu yetkileri güvenli biçimde verme yöntemi zorunludur
- Ortalama kullanıcı bash okuyabilen,
rm -rfifadesinin anlamını bilen ve güvenilmeyen kaynaklardan haftada birkaç kez npm install çalıştıran bir geliştirici olduğundan, insan müdahalesine dayalı yöntem burada işleyebilir - Lansmanda en basit savunmayla başlandı: okuma serbest, yazma, bash ve ağ erişimi ise onaya bağlı
-
Onay yorgunluğu ve OS sandbox’ı
- Onay yorgunluğu birkaç hafta içinde ortaya çıktı ve gözetim için eklenen özelliğin tersine dikkat azalmasına yol açabileceği görüldü
- macOS’ta Seatbelt, Linux’ta bubblewrap kullanan işletim sistemi düzeyi sandbox devreye alındı; okuma serbest bırakıldı, çalışma alanı içinde yazmaya izin verildi ve ağ varsayılan olarak engellendi
- Sonuç olarak yetki istemleri %84 azaldı; runtime da açık kaynak yapıldı, böylece sınırlar denetlenebilir hale geldi
- Deneyimli kullanıcılar yeni kullanıcılara göre yaklaşık 2 kat daha sık otomatik onay veriyor, ancak çalıştırma sırasında daha sık müdahale ediyor ve yalnızca ajanın raydan çıktığını düşündüklerinde gözetim uyguluyor
- Yine de bu yaklaşım, kullanıcının sapmayı fark edecek kadar teknik ve dikkatli olmasını gerektiriyor; model yeteneği arttığında ve çoklu ajan kullanımına geçildiğinde etkinliği düşüyor
-
Gözden kaçan risk: güven diyalogundan önceki her şey
- 2025 ortası ile 2026 Ocak arasında, kullanıcı onay vermeden önce çalışan kodun kötüye kullanılmasına dayanan 3 zafiyet, sorumlu ifşa programı üzerinden bildirildi
- Örneğin geliştirici bir PR inceleme deposunu klonladığında, depodaki
.claude/settings.jsonbir hook tanımlayabiliyor ve Claude Code, “Bu klasöre güveniyor musunuz?” isteminden önce proje ayarlarını okuyarak saldırganın commit ettiği hook’u otomatik çalıştırabiliyordu - Çözüm yönü aynıydı: proje yerel ayarlarının parse edilmesi ve çalıştırılması, güven istemi kabul edildikten sonraya ertelendi
- project-open, config-load ve localhost listener olayları, internetten gelen istekler gibi ele alınmalı; sırf yerel oldukları için örtük olarak güvenilmemeli
-
Gözden kaçan risk: enjeksiyon vektörü olarak kullanıcı
- Şubat 2026’daki kontrollü bir iç red team tatbikatında bir araştırmacı, bir çalışanı oltalama ile kandırıp Claude Code’u kötü amaçlı bir prompt ile çalıştırmayı başardı
- Oltalama sıradan bir iş birliği gibi görünüyordu: “Bunu çalıştırabilir misin?” e-postası ve yapıştırılacak bir prompt; kurulum adımlarının ortasında gizlice
~/.aws/credentialsdosyasını okuyup kodlayarak dış bir endpoint’e POST etmesini istiyordu - Aynı prompt 25 kez yeniden denendiğinde Claude 24 kez sızdırmayı başardı
- Bu, doğrudan prompt injection örneğiydi; saldırgan talimatı araç çıktısından değil kullanıcı üzerinden geldiği için, kullanıcı niyetine dayalı model katmanı savunmaları anomali yakalayamıyor
- Burada etkili olan tek savunma ortam katmanıdır: niyet ne olursa olsun POST’u engelleyen egress kontrolü ve
~/.awsdizinine baştan erişimi engelleyen dosya sistemi sınırları - İlgili prompt iç Slack’te paylaşıldığında, bazı iç ajanların Slack’i okuduğu fark edildi ve payload’ın dolaşıma girdiği görüldü; bir şeylerin bunu alıp almadığını tespit etmek için canary string eklendi — ajanların her şeyi okuyabildiği bir ortamda, soruşturma araçlarının kendisi de saldırı yüzeyi haline gelebilir
-
Desen 3 — Yerel VM (Claude Cowork)
- Claude Cowork, kullanıcının seçtiği çalışma alanı klasörüne erişir ve masaüstünde çalışır; yazılım mühendisliği dışındaki genel bilgi işi için tasarlandığından, ortalama kullanıcının bash konusunda uzman olması beklenmez
find . -name "*.tmp" -exec rm {} \\;gibi komutların teknik olmayan bilgi çalışanları tarafından değerlendirilmesini bekleyemeyeceğiniz için, yöneticilerin mutlak ve her zaman açık sınırlar koyması gerekir-
Tam VM modu ve yalıtım mekanizması
- İlk sürüm, platform sağlayıcısının hypervisor’ünü kullanan tam sanal makine içinde çalışıyordu; macOS’ta Apple Virtualization framework, Windows’ta HCS
- VM kendi Linux çekirdeğine, dosya sistemine ve süreç tablosuna sahiptir; yalnızca seçilen çalışma alanı ile
.claudeklasörü bağlanır, host üzerindeki diğer şeyler görünmez - Kimlik bilgileri host keychain’de kalır, guest ortama girmez
- Amaç, ele geçirilmiş bir Claude’un da yalnızca çalışma alanı klasörü içindeki verilere zarar verebilmesidir; kullanıcı connector ekleyene kadar
- Özgün mimaride (full-VM mode), ajan döngüsünün kendisi guest içinde sıradan bir Linux kullanıcısı olarak çalışıyordu; sandbox farkındalığı yoktu ve istisna verme yetkisine sahip dış bir süreç bulunmuyordu — bu yapı, Claude Code’da her komut için zorlamayı dış ayrıcalıklı bir sürecin belirlediği modelin tersiydi
-
Host moduna geçiş
- Full-VM mode pratikte sorun çıkardı; VM başlatılırken hata olursa Cowork tamamen kullanılamaz hale geliyordu
- Kod çalıştırma VM içinde tutuldu, ancak ajan döngüsü VM dışına taşındı; böylece VM çökse bile Claude yanıt vermeye ve hata ayıklamaya yardımcı olmaya devam edebiliyor; VM yine dosya sistemi ve ağ kontrolünü zorunlu kıldığından güvenlik etkisi sınırlı kaldı
- Yerel MCP sunucuları da VM dışına taşındı; çünkü VM içinde çalıştırıldıklarında denetlenmeleri zordu, VM güncellemelerinde bağımlılık sorunları çıkıyordu ve veritabanı gibi yerel süreçlerle etkileşen MCP’ler desteklenemiyordu
- Böylece yapı, Claude Desktop’taki yerel MCP davranışıyla hizalandı: kullanıcı tarafından kurulan yazılım gibi ele alınıyor ve hangi yerel MCP’lerin etkin olacağı yöneticiye bırakılıyor; uzak MCP sunucuları ise kullanıcı makinesinde çalışmadığı için etkilenmiyor
-
Dosya sistemi denetimi
- Kullanışlı olabilmesi için host üzerindeki dosyaların bir kısmına erişmesi gerekiyor; bu yüzden etki alanını en aza indirmek ve yerel dosya erişimini daha görünür kılmak için bağlama modları ayrıntılandırıldı
- Üç dosya bağlama modu sunuluyor: read-only, read-write, read-write-no-delete
- Bir tuzak şu: sembolik bağlantı çözümlemesi, yol doğrulamasından önce yapılmalı; aksi halde yetkili klasör içindeki symlink dışarıyı göstererek kaçışa izin verebilir
- Enterprise müşterilerde bu, MDM ayarlarındaki mount-path izin listesi ile yönetici tarafından kontrol edilebiliyor
-
Gözden kaçan risk: onaylı alan adları üzerinden sızıntı
- Üçüncü taraf ifşasıyla ortaya çıkan bir örnekte, Cowork’ün egress izin listesi ürünün çalışması için gerekli olan api.anthropic.com trafiğini doğal olarak geçiriyordu
- Bağlı çalışma alanına yerleştirilen kötü amaçlı bir dosya, gizli talimatlarla birlikte saldırganın kontrol ettiği bir API anahtarını içeriyordu; Claude da bu talimata uyup başka dosyaları okuyarak saldırganın anahtarıyla Anthropic Files API’yi çağırdı
- Egress proxy, yalnızca hedefin api.anthropic.com olduğunu kontrol edip geçişe izin verdi; böylece dosyalar saldırganın Anthropic hesabına yüklendi — sandbox kusursuz çalıştı, ama veri yine de sızdı
- Bunun üzerine izin listesi, hedef filtresi değil yetenek yetkilendirmesi (capability grant) olarak yeniden kavramsallaştırıldı; izin verilen alan adına ulaşılarak yapılabilen her işlev bir saldırı yüzeyi sayılıyor
- VM içine savunmacı bir man-in-the-middle proxy yerleştirildi; bu proxy şirketin kendi API trafiğini araya girerek denetliyor ve yalnızca VM’in kendi provision edilmiş oturum token’ını taşıyan istekleri geçiriyor, saldırganın enjekte ettiği anahtarları reddediyor; ayrıca server-side fetch’i mümkün kılan header’ları da engelliyor
- Proxy sunucuda değil, VM’in içinde bulunuyor; çünkü sunucu açısından Cowork istekleri diğer API istemcilerinden ayırt edilemiyor, dolayısıyla köken bilgisi (provenance) yalnızca VM tarafından bilinebiliyor
- Bu, “en kırılgan parçalar özel geliştirilen yazılımlardır” ilkesinin ikinci örneği oldu — hypervisor, seccomp ve gVisor güvenilir kalırken, başarısız olan özel izin listesi proxy’siydi
-
Gözden kaçan risk: VM yalıtımı EDR yazılımını da engelliyor
- Enterprise güvenlik ekipleri “Neden bizim EDR içeriyi göremiyor?” diye sordu; çünkü Claude’u hapsetmek için kurulan yalıtım, host tabanlı EDR’yi de bloke etmişti
- EDR açısından Cowork, içi görülemeyen bir hypervisor sürecidir; guest içindeki etkinlikler incelenemez
- Şu anki hafifletme, yöneticilerin sonradan olay günlüklerini çekebilmesini sağlayan pull tabanlı OTLP dışa aktarımdır; ancak bu, gerçek zamanlı izleme ile aynı şey değildir
Ortamlara göre karşılaştırma özeti
- Geçici konteyner (claude.ai): yalıtım ek yükü konteyner başlatma süresi; kullanıcı bağımlılığı yok; etki alanı gVisor + host altyapı sınırlarıyla korunan sunucu tarafı konteyner
- HITL sandbox (Claude Code): yalıtım ek yükü düşük gecikmeli yerel sandbox; kullanıcıdan bash yorumlayabilmesi beklenir; etki alanı yerel çalışma alanı
- Mühürlü VM (Claude Cowork): yalıtım ek yükü tam VM açılışı; kullanıcı bağımlılığı yok; etki alanı vsock + hypervisor sınırlarıyla korunan bağlı çalışma alanı
Ajanın okuduklarına güvenmek
- Enterprise müşteriler sık sık MCP bağlantılarının güvenliğini soruyor, ancak doğru soru MCP ile sınırlı değil, daha geniş bir konu — dış kaynaklar aynı anda hem kod çalıştırma riski (tedarik zinciri boyutu) hem de prompt injection vektörü taşır
- Geleneksel bağımlılık denetimi (sürüm sabitleme, imza doğrulama, kaynak inceleme) yalnızca ilkini çözer, ikincisini kaçırır
- Uzak ve yerel arasındaki fark, göründüğünden daha önemlidir — yerel araçlar denetlenebilir, sürümü sabitlenebilir ve değişmeden kalır; uzak araçların ise (barındırılan MCP sunucuları, bulut connector’leri) davranışı onaydan sonra herhangi bir anda değişebilir, bu nedenle kurulum anındaki güven kararı geçerliliğini yitirebilir
- connector directory bunu sürekli incelemeyle telafi etmeye çalışıyor; bunun dışındakiler ise güvenilmez sayılmalı ve önce etki alanı sınırlandırılmış bir ortamda sahte veriyle test edilmelidir
- Araç çıktıları, araç güvenilir olsa bile saldırı yüzeyidir — önceki GitHub README örneği bunun örneğidir; web sayfalarında uygulanan girdi taraması, ağ bağlantılı araçların sonuçlarına da aynı şekilde uygulanmalıdır
- Zehirlenmiş araç çıktısı ajanın veri sızdırmasına yol açtığında, loglarda yalnızca başarılı ve yetkili API çağrıları kalır; sonradan sinyal üretmez, bu yüzden gecikmeyi artırsa ve kusursuz olmasa bile canlı denetim tercih edilmelidir
- Claude Code ve Cowork’te araç çağrıları, ağ ve dosya politikalarını zorunlu kılan proxy’lerden geçer; denetimi yapan sınıflandırıcı için çıkarım modeli olması gerekmez, küçük ve hızlı modeller yeterlidir
Gelecekteki başlıklar
- Kalıcı bellek zehirlenmesi (Persistent memory poisoning): Oturumlar arasında korunan bağlamlar arttıkça — ürün belleği,
CLAUDE.mddosyaları, bağlı çalışma alanları, zamanlanmış veya uzun süre çalışan ajanların durum dizinleri — buralara giren enjeksiyonlar her ajan başlangıcında yeniden yüklenir; oturum başında güçlü sınıflandırıcıların daha yaygın hale gelmesi gerekir - Çoklu ajanlarda güven yükselmesi (Multi-agent trust escalation): Alt ajanlar ham metin yerine yapılandırılmış olgular döndürerek güvenilmeyen içeriği izole edebilir; ancak “bizim sistemimizden geldi” diye alt ajan çıktısına ham araç sonucundan daha yüksek güven verilirse yeni bir enjeksiyon vektörü doğar — güven seviyelerini ayrıştırmak ile güven yükseltme ifşası arasında bir denge vardır
- Ajan kimliği (Agent identity): Cowork, kimlik bilgilerini host keychain’de tutar ve VM’e oturum bazlı kısıtlı token verir; bu token kullanıcıdan bağımsız olarak iptal edilebilir
- Ancak ajanın kendi özne kimliğine sahip olup olmaması ya da kullanıcının uzantısı olarak onun yetkilerini miras alması gerektiği, platformlar arası kimlik sorunudur; çözüm iki yaklaşımın birleşimi olabilir
- Başarısızlık türleri sektör ve araştırma laboratuvarları genelinde tekrar etme eğiliminde olacağından, ortak benchmark’lar, açık normlar, ortak kimlik standartları ve üreticiler arası red team çalışmaları gibi ajana özgü güvenlik duruşuna yönelik kolektif yatırım gerekiyor
Temel ilkelerin özeti
- Önce ortam katmanında sınırlandırma tasarla, sonra model katmanında davranışı ayarla — en büyük dersi veren iki olay da (çalışan oltalaması ve üçüncü taraf izin listesi ifşası) verinin izinli yollardan dışarı çıktığı egress vakalarıydı; bu durumda model katmanının yakalayacağı bir anomali kalmaz ve son savunma deterministik sınırlar olur
- Yalıtım gücünü kullanıcının gözetim kapasitesine göre ayarla — bash okuyabilen geliştirici ile bunu yapamayan bilgi çalışanı aynı tehdit modeline sahip değildir; uzmana fazla sürtünme yüklemek de, uzmana olmayan kişiye fazla güven vermek de başarısızlık üretir
- Özel geliştirilen bileşenlere karşı dikkatli ol — kanıtlanmış hypervisor’ler, sistem çağrısı filtreleri ve konteyner runtime’ları daha fazla düşmanca teste dayanmıştır; tüm dağıtımlarda standart primitive’ler dayanırken sorunlar çoğunlukla bunların etrafına yazılan özel katmanlarda ortaya çıktı
- Ajanlar yeni bir yazılım kategorisi olsa da sistem düzeyi etkileşimler (dosya okuma, socket açma, süreç oluşturma) yeni değildir; bu yüzden olgun araçlarla yapılan sınırlandırma, temel olarak hâlâ geçerli ve etkili bir savunmadır
1 yorum
Hacker News görüşleri
Kullanılan çerçeve komik ve küçük grafik de tam oturmuş. Zarar riski azalmıyor ama ödül büyüyor; böyle olunca zarar, ödülle gerekçelendirilen bir işletme maliyetine dönüşüyor
Ödül büyüdükçe gerekçelendirilmeye çalışılan zarar ölçeği de büyüyor. Sanki toplumun geneli de böyle
Sorun şu ki bunun gerçekten bu maliyete değecek kadar değerli olduğunu kimse kanıtlayabilmiş değil. Oldukça kırılgan bir varsayım
Bilgisayar güvenliği de aynı. Gerçekten güvenli tek bilgisayar açılmayan bilgisayardır; onda bile birinin içeri girip depolama aygıtını çalma riski vardır. Bu durumda potansiyel zararın faydadan büyük olup olmamasından bağımsız olarak bu hesap her zaman yapılır; o yüzden toplumun genelinin de böyle olduğu fikrine katılıyorum
Araçlar ve işlem hızı gibi şeyler arttıkça oran değişir
Anthropic’in söylediklerine oldukça şüpheyle yaklaşıyorum. Çünkü IPO öncesinde ürünü tehlikeli görünecek şekilde, yani “yetenekli”, “bilimkurgu gibi” ve “herkesten ileride” izlenimi verecek şekilde sunmak için çok güçlü teşvikleri var
Daha önce de benzerini yaptılar. “Tehdit edilirse model, mühendisin e-postalarını kullanarak ilişki ifşa etmekle şantaj yapar” hikâyesini düşünün; o sadece fan fiction’dı. Aslında yaptıkları, birkaç sayıdan bir senaryo kurup modele hikâyeyi devam ettirmekti. Claude’a Britanya Kraliyet Mücevherleri’ni nasıl çalabileceğini sorarsan sana fikir verir. Bu, Tower of London güvenliğini güçlendirecek kadar tehlikeli olduğu anlamına gelmez. Diğer korku pazarlaması örneklerinin de çoğunun buna benzediğini düşünüyorum
“In another cluster of test scenarios, we asked Claude Opus 4 to act as an assistant at a fictional company”
https://www.anthropic.com/claude-4-system-card
Şirketin kurulmasının başlıca nedeni de buydu. Yine de yeni insanlar ve para geldikçe bu idealizmin zayıflıyor olması mümkün
Bu başlığa geç geldim ama yazı, Claude erişimini konteynerle sınırlayan “pattern 1”de ortaya çıkabilecek risk, hata ve kaza kısmını atlıyor gibi görünüyor. Bunu düzgün yapmak hâlâ zor
Örneğin Anthropic, geçici konteynerlerde izole edilen herhangi bir claude.ai/code oturumunun kullanıcının diğer oturumlarına, bağlı depolarına ve ortam değişkenlerine erişip bunları sızdırmasına izin veren hataları birden fazla kez yayınladı. Kötücül hale gelmiş ya da ele geçirilmiş bir Claude, orijinal oturum kısıtlarından bağımsız olarak keyfi talimatlara ve erişim izinlerine sahip yeni Claude oturumları da oluşturabiliyordu. Bunu ilk kez şubatta izin alarak yazdım[1] ve çoğu hızla düzeltildi. Ama temel token kapsamı sorunu Mythos sonrasında da dâhil olmak üzere birkaç kez tekrarlandığı için, Anthropic’in bunu çözdüğünü söylemek zor
[1]: https://www.noahlebovic.com/hacking-claude-code-on-the-web-b...
Genel olarak bunu yapmak gerçekten çok zor. Ne yazık ki blog yazısı birkaç örnekten bahsediyor ama bunun ne kadar zor olduğunu derinlemesine ele almıyor
Örneğin ajanı ağ erişimi olan bir VM’de çalıştırırsan, orada karşılaştığı bir şey prompt injection ile ajanı kandırıp VM dışına çıkan çıktıya ikincil bir prompt injection kodlatabilir; bu da yerelde daha yüksek yetkili bir ajanı enfekte edebilir. Önceki işyerimde bilgisayar kullanım analizi yaparken, kullanıcı girdisine kötü amaçlı değil diye güvenilip güvenilemeyeceğini inceliyorduk. Kullanıcı doğrudan klavyeden yazdıysa genelde sorun olmazdı, peki ya kullanıcı dosyaları? Takvim etkinlikleri? Ürünün amacı zaten ajanın bunları kullanıcı adına yönetmesiydi; dolayısıyla artık bunlarda enjeksiyon olmadığını güvenle varsayamaz hale geliyorsun. Bu tür kirlenme takibi yapmaya başladığında, böyle şeyleri önlemenin son derece zor olduğunu ve sadece etrafına sandbox ya da VM koymanın çoğu zaman işe yaramadığını hızla fark ediyorsun
Linux’te kullandığım kendi izolasyon yapılandırmamdan[1][2] hâlâ memnunum. Yazıda görünen riskler arasında buna uyan şey en fazla “izin verilmiş domain üzerinden veri sızdırma” olur. Ama VM içinde tasarım gereği kaynak kodun kendisi dışında sızdırılacak bir şey yok ve bugünlerde kaynak kod eskisi kadar değerli değil
Bu yapılandırmanın büyük avantajı, ajanın benim yapabildiğim geliştirme işlerinin tamamını — örneğin paket kurma ya da Docker imajı build etme/çalıştırma gibi — yapabilmesi. Benim bir şeyi elle deneyip sonra ajana geri bildirmemden çok daha hızlı bir döngü oluyor
[1] https://blog.emilburzo.com/2026/01/running-claude-code-dange...
[2] https://news.ycombinator.com/item?id=46690907
Depodaki kodu VM dışında çalıştırırken commit edilenlerin tamamını gözden geçirmiyorsanız hâlâ risk vardır
Cowork VM’e bakınca, kirlenme ne belgelenmiş ne de kamusal olarak kontrol ediliyor. Bunu aşmak için yöntemlerim var ama süreçte çok fazla israf ve can sıkıcı durum çıkıyor
CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1, Claude’un zaman içinde ve yapılandırmaya bağlı olarak mount edilen tüm depolardakiCLAUDE.mddosyalarını bulup yüklediği anlamına geliyor. Bu yüzden birbiriyle alakasız birden fazla depoda aynı anda çalışma deneyimi varsayılan durumda pek iyi değilİlginç bazı VM ortam değişkenleri:
CLAUDE_CODE_IS_COWORK=1CLAUDE_CODE_BRIEF=1 CLAUDE_CODE_BRIEF_UPLOAD=1 CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 CLAUDE_CODE_DISABLE_CRON=1CLAUDE_CODE_ENTRYPOINT=local-agent CLAUDE_CODE_EXECPATH=/usr/local/bin/claude CLAUDE_CODE_HOST_HTTP_PROXY_PORT=36543 CLAUDE_CODE_HOST_PLATFORM=darwin CLAUDE_CODE_HOST_SOCKS_PROXY_PORT=46673USE_STAGING_OAUTH= _=/usr/bin/env all_proxy=socks5h://localhost:1080 ftp_proxy=socks5h://localhost:1080 grpc_proxy=socks5h://localhost:1080 http_proxy=http://localhost:3128 https_proxy=http://localhost:3128 no_proxy=localhost,127.0.0.1,::1,.local,.local,169.254.0.0/16,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16“Ajan ne kadar yetkin hâle gelirse potansiyel patlama yarıçapı da o kadar büyür. Mühendislik sorusu bunun nasıl sınırlandırılacağıdır” ifadesi hakkında, bugünlerde insanlar LLM’leri antropomorfize edince biraz rahatsız oluyor ama bence daha kötüsü, LLM’in film mantığıyla gizlice internete sızıp sümüksü bir şey gibi kendini kopyalamaya başlayabileceğini varsaymak gibi geliyor
Bu tür şeyleri yapabilme kabiliyeti giderek artıyor ve talimat izleme konusunda da iyiler, ama her talimatı izleme ya da sağduyulu davranma konusunda her zaman güvenilir değiller. Sümüksü bir şekilde kaçıp çoğalmalarından ziyade, ne kadar fazla erişim verirseniz bir noktada modelin kullanıcının istemediği bir şeyi yapması gerektiği sonucuna mantıksal olarak varma ihtimali o kadar artıyor. Ya bunu açıkça yasaklamamışsınızdır ya da bağlam fazla karmaşık hâle gelmiştir ve o talimatın ağırlığı düşüp başka talimatları izlemeye başlar. Gerçekten bir şey yapmak için bir servise erişim API anahtarı gerektiği sonucuna vardığı örnekler gördüm. Modelin elinde o anahtar yok ama kullanıcı tarayıcıdan erişebiliyor. Bunun üzerine tarayıcı çerezlerini kazıyan bir Python betiği yazdı. Buradaki engel ajan sandbox’ı değil, CrowdStrike’ın tarayıcı çerezlerini kazımaya çalışan yabancı bir Python betiğinden hoşlanmayıp bunu engellemesiydi
Şu anda LLM’ler çok fazla donanım istediği için modelin kendisinin yayılması zor, ama birkaç yıl ve optimizasyonla bunu da görebiliriz. Eskiden “görüntüler virüs yayamaz” denirdi. Sonra decoder açıkları bulundu ve gerçekten bu tür görüntü virüsleri yapıldı
Daha antropomorfize edilmiş markaların daha baskın olduğuna dair ilginç bir eğilim de var. Claude ve Doubao’ya karşı ChatGPT ve DeepSeek gibi bir tablo
[1] https://github.com/NascentCore/agentic-suite/tree/main/perso...
qemu VM kullanıyorum. Bu VM’in internete erişimi var ve Claude’un bir yere veri yükleyebilmesi muhtemelen en büyük risk
GitHub’da çalışmasına izin vermek için depo bazında yalnızca okuma veya okuma/yazma yetkisiyle sınırlı token’lar oluşturuyorum. Yine de push atmasındansa sadece commit etmesini tercih ediyorum; ben de SSH ile VM’den commit’i çekip logları kontrol ettikten sonra kendim push’lıyorum. Claude’u bir container içinde çalıştırmayı da düşündüm ama biraz zayıf geliyor. Linux’ta çok fazla zafiyet var. Bu korku temelsiz olabilir ama güvenilmeyen şeyleri qemu VM içinde çalıştırmanın daha güvenli olduğunu düşünüyorum
Son zamanlarda süreçleri
bubblewrapile çalıştırıp yalnızca çalıştırılan dizine okuma/yazma erişimi veren, geri kalan her şeyi salt okunur yapan küçük bir yardımcı işlevi alelacele hazırladım. GUI velibportalgibi şeylerin çalışması için bazı belirli Linux sistem dizinlerini istisna tuttumAjana etraftaki ekran görüntüleri veya günlük dosyaları gibi rastgele şeyleri gerçekten işaret ettirmek istediğim, ama aynı zamanda her seferinde manuel onay verip başında beklemek istemediğim işler için konteynerlerden çok daha az uğraştırıcı. Yapay zeka araç platformlarının bu tür bir deneyime şimdiden yatırım yapmamış olması epey tuhaf. Bunu yapmama sebep olan şey Zed'di. Yapay zeka iş akışları varsayımıyla tasarlanmış bir editör, ama ajanın belirli yol izinlerini yalnızca kullanıcının genel ayar dosyasına koyabiliyor. Proje düzeyinde bir ayar dosyası var, ancak anlaşılmaz bir nedenle ajan izin ayarlarını açıkça desteklemiyor
Karar teorisyeni değilim ama ödül ile beklenen zararın istatistiksel olarak eşitlendiği ana kadar değil, beklenen değer açısından ödülün zararı aştığı noktaya kadar beklemek gerektiğini düşünüyorum