AI'nin "ölümcül üçlü tehdidi" nasıl durdurulur

• LLM'ler, kod ile veriyi ayıramayan yapısal bir soruna sahip oldukları için prompt injection saldırılarına karşı savunmasızdır
• Özellikle harici verilere erişim, dahili sırları okuma ve dış dünya ile iletişim kurma yetkisi aynı anda verildiğinde, sözde ölümcül üçlü (lethal trifecta) ortaya çıkar ve ciddi zararlara yol açabilir
• Yapay zeka mühendisleri makine mühendisleri gibi düşünmeli; deterministik yaklaşım yerine olasılıksal sistemlerin belirsizliğini kabul eden ve güvenlik payı bırakan bir yönteme ihtiyaç vardır
• Viktorya dönemi mühendisleri malzemelerin belirsizliğine karşı aşırı tasarımla güvenlik payı bıraktığı gibi, yapay zeka sistemlerine de güvenlik sınırları, risk toleransı ve hata oranları eklenmelidir
• Fiziksel dünyadaki köprülerin yük sınırları olduğu gibi, yapay zeka sistemleri için de açık sınırlar ve güvenlik payı tanımlayan normlara ihtiyaç duyulan bir dönemdeyiz

---

LLM'lerin özündeki güvenlik sorunu

• Büyük dil modelleri, kod ile veriyi ayıramayan yapısal bir kusur taşır
• Bu nedenle prompt injection saldırılarına açıktırlar
  • Sistemin uymaması gereken komutlara uymasını sağlamak için kandırılması
  • Bazı durumlarda müşteri destek ajanının korsan gibi konuşmasına neden olmak gibi yalnızca utandırıcı sonuçlar doğurabilir
  • Diğer durumlarda ise çok daha yıkıcı zararlar ortaya çıkabilir

Ölümcül Üçlü (Lethal Trifecta)

• En kötü etkiler, "ölümcül 3 unsur" oluştuğunda görülür
• Bu 3 unsur şunlardır
  • Güvenilmeyen verilere erişim yetkisi
  • Önemli gizli bilgileri okuyabilme yeteneği
  • Dış dünya ile iletişim kurabilme yeteneği
• Şirketler çalışanlarına güçlü bir yapay zeka asistanı vermeye çalışırken bu üçünü aynı anda sağlarsa ciddi sorunlar kaçınılmaz olur
• Yalnızca yapay zeka mühendislerinin değil, genel kullanıcıların da yapay zekayı güvenli kullanmayı öğrenmesi gerekir
  • Yanlış uygulama kombinasyonları yüklenirse bu 3 unsur tesadüfen oluşabilir

Yapay zeka mühendislerinin düşünme biçimini değiştirmesi gerekiyor

Makine mühendisi gibi düşünmek

• Daha iyi yapay zeka mühendisliği ilk savunma hattıdır
• Yapay zeka mühendisleri köprü gibi yapılar inşa eden mühendisler gibi düşünmelidir
  • Kötü işçiliğin insan hayatına mal olabileceğini kabul ederek

Viktorya dönemi mühendisliğinden alınacak dersler

• Viktorya dönemi Britanyası'nın büyük yapıları, malzeme özelliklerinden emin olamayan mühendisler tarafından inşa edildi
  • O dönemde demir, yetersizlik veya sahtekârlık nedeniyle sık sık düşük kaliteliydi
  • Sonuç olarak mühendisler ihtiyatlı davranıp aşırı tasarımla fazladan dayanıklılık entegre etti
  • Bunun sonucunda yüzyıllar boyunca ayakta kalan başyapıtlar ortaya çıktı

Günümüz yapay zeka güvenliği sektörünün sorunu

• Yapay zeka güvenlik sağlayıcıları bu şekilde düşünmüyor
• Geleneksel kodlama deterministiktir
  • Güvenlik açıkları düzeltilmesi gereken hatalar olarak görülür
  • Düzeltildiğinde ortadan kalkarlar
• Yapay zeka mühendisleri okul yıllarından beri bu düşünme biçimine alışkındır
  • Bu yüzden sorunun yalnızca daha fazla eğitim verisi ve daha akıllı sistem prompt'larıyla çözülebileceği gibi davranırlar

Olasılıksal sistemlere uygun yaklaşım

Eğitim verisi ve prompt'ların sınırları

• Eğitim verisi ve akıllı prompt'lar riski azaltır
  • En akıllı son model sistemler, kötü niyetli istekleri tespit edip reddetmede önceki ya da daha küçük modellere göre daha iyidir
• Ancak riski tamamen ortadan kaldıramazlar
  • Çoğu yazılımdan farklı olarak LLM'ler olasılıksaldır
  • Çıktılar, olası yanıtlar arasından rastgele bir seçime göre belirlenir
  • Bu nedenle deterministik güvenlik yaklaşımı uygun değildir

Fiziksel dünya mühendisliğini örnek almak

• Daha iyi yöntem, fiziksel dünyanın mühendislerini örnek almaktır
• Öngörülemez sistemlerle birlikte çalışmayı öğrenmek
  • Amaçlandığı gibi çalışacağı garanti edilemeyen kaprisli sistemlere karşı savaşmak yerine onlarla birlikte çalışmak
• Güvenlik payı, risk toleransı ve hata oranları getirerek öngörülemezliği daha rahat yönetmek

Yapay zeka çağında aşırı tasarım stratejisi

• Gerekli olandan daha güçlü modeller kullanmak
  • Uygunsuz davranışlara kandırılma riskini azaltır
• LLM'nin harici kaynaklardan alabileceği sorgu sayısına sınır koymak
  • Kötü niyetli sorguların verebileceği zarar riskine göre ayarlanmalı
• Güvenli biçimde başarısız olmayı vurgulamak
  • Yapay zeka sisteminin gizli bilgilere erişmesi gerekiyorsa ona krallığın anahtarlarını teslim etmekten kaçınılmalıdır

Güvenlik sınırları belirleme ihtiyacı

• Fiziksel dünyada köprülerin yük sınırları vardır
  • Sürücülere her zaman açıkça gösterilmese de bu sınırlar mevcuttur
  • Kritik nokta: Bu sınırlar, hesaplamalara göre köprünün kaldırabileceği gerçek tolerans aralığının içinde yeterli güvenlik payı bırakır
• Artık yapay zeka sistemlerinin sanal dünyasının da benzer şekilde donatılmasının zamanı geldi
• Açık güvenlik sınırları ve payları olan sistemler tasarlamak zorunludur

[GN⁺]

Hacker News görüşü

• Arşivlenmiş makale bağlantısı
• Bu hafta Economist’te lethal trifecta’dan bahseden ikinci yazı bu. İlki AI sistemleri asla tamamen güvenli olmayabilir — ele alınması gereken “ölümcül üçlü tehdit” idi; medyada prompt injection’ın ne olduğu ve neden tehlikeli olduğu konusunda gördüğüm en net açıklamaydı. İçinde benden alıntı yapılan bir bölüm de var, o yüzden biraz taraflı olabilirim ama yöneticilere özellikle tavsiye edeceğim bir yazı. Bu yeni makaleyi ise pek beğenmedim. LLM’lerin deterministik olmaması yüzünden güvenlik açıklarını düzeltmenin zor olduğundan söz ediyor ve bu yüzden köprülerde olduğu gibi “aşırı mühendislik” yapıp tolerans payı bırakmak gerektiği benzetmesini kullanıyor. Köprüler için doğru olabilir ama güvenlik açıkları için kökten bir çözüm olduğunu düşünmüyorum. Bir sistem 100 denemenin sadece 1’inde bile prompt injection’a yenik düşüyorsa saldırgan sonuna kadar varyasyon denemeye devam eder. lethal trifecta’nın (özel verilere erişim, güvenilmeyen komutlara maruz kalma, dışarı sızdırma yolu) herhangi bir ayağı kesilirse saldırı gerçekleşemez
  • Köprü inşaatçıları çoğunlukla düşmanca saldırılara göre tasarım yapmaz. Yapsalar bile, daha sağlam hale getirmekten çok kolay taşınabilmesi ve hızlı yeniden konuşlandırılmasına odaklanırlar. Bombardımandan sağ çıkacak aşırı sağlam bir köprüdense, bir geçici köprü daha kurmak daha hızlı ve daha ucuzdur. Somut örnek
  • LLM’ler insanlar gibi deterministik değildir. Bu yüzden güvenlik yönetimine de insanlardaki gibi yaklaşabilirsiniz. Gerekli rol tabanlı erişim kontrolüyle sadece asgari yetki vermek, riskli ya da maliyeti yüksek işler için de onay süreci işletmek gerekir. Teknoloji, altyapı, savunma, finans gibi kritik kurumlarda tehdit modelini, ekip içinde Rusya, Çin, İsrail, Kuzey Kore gibi yabancı devletlerin ajanlarının bulunabileceği varsayımıyla kurmak zaten temel yaklaşımdır
  • Aslında iki yazı da aynı yazı. Economist, her haftaki sayısının başında “Leaders” adlı bir yazı serisi yayımlıyor; aynı sayıda yer alan derinlikli yazıları kısaltıp genelleştiriyor. Yani tüm gazetede ters piramit yapısını (ters piramit açıklaması) uyguluyor denebilir. Bu kez de bağlantısı verilen yazı, sorunlu asıl yazının bir özet sürümü gibi işliyor
  • LLM’lerin güvenlik sorununu “Kodum sosyal mühendislik saldırılarına kanabilseydi ne olurdu?” diye düşünüyorum. LLM’ler de insanlar gibi, ne kadar eğitilirse eğitilsin kandırılabilir. Bir bilgisayarda root yetkisi verip dünyanın her yerinden herkesin LLM ile konuşmasına izin verirseniz, eninde sonunda açık verecektir. İnsanlara sınırsız yetki devretmediğimiz gibi, LLM’lere de istekte bulunan kişiyle ilgisiz verilere erişim ya da kullanıcı verisini değiştirme gibi izinler verilmemeli
  • Sorun, lethal trifecta’nın yalnızca bir tarafını kesmenin yeterli olduğunun söylenmesi. Oysa bu üç unsur birbirine dolanmış durumda. Örneğin e-posta gibi dış içerik de kişisel veri olabilir ve e-posta göndermek, gelen kutumun içeriğini saldırgana sızdırabilir. Ayrıca e-posta, GitHub vb. en kullanışlı hâline hem gönderme hem alma yapabildiğinde geliyor; her işlev için ayrı bir sunucu kurmak da verimsiz
• Makine mühendisliği geçmişimden bakınca bu yazı yetersiz geliyor. “Biraz daha dayanım ekleyelim” sözü sık duyulur ama gerçekte bunu uygulayabilmek için farklı arıza modlarını ayrıntılı biçimde anlamak gerekir. lethal trifecta da sadece bir arıza modu; onu engellemek için “dayanım” ekleniyor. “Bu köprü fazla titreşiyor → titreşen köprüden güvenle nasıl geçilir diye düşünelim” değil, köprüyü baştan aşırı titreşmeyecek şekilde değiştirmek gerekir
  • Dünya delirmiş gibi geliyor. Bu köprü benzetmesine göre, yıllardır köprü yapmayı biliyoruz ama arada sırada zeminin aniden kaybolup insanların nehre düşmesi gibi bir şey oluyor ve buna rağmen “başka bir yöntem düşünelim” yerine “alta ağ gerelim, düşenleri toplayalım” deniyor. Temelde öngörülemez bir teknolojinin üstüne milyarlar döküyoruz, sonra da sadece biraz daha korkuluk ekleyerek çözdüğümüzü sanıyoruz. Gerçekten akıl dışı
  • Makalede “coders need to” ifadesini görünce ilgimi hemen kaybediyorum. Benzetmenin kendisi yanlış geliyor ve o alanda gerçekten deneyimi olanlara da tuhaf geliyordur diye düşünüyorum. Gazetecinin örnek verdiği “şirkette LLM’nin aynı anda güvenilmeyen veri, önemli bilgi ve dış iletişimle çalışabilmesi” koşulunun kendisi zaten sorunlu. Şirketler çoğu zaman güvenlikten çok işlevselliğe öncelik vererek bu riski yaratıyor. “LLM’ler olasılıksal olduğu için deterministik yaklaşım uygun değil” iddiası mantık sıçraması. Deterministik olmasa da sandbox mantığı hâlâ geçerli; başka bir deyişle benzetmeyi fazla uzatmak alanın kendisine fayda etmek yerine zarar veriyor. İlgili terimleri ve alan bilgisini kullanmak daha iyi olurdu ama o zaman da haber olarak cazibesi azalırdı herhâlde
• Yoksa makale gerçekten sadece hız sınırı koymayı ve daha iyi modeller kullanmayı mı çözüm diye sundu? Yazılım mühendisleri bunları onlarca yıl önce zaten çalışmıştı. Bu sektör güvenlik konusunda yanıtları biliyor; sorun, bunların AI ürünlerini apar topar piyasaya sürme anlayışıyla uyuşmaması
  • AI da artık aynı IT alanının parçasıysa, o zaman sonuç olarak “biz güvenliği anlamamışız” demek gerekir. AI konusunda dikkatsiz olduğumuz iddiası gerçeği yansıtmıyor. Veriyle komut token’larını kusursuz biçimde ayırmanın yolu yok; bu dikkatsizlikten değil, temel bir sınırdan kaynaklanıyor. “Bunları onlarca yıl önce çözmüştük” demek kibirli bir yaklaşım
  • “Güvenliği onlarca yıl önce çözmüştük” tarzı laflar, yeni bir sektör eski kötü standartları yeniden üretip aceleyle “AI ürünü” çıkarmaya çalıştığında ortaya çıkıyor. MCP standardı gibi şeylerin daha baştan delik deşik olduğu örnekler düşünülünce, “prompt’u iyi yazalım” yaklaşımı gülünç kalıyor. En büyük sorun, AI sektöründeki neredeyse herkesin MCP sunucusunun veritabanına doğrudan erişmesini pek sorgulamadan tasarlamış olması. Mümkün diye yapılmasının şart olmadığını gösteren iyi bir örnek bu; bu kadar zayıf güvenlik yüzünden sayısız AI ürünü gerçekten ihlal ediliyor
  • “Biz zaten güvenliği biliyoruz” iddiası da pratikte doğru değil. İnsan unsuruna geldiğinizde hiç değil; milyarlar harcanıp tekrar tekrar eğitim verilse bile etkinlik giderek azalıyor. Yakın zamanda çok iyi güvenlik uzmanlarının bile YouTube’daki basit phishing saldırılarına kandığı örnekler gördük
• Orijinal @simonw yazısı: The lethal trifecta for AI agents, ayrıca ilgili ek yazı da okunabilir. HN’deki ilgili tartışma bağlantısını da bırakıyorum
• lethal trifecta, LLM’nin aynı anda güvenilmeyen verilere erişmesi, önemli bilgileri görebilmesi ve dış iletişim kurabilmesi durumunda ortaya çıkan sorun demek. Çözüm de sınırları (yetkileri) yöneterek riski düşürmek; yani oldukça temel Security 101 seviyesi
  • Doğru ama pratikte güvenlik ile işlevsellik arasında ciddi bir gerilim oluşuyor. Kişisel verilerle faydalı işler yaptırmak istediğiniz anda prompt injection açığı da kapıyı aralıyor. Ayrıca ilgili bağlamı olabildiğince bir araya getirmek ajan verimliliği için etkili olsa da, güvenilmeyen girdiyi okuyan ajanı tamamen ayırıp izole etmek faydayı da düşürüyor. İlgili blog
  • Bu da teknik olarak yalnızca temel access control meselesi. İnternete bağlandığı anda risk keskin biçimde artıyor. Çok iyi bir güvenlik araştırmacısı varsa tek bir prompt injection ile tüm sistemi ele geçirip koşullardan en az birini hemen sağlayabilir
• LLM’ler prompt ile veriyi ayırmıyor. NX bit (execute disable bit) benzeri bir kavram yok ve buna benzer bir şeyin uygulanmış örneği de bulunmuyor. Tabii NX bit geldikten sonra bile remote code execution tamamen bitmemişti; yani bu tek başına kusursuz bir savunma olmazdı. Şu anda en gerçekçi yöntem, mevcut güvenlik mekanizmalarıyla LLM ajan sürecini yönetmek. Örneğin ayrı bir kullanıcı hesabıyla çalıştırıp dosya erişimini kısıtlamak, buna ağ, donanım ve cgroups sınırlamaları eklemek. Yine de güvenilmeyen verinin içine komut karışırsa, LLM’nin gizli verileri de dışarı sızdırma riski sürüyor. Kullanıcı LLM çıktısını fark etmeden dışarı kopyalarsa sızıntı yolu yeniden açılmış oluyor
  • “Buna benzer bir şeyi yapan kimse yok” deniyor ama gerçekten deneyen biri oldu mu, buna uygun eğitim verisi bile var mı merak ediyorum. Sosyal canlılar doğal olarak compartmentalization yapar. Köpekler bile insanların tepkisini ölçüp yiyeceğin varlığını gizleyebilir. Ben de çocuk büyütürken, sosyal yaşam, gizli bilgi, çocuğun kişisel verileri, çocuğun henüz kaldırabileceği türden olmayan bilgiler, iç dünyam ve güvenilmeyen kaynaklardan öğrendiklerim arasında bilgiyi ayırarak yönetiyorum. Zeka önemli ama wisdom hâlâ LLM alanında birinci sınıf bir değerlendirme konusu değil. Şu an köpek yavruları ve küçük çocuklar bile bu compartmentalization yeteneğinde önde gidiyor
• İlgili derinlikli makalede etkileyici bir alıntı gördüm: Google’ın önerdiği CaMeL sistemi, lethal trifecta’nın risklerinin bir kısmını iki LLM kullanarak aşmaya çalışıyor. Biri sadece güvenilmeyen verilere erişiyor, diğeri diğer her şeyi ele alıyor. Daha güvenilir model, kullanıcının doğal dil komutlarını sınırlı kapsamdaki koda dönüştürüyor; güvenilmeyen model de bu kodun boşluklarını dolduruyor. Bu yapı güvenlik garantisi sağlıyor ama bunun karşılığında LLM’nin yapabileceği işlerin kapsamını ciddi biçimde daraltıyor. Bunu ilk kez duyuyorum; gerçekten ne kadar etkili olduğunu merak ettim. Gerçekten “mutlak” güvenlik sağlıyor mu, ne tür kısıtlar getiriyor, pratik bir alternatif olabilir mi? Makale kaynağı
  • CaMeL makalesi üzerine uzun süre düşündüm. Oldukça iyi bir yaklaşım ama gerçek dünyada uygulaması epey zor ve sistem ancak oldukça sınırlı işlevler sunabiliyor. Analiz yazımda toparlamıştım
• “AI mühendisleri de köprü inşası gibi can kaybına yol açabilecek alanlardaki gerçek mühendisler gibi düşünmeli” benzetmesi geçiyor. “AI mühendisleri okuldan beri, daha fazla eğitim verisi ve daha akıllı prompt olursa sorunun çözüleceğine inanmaya şartlanmış durumda” gibi bir ifade kullanılıyor
  • Buradaki “AI mühendisleri gerçek mühendisler gibi düşünmeli” sözü, sadece yazılım mühendisi gibi değil, gerçek mühendis gibi; artık yazılım köprülere ve arabalara da girdiğine göre en azından fiziksel sistem mühendislerinin düşünme biçimini edinmeleri gerektiği anlamına geliyor
  • Sanki yazılım mühendisliği lisansı ya da etik sertifikasyonu gibi şeyler gerekmeli demeye getiriyor. Ama etik dışı olsa da yasal olan yazılımlar çok yüksek kazanç ürettiği için, bu tür fikirlerin pratikte uygulanması zor görünüyor
  • “Daha iyi eğitim verisi olursa çözülür” düşüncesinin vardığı yer, sonunda bu tür trajik zararların da eğitim verisine dönüşmesi
  • Sadece yazılım “mühendisi” değil, “mimar” rolünü de unutmamak gerekir
• LLM hesaplarını otomatik izleyip girdileri filtreleyen/pipeline’dan geçiren bir yazılım ürününü küçük bir abonelik ücretiyle SaaS olarak sunmanın ticari fırsat olup olmayacağını düşünüyorum