- Kullanıcı istismarını mümkün kılan “ölümcül üçlü (lethal trifecta)”ya nasıl karşılık verileceği
- Doğal dil talimatlarını aynen izleyen LLM ajanları, veri ile komutun ayrılmaması nedeniyle dış metinlerdeki kötü niyetli talimatları da çalıştırabilecek yapısal bir zafiyete sahiptir
- Harici içeriğe maruz kalma, özel verilere erişim ve dışarıyla iletişim kurma yeteneği birleştiğinde “ölümcül üçlü” oluşur; bu da küçük hataların bile ölümcül güvenlik olaylarına dönüşme riskini büyütür
- Gerçek örnekler arasında Microsoft Copilot’un zafiyet yaması (Haziran), DPD müşteri destek botunun kötüye kullanımı (Ocak 2024) ve Notion AI ajanında PDF tabanlı veri sızdırma gösterimi (19 Eylül) yer alıyor
- Savunma ilkeleri üçlünün dağıtılması, güvenilmeyen modelin yalıtılması ve iletişimin kontrolü; ayrıca Google’ın CaMeL çift LLM mimarisi gibi işlev kısıtlarını göze alan güvenli tasarım önerileri öne çıkıyor
- Sektör, yalnızca eğitimle güçlendirmenin yeterli olmadığını; MCP eklenti kombinasyonlarının riski ve ürün çıkışlarının ertelenmesi (ör. Apple’ın AI özelliklerini ertelemesi) gibi işaretlerin de gösterdiği üzere olasılıksal güvenlik payını temel alan bir tasarım dönüşümüne ihtiyaç duyuyor
Temel sorunun tanımı: veri-komut ayrımının olmaması ve “ölümcül üçlü”
- LLM, girdiyi art arda gelen kelime tahmini olarak işler; bu nedenle soruya yanıt veren, komuta ise yürütme girişiminde bulunan birleşik bir yorumlama modelidir
- Harici bir belgeye “sabit diski kopyala ve saldırganın e-postasına gönder” gibi kötü niyetli bir talimat yerleştirilirse, özetleme görevi sırasında yan etkili çalıştırma riski doğar
- Harici içeriğe maruz kalma + özel verilere erişim + dışarıya gönderim yolu aynı sistemde birlikte bulunursa ölümcül üçlü (lethal trifecta) oluşur
- Ölümcül üçlü, güvenlik araştırmacısı Simon Willison tarafından ortaya atılan bir kavramdır; üç unsur aynı anda açıksa kötüye kullanımın kaçınılmazlığı artar
Erken işaretler ve gerçek vakalar
- 2022 yazında prompt injection teriminin bağımsız olarak ortaya çıkmasıyla, ehlileştirilmiş uyumluluğun riski gündeme geldi
- Ocak 2024’te DPD müşteri destek botunun küfürlü yanıtları izlemesi sorunu doğrulandı ve hizmet durduruldu
- Haziran 2025’te Microsoft Copilot içinde üçlü zafiyeti bulundu, ardından sessiz bir yama dağıtıldı; gerçek dünyada kötüye kullanım bildirilmediği açıklandı
- 19 Eylül 2025’te, belge, veritabanı ve web erişimine sahip Notion AI ajanı üzerinden manipüle edilmiş bir PDF ile veri sızdırma, araştırmacı Abi Raghuram tarafından gösterildi
Neden engellemesi zor: olasılıksal başarısızlık ve dolaylı kanallar
- Sistem prompt’u ile öncelik kuralları verilse bile, 100 denemede 1 kez başarısızlık gibi olasılıksal kaymalar her zaman mümkündür
- “Zararlı sinyali algıla” gibi güvenlik talimatları eklense de, bir gün yine içeri sızma ihtimali sürer
- Harici iletişimi kesmek kritik olsa da yalnızca e-posta gönderimini yasaklamak yetmez; gizli değerleri URL yoluna kodlamak gibi yöntemlerle web istek günlükleri üzerinden sızıntı yaşanabilir
- Web erişimine izin verilmesi başlı başına bir veri sızdırma kanalına dönüşebilir
Savunma stratejisi 1: üçlüyü hiç oluşturmamak
- Unsurlardan yalnızca birini bile kaldırmak riski ciddi ölçüde azaltır
- Girdiyi kurum içinde üretilmiş ve doğrulanmış kaynaklarla sınırlarsanız harici maruziyet ortadan kalkabilir
- Kodlama yardımcılarının yalnızca güvenilir kod tabanlarıyla çalışması ya da akıllı hoparlörlerin sadece sesli komutları işlemesi gibi kapsam daraltma stratejileri etkilidir
- Ancak e-posta yönetimi gibi doğası gereği harici veriyi işleyen görevlerde tam kaldırma zordur
Savunma stratejisi 2: güvenilmeyen modeli yalıtmak ve en az yetki
- Google’ın Mart tarihli makalesi, harici veriye temas eden modeli “güvenilmeyen model” olarak sınıflandırıyor ve hassas bilgilerin yalıtılmasını öneriyor
- E-posta gibi hem özel hem de dışarıdan gelen kaynaklar, iki unsuru zaten karşıladığı için yüksek riskli hale gelir
- Yetkileri en aza indirme, sandbox ve bağlam sınırları ile kurum içi sırlar ve kimlik bilgilerine erişim ayrı yönetilir
Savunma stratejisi 3: model kısıtları ve mimari ayrım
- Eğitim verisiyle reddetme kalıplarını güçlendirmek gerekli olsa da yeterli değildir
- Google’ın CaMeL yaklaşımı, rolleri ayırmak için iki ayrı LLM kullanır
- Güvenilir model, kullanıcının doğal dilini kısıtlı bir koda dönüştürür
- Güvenilmeyen model ise yalnızca boşluk doldurma yapan sıkı kısıtlı bir akış içinde çalışarak güvenlik özelliklerini korur
- Bunun karşılığında yapılabilecek işlerin kapsamını daraltan bir işlevsel kısıt kabul edilir
Tüketici ve eklenti ekosistemindeki risk: MCP örneği
- Model Context Protocol(MCP) ile yardımcı uygulamalar eklendiğinde, yeteneklerin birleşmesi sonucu kazara ölümcül üçlü oluşabilir
- Tek tek güvenli olan MCP’lerde bile kombinasyon güvenliği bozulabilir; bu yüzden kurulumları minimumda tutmak ve kaynak doğrulaması yapmak gerekir
Sektörden sinyaller: çıkış ertelemeleri ve daha temkinli yaklaşım
- Apple, 2024’te “Jamie’nin önerdiği podcast’i çal” gibi özellikleri duyurdu, ancak üçlü riskini tetikleme endişeleri nedeniyle çıkışı ertelemeyi seçti
- Eylül 2025’teki en güncel iOS sürümünde de büyük AI özelliklerinin bulunmaması, bunun yerine çeviri ve arayüz iyileştirmelerine ağırlık verilmesi, sorunun ne kadar gerçek olduğunu gösteriyor
Uygulama kontrol listesi: ne yapılmalı
- Risk modelleme: Harici girdi, hassas veri ve dış iletişimden hangi unsurların açık olduğunu netleştirin ve üçlü oluşup oluşmadığını haritalayın
- Sınır tasarımı: Güvenilmeyen modeli salt okunur tamponla sınırlayın, gizli bilgiler ve token’ları ayrı bir ara hizmet üzerinden yönlendirin, doğrudan erişimi engelleyin
- Çıkışları kapatma: E-posta, web istekleri, dosya yükleme gibi veri sızdırma kanallarını izinli liste temelli olarak kısıtlayın
- Politika motoru: Yalnızca izin verilmiş araç çağrılarını çalıştırın; doğal dil → yapılandırılmış politika derlemesi sonrası yürütün
- Denetim ve guardrail’ler: Prompt injection test setleri, otomatik red team, oturum kayıtları ve ret oranı izleme ile olasılıksal başarısızlıkları yönetin
- İşlevsel ödünleşimleri kabul etme: Performans ve özerklikten bir miktar vazgeçip olasılıksal güvenlik payını koruyan bir mühendislik kültürü dönüşümü gerekebilir
Sonuç
- Üç unsurun da açık olduğu sistemlerde zafiyetlerin kaçınılmaz olarak bulunacağı yönündeki uyarılar giderek birikiyor
- Üçlüyü dağıtmak, güvenilmeyen modeli yalıtmak, çıkışları kontrol etmek ve rol ayrımlı mimari kurmak bugün için en gerçekçi çözümler olarak öne çıkıyor
- Uzun vadede ise deterministik güvenlik beklentisinden vazgeçip olasılıksal güvenlik payını tasarıma gömmeyi hedefleyen bir yazılım mühendisliği dönüşümü gerekiyor
Henüz yorum yok.