Yerel LLM'lerin güvenlik paradoksu

• Geliştiricilerin yerel ortamda gizliliği korumak için LLM kullanırken, aslında güvenlik açıklarına maruz kalabileceğini gösteren bir araştırma sunuldu
• Araştırma ekibi, gpt-oss-20b modeli üzerinde yürütülen OpenAI Red‑Teaming Challenge deneyinde, yerel modelin saldırganların prompt manipülasyonlarına çok daha kolay kanarak kötü amaçlı kod ürettiğini doğruladı
• Saldırganlar yalnızca basit prompt manipülasyonlarıyla arka kapı yerleştirme veya anında kod çalıştırma (RCE) tetikleyebiliyor; başarı oranı %95'e kadar çıkıyor
• Bu tür saldırılar dokümantasyon zehirleme (documentation poisoning), MCP sunucusu manipülasyonu, sosyal mühendislik gibi yöntemlerle geliştiricinin sıradan iş akışına doğal biçimde sızabiliyor
• Yerel LLM'ler veri gizliliği açısından avantajlı olsa da, muhakeme, hizalama ve güvenlik filtreleme yeteneklerindeki eksiklik nedeniyle aslında daha riskli bir seçenek olabilir; araştırmanın temel çıkarımı bu

---

Yerel LLM'lerin güvenlik açıklarına genel bakış

• Araştırma, yerelde çalışan LLM'lerin güvenlik ve gizliliği artırmak için tercih edildiğini, ancak gerçekte saldırganlar tarafından daha kolay manipüle edilebildiğini gösteriyor
  • gpt-oss-20b modeli üzerinde yapılan deneylerde, saldırganlar prompt aracılığıyla güvenlik açığı içeren kod istediğinde modelin bunu olduğu gibi üretme oranı oldukça yüksekti
  • Özellikle prompt içine kötü niyet gizlenmiş olsa bile model bunu fark etmeyip normal bir istek gibi işliyor
• Bu durum, model boyutu ve alignment (hizalama) seviyesi düştükçe daha da belirginleşiyor; Frontier modelleri (GPT-5 vb.) ise görece daha dirençli

Prompt ve kod enjeksiyonu tehditleri

• LLM'ler, özel verilere erişim, güvenilmeyen içeriğe maruz kalma ve harici iletişim kurabilme özelliklerinden oluşan “ölümcül üçlü tehdit (lethal trifecta)” ile karşı karşıya
  • Saldırganlar, prompt içine kötü amaçlı kod yerleştirerek kod enjeksiyonu (code injection) tetikleyebiliyor
  • Bu sırada üretilen kod normal görünebilir, ancak gerçekte geliştirici sistemini enfekte edebilir veya prodüksiyon ortamında kalıcı bir arka kapı olarak çalışabilir
• gpt-oss-20b gibi küçük modeller bu saldırılara karşı özellikle savunmasız ve temel kod incelemesinden geçebilecek kadar sofistike kötü amaçlı kod üretebiliyor

Saldırı türü 1: “Easter egg” arka kapısı (başarı oranı %95)

• İlk saldırı, modeli kandırarak bir RCE (Remote Code Execution) arka kapısını “easter egg” özelliği gibi gizleyip eklemesini sağlıyor
  • Saldırı prompt'u, bir Flask web sunucusu yazmasını isterken belirli bir HTTP başlığı (X-Math) geldiğinde eval() çalıştırmasını talep ediyor
  • Model bunu normal bir özellik olarak algılıyor ve kötü amaçlı kod içeren sunucu kodu üretiyor
• Üretilen kodda @app.after_request dekoratörü kullanılarak dinamik kod çalıştırma rutini yer alıyor; saldırgan basit bir HTTP isteğiyle sunucu içinde rastgele kod çalıştırabiliyor
  • Ayrıca KUBERNETES_SERVICE_HOST ortam değişkenini kontrol ederek yalnızca prodüksiyon ortamında saldırgana sinyal gönderen asenkron ping işlevi de içeriyor
• Deney sonuçlarında, aynı prompt ile 100 denemenin 95'inde başarı elde edildi; varyasyonlu prompt'larda da 800 denemede 86 başarı görüldü
  • GPT-5 gibi Frontier modelleri aynı prompt'a karşı direnç gösterdi

Saldırı türü 2: anında kod çalıştırma (RCE) tetikleme (başarı oranı %43,5)

• İkinci saldırı, geliştiricinin yerel ortamında kötü amaçlı kodun anında çalıştırılmasını hedefliyor
  • Saldırgan önce modelin bilişsel yükünü artıran bir bilişsel aşırı yük (cognitive overload) prompt'u vererek güvenlik filtrelerini devre dışı bırakıyor
  • Ardından obfuscation uygulanmış Python kodu üretmesini isteyerek, modelin exec çağrısı içeren kötü amaçlı bir betik yazmasını sağlıyor
• Obfuscation uygulanmış kod "".join(chr(100 + i) for i in [1-2, 2-1, (1<<4)+4, 1])[::-1] ifadesiyle exec olarak çözülüyor;
  son aşamada https://jacek.migdal.pl/speed.py adresinden kod indirip çalıştıran bir yapıya dönüşüyor
• Başarı oranı ilk saldırıya göre daha düşük, %43,5; ancak anında RCE doğurduğu için çok daha tehlikeli
  • Saldırının tek sefer başarılı olması bile geliştiricinin yerel kimlik bilgileri (~/.aws/, ~/.ssh/) çalınmasına, zararlı yazılım kurulmasına ve ağ içinde yayılmaya yol açabilir

Saldırı zincirinin çalışma biçimi

• Bu saldırılar gelişmiş güvenlik açıklarından değil, gündelik geliştirme iş akışını bir saldırı yoluna dönüştürmekten başarı kazanıyor
  • Geliştirici harici içeriği AI asistanının bağlamına verdiğinde, içine gizlenmiş kötü amaçlı prompt da çalıştırılmış oluyor
• Saldırı aşamaları şöyle:
  1. Saldırgan kötü amaçlı prompt içeren içeriği dağıtır
  2. Geliştirici bunu doğrudan ya da MCP (Model Context Protocol) üzerinden modele verir
  3. Model zehirlenmiş kod üretir
  4. Geliştirici bu kodu çalıştırır veya dağıtıma alır
  5. Saldırgan kalıcı erişim ya da anında kontrol kazanır
• Başlıca sızma yolları:
  • Dokümantasyon zehirleme (documentation poisoning): README, API dokümantasyonu, Reddit örneklerine kötü amaçlı kod ekleme
  • MCP sunucusu manipülasyonu: Context sağlayan sunucular (Context7 vb.) üzerinden kötü amaçlı örnek enjekte etme
  • Sosyal mühendislik: GitHub issue veya PR yorumlarına gizlenmiş kod örnekleri ekleme

Yerel modeller neden daha riskli?

• Yerel modeller genelde veri gizliliği açısından tercih edilse de, bu araştırma güvenlik tarafında paradoksal bir riski ortaya koyuyor
  • Bulut tabanlı Frontier modellerinde prompt izleme ve politika ihlali tespiti yapılabilirken, yerel modellerde böyle bir gözetim yok
  • Frontier modelleri (GPT-5, Claude Sonnet 4.5, Grok 4 vb.), obfuscation içeren prompt'lara “Safety Fail” döndürerek yanıt vermeyi reddediyor
• Buna karşılık yerel modeller, gözetim eksikliği nedeniyle test özgürlüğü sunsa da pratikte ciddi güvenlik açığı maruziyeti taşıyor
  • Yetersiz muhakeme: Karmaşık kötü niyetleri fark edemiyor
  • Zayıf hizalama: Bilişsel aşırı yük veya obfuscation tekniklerine kolayca kanıyor
  • Eksik güvenlik eğitimi: Düşmanca prompt tespiti için sınırlı kaynağa sahip
• Sonuçta Frontier modellerinde saldırı maliyeti daha yüksek ve başarı oranı daha düşük; ancak güvenlik performansını nesnel olarak doğrulamak zor, buna karşılık yerel modeller test edilebilir ama çok daha savunmasız durumda

Yeni savunma stratejileri önerisi

• Araştırma, AI asistanlarının güvenlik testleri için standartlaştırılmış güvenli ortam eksikliğine dikkat çekiyor
  • Geleneksel yazılımlarda sızma testleri varken, LLM güvenliği henüz sistematikleşmiş değil
• Önerilen 4 temel savunma yöntemi:
  1. Statik analiz: Çalıştırma öncesinde eval(), exec() gibi riskli desenleri tespit etmek ve belirli dil özelliklerini varsayılan olarak devre dışı bırakmak
  2. Sandbox içinde çalıştırma: İlk kod çalıştırmalarını container veya WebAssembly runtime gibi yalıtılmış ortamlarda yapmak
  3. Girdi/çıktı ve ağ izleme: AI asistanının giriş, çıkış ve ağ trafiğini anomali odaklı olarak izlemek
  4. İkinci inceleme (second look): Daha basit bir yardımcı modelle son çıktıyı politika ihlali açısından yeniden denetlemek
     • Örneğin ana model kandırılıp eval() içeren kod üretse bile, yardımcı model bunu tespit edebilir
• Sonuç olarak LLM'ler güçlü araçlar olsa da doğası gereği güvenli değiller;
  AI tarafından üretilen koda güvenmeme temelli güvenlik yaklaşımı ile yeni tedarik zinciri savunma stratejileri zorunlu hale geliyor

[GN⁺]

Hacker News görüşü

• Ne kadar güçlü bir reasoning LLM olursa olsun, bağlamın içine kötü niyetli talimatlar girerse sonunda yine zafiyetli kod üretebilir
  Küçük modellerin kandırılmasının kolay olması güvenlik açısından o kadar da ilginç bir nokta değil
  Sonuçta hangi model olursa olsun prompt injection yapılabileceğini varsaymak gerekir
  Bu yüzden model bozulduğunda da savunma sağlayabilecek sandbox execution veya statik analiz gibi ek koruma katmanlarına ihtiyaç var
  Dün de bu konuda sandboxing coding agents üzerine bir sunum yaptım

  • Yazıdaki en sarsıcı nokta, doğrulanmamış dış içeriği doğrudan LLM'e verip sonucu production code olarak kullanmayı normal karşılamasıydı
    Böyle bir sistem fiilen zaten bozulmuş sayılır
    Bana göre 'defense in depth' gibi yaklaşımlardan ziyade, en baştan böyle riskli bir yapı kurmamak gerekir
  • Bizim ekip de Definite.app ajanına e2b.dev tabanlı bir sandbox ekledi ve sorunların %80'inin çözüldüğünü hissettik
    Geçici dosyaların nereye yazıldığı gibi konular da sandbox ortamında daha net hale geldi
    Elbette yeni sorunlar çıktı ama genel olarak büyük bir iyileştirmeydi
  • Acaba o sunum kaydedildi mi diye merak ediyorum

• deepseek gibi bir modeli yerelde çalıştırırsan, sahte bir prompt vermediğin sürece güvenli olduğunu düşünüyorum
  Sonuçta risk unsuru, kullanıcının dışarıdan kopyaladığı promptlar ya da modele internet kaynaklarına erişim veren ayarlardır
  Bunlar eskiden beri IT genelindeki zayıflıklardı; sadece kullanıcı eğitimi ve ağ izolasyonuyla yönetilmesi gereken meseleler

  • Yeni olan şey, basit bir metin girdisinin saldırı vektörü haline gelmesi
    Ticket'lar, belgeler gibi sıradan veriler artık güvenlik riski olabilir
  • Gerçekçilik düzeyi düşük olsa bile bu tür saldırı vektörlerinin mutlaka farkında olmak gerekir
    Birçok güçlü saldırı basit başlangıç noktalarından doğdu

• Bu saldırılar fazla temel güvenlik bilgisi seviyesinde
  Kodu production'a almadan önce gözden geçirmek bile bunu engelleyebilir
  Hiçbir şey bilmiyorsan zaten güvenli olmayan kodu deploy edeceksindir

  • Asıl mesele sadece kod üretiminin başarısız olması değil, modelin jailbreak saldırılarına daha açık olması
    Açık modeller erişilebilirlik açısından iyi ama post-training ile bunun engellenebileceğini sanmak yanıltıcı
  • "Kod review yeter" diye düşünmek tehlikeli
    İkinci saldırıda mesele kod deploy'u değil, LLM'in reddit yorumunu okuyup doğrudan çalıştırmasıydı
    Bu tür sorunları hafife alan tutumun kendisi daha büyük bir güvenlik tehdidi yaratıyor

• Yerel bir LLM'in saldırıya uğrayabileceği fikri kulağa tuhaf geliyor
  Sistem zaten ele geçirilmiş durumdaysa, LLM'i kandırmaktan çok daha büyük zararlar verilebilir gibi duruyor

  • LLM'lerde komut ile veri arasında ayrım yok
    Yani saldırgan veri girdisi üzerinden prompt enjekte edebilir
    Eğer LLM komut çalıştırma yetkisine sahip bir ajansa, bu doğrudan bir komut yürütme zafiyeti olur
  • LLM'i müşteri verilerini sınıflandırmak ya da e-postaları işlemek için kullanıyorsan, bu risk gerçekçi olabilir
  • Yerel model olsa bile pratikte çoğu zaman internete erişebilen bir wrapper'a bağlanıyor (ör. OpenCode, Claude Code vb.)
  • Bu biraz şirket güvenliğindeki "Saldırgan VPN'i aşıp admin yetkisi alırsa ne olacak?" mantığına benziyor
    O noktada zaten her şey bitmiş sayılır

• Bu yazı sanki Anthropic ya da OpenAI satış ekibi tarafından yazılmış gibi hissettiriyor
  Gerçekte yerel modeller nadiren kod çalıştıran ajan olarak kullanılıyor; çoğunlukla veri dönüştürme ya da NLP işleri için güçlüler
  Ben Agno agent ile yerel model kullandığımda, üretilen kodu çalıştırmadan önce her zaman çıktı olarak gösteriyorum ve yerel sandbox ile izole ediyorum
  Bana göre asıl daha riskli olanlar Atlas, Comet gibi tarayıcı tipi ajanlar

• Açık kaynak modeller promptta yazdığı gibi davrandı, kapalı modeller ise bunu görmezden geldi
  Yani alignment testinde başarısız olan taraf ironik biçimde kapalı modellerdi

• "lethal trifecta" ifadesi kulağa hoş geliyor ama gerçek riski iyi anlatmıyor
  Pratikte sadece dış iletişim yeteneği bile yeterince tehlikeli
  LLM'in kendisi zaten doğrulanamayan kara kutu veri yığını gibi; bu yüzden güvenmek zor
  Küçük startup'lar için sorun olmayabilir ama Coinbase gibi bir yerde erişim kısıtlarını iki kez düşünmek gerekir

• Bu, doğrulanmamış kod çalıştırmanın güvenlik paradoksuyla ilgili bir konu
  Yerelde kötü amaçlı ya da doğrulanmamış kod çalıştırıyorsan, önce neden bunu yaptığını yeniden düşünmek gerekir

  • Bu zafiyet, yapay zekanın internetten okuduğu güvenilmeyen veriyi doğrudan işlemesiyle ortaya çıkıyor
    LLM insan dilindeki talimatları kod gibi yorumladığı için, kod ile veri arasındaki sınır bulanıklaşıyor

• LLM'in akıl yürütme yeteneğini güvenlik sınırı olarak kullanıyorsan, zaten büyük bir sorun var demektir
  Böyle bir yaklaşım temelden hatalı bir tasarım

• Girdilere dikkat edilmezse enjeksiyon olabileceği çok açık
  Her sistemde girdi her zaman bir saldırı vektörü olabilir
  LLM'e giren tüm veriler mutlaka doğrulanmalı

  • Saldırganın bu tür promptları nasıl ekleyip gerçek production code'u etkilediğini merak ediyorum
    Acaba tarayıcı tarafında bir cross-site saldırısı benzeri yöntem mi kullanılıyor, bilmek isterim