Doğrusu, LLM güvenliği deyince çoğu kişinin aklına hâlâ tek bir şey geliyor: mesajı tara, riskliyse kes (şaşırtıcı ama gerçek) (bu konuda ikircikliyim). Kağıt üstünde mantıklı. Pratikte ise biraz komik, çünkü saldırganlar tek satırlık oyun oynamıyor. Mesajı parça parça veriyor, niyeti zamana yayıyor, modeli kendi ağzıyla konuşturuyor. İşin can sıkıcı tarafı da bu zaten.
Şunu söyleyeyim, Geçen ay, 2025 Mart ortasında İstanbul’da bir ürün ekibiyle konuşurken tam bu konuyu masaya yatırdık. Onların chatbot’u tek mesaj bazlı filtreyi geçiyordu. Üç-dört tür sonra kullanıcıya garip komutlar döndürmeye başlıyordu. Hani ilk bakışta “bir şey yok” diyorsun… sonra zincir bir anda tamamlanıyor. Benzer bir şeyi 2024 Kasım’da Berlin’de küçük bir SaaS demo ortamında da görmüştüm; orada saldırı o kadar sessiz ilerledi ki, loglara bakmadan fark etmek neredeyse imkânsızdı. Gerçekten sinir bozucu bir şey.
Bu yazıda olayın özünü kendi bakış açımdan anlatacağım: çok turlu prompt injection nedir, neden klasik filtreler kaçırıyor. ML kullanmadan nasıl daha sağlam bir savunma kurulur? Açık konuşayım, burada “sihirli çözüm” yok. Ama iyi kurgulanmış sezgisel kurallar, zamanla azalan risk puanı ve birkaç akıllı desen yakalaması baya iş görüyor.
Tek mesajı incelemek yetmiyor; saldırının asıl gücü cümlelerin arasına saklanmasında yatıyor. Yani model değil, konuşmanın akışı hedef alınıyor.
Neden tek mesajlık filtreler yetmiyor?
Bunu yaşayan biri olarak söyleyeyim, Bakın şimdi, klasik yaklaşım şöyle çalışıyor: her kullanıcı mesajına ayrı ayrı skor veriliyor. Kötü anahtar kelime var mı? Şüpheli pattern var mı? İmza benziyor mu? Yoksa geç gitsin. Bu yöntem fena değil, hatta basit senaryolarda işini görüyor. Ama çok turlu saldırıda mesele zaten tek bir kötü cümle kurmak değil ki.
Dürüst olmak gerekirse, Saldırgan önce masum gibi görünen bir bilgi yerleştiriyor (şaşırtıcı ama gerçek). Sonra ikinci turda bu bilgiyi yeniden tanımlıyor. Üçüncü turda da sistemi tetikliyor. Mesela “ALPHA kod sözcüğü” gibi zararsız başlayan şeyler, birkaç mesaj sonra “önceki talimatları unut” anlamına dönüşebiliyor — bir an düşünün, ilk turda alarm vermeyen metinler birlikte okununca aslında dümdüz jailbreak oluyor. Ciddi sorun bu.
Ben bunu ilk kez 2023’te kendi yan projemde test ederken fark etmiştim; Ankara’daki ev ofisimde iki saat boyunca “neden hiçbir şey yakalanmıyor?” diye ekranın içine baktığımı hatırlıyorum. Sebep netti: savunma katmanı hafızasızdı. Her turu yeni doğmuş gibi değerlendiriyordu. Saldırgan için de bundan kolay ne var?
Hmm, bunu nasıl anlatsamdı…
Üç yaygın çok turlu saldırı tipi
Crescendo denilen türde saldırgan sınırı azar azar zorlar. İlk mesaj sıradan olur, ikincisi hafif yön değiştirir, üçüncüsü ise açık kapıyı iter ve içeri dalar. Buradaki tehlike şu: hiçbir satır tek başına kırmızı bayrak gibi görünmüyor. Hiç.
Doğrusu, Payload splitting ise yükü parçalamak demek. Yani kötü niyetli komut tek satırda durmaz; beş farklı mesaja bölünür. İnsan okuyunca bile bazen fark etmezsiniz… modelin kaçırması şaşırtıcı değil aslında.
İlginç olan şu ki, Context poisoning ise bence en sinsisi. Modeli önce belli bir şeyi kabul etmeye zorlarsınız, mesela “evet, şu kod sözcük işe yarar” dedirtirsiniz. Sonra o kabulü kullanıp sonraki aşamada sistemi kandırırsınız. İşin aslı şu ki burada model kendi geçmiş cevabına karşı savunmasız kalıyor — ve bunu engellemek düşündüğünüzden zor.
- Crescendo: Kademeli baskı yapar. (bence en önemlisi)
- Payload splitting: Kötü komutu parçalara ayırır.
- Context poisoning: Önce kabul alır, sonra onu silah yapar.
Kafadaki ML fikri neden ilk başta çekici geliyor?
E tabi insanın aklına ilk olarak makine öğrenmesi geliyor. Büyük veri var, sınıflandırıcı kurulur, güzelce eğitilir… kulağa düzgün geliyor değil mi? Ama dur bir saniye — proxy seviyesinde çalışan bir güvenlik katmanında gecikme can sıkıyor. Kullanıcı sohbet ederken araya eklenen ekstra 200-500 milisaniye bazen anlaşılır derecede hissediliyor. Hele bir de de mobilde.
Bunu geçen sene Haziran ayında Londra merkezli bir fintech demosunda bizzat gördüm; ekip ML tabanlı filtreyi beğenmişti ama canlı kullanımda sohbet ritmi bozuluyordu. Küçük startup için bile bu rahatsız edici olabiliyor, enterprise tarafında ise iş büyüyünce maliyet daha da kabarıyor. Üstelik mesele sadece gecikme değil; başka bir LLM’i savunma amaçlı kullanıyorsanız zincirin kendisi de kırılgan hale geliyor. Yani biraz ironik bir durum bu.
Şöyle düşünün: bir evi yangından korumak için yine ateşe bağımlıysanız biraz tuhaf olurdu. Burada da savunmayı model davranışına fazla bağlamak aynı riski taşıyor (ki bu çoğu kişinin gözünden kaçıyor)
Zamana yayılan skor mantığı nasıl çalışıyor?
Burada yapılan şey aslında oldukça insani. Her mesajı tek başına yargılamıyorsunuz, önceki izleri de hesaba katıyorsunuz ve eski sinyalleri zamanla solduruyorsunuz — tam çay demini düşünün, bir noktadan sonra acılık azalıyor. Böylece üç gün önceki ufak şüphe ile son dakika gelen sert sinyal aynı ağırlıkta kalmıyor.
Kullandığım yaklaşımda her oturum için kümülatif risk tutuluyor ve eski puanlar decay faktörüyle azalıyor. Diyelim ki decay değeri 0.9 olsun; bu durumda geçmişteki sinyal yavaş yavaş etkisini kaybeder ama peş peşe gelen zayıf işaretler birleşince eşik aşılıyor. Mantık sade. Ama etkili. Daha fazla bilgi için Apple’ın MacBook Neo çıkmazı: İnce çizgi kalınlaştı yazımıza bakabilirsiniz.
Ve işler burada ilginçleşiyor.
| Mekanizma | Açıklama | Neden işe yarıyor? |
|---|---|---|
| Kümülatif skor | Tüm oturum boyunca risk topluyor | Turlar arasındaki bağlantıyı görüyor |
| Temporal decay | Eski sinyallerin etkisini azaltıyor | Sonsuza kadar suçlu bırakmıyor |
| Eşik kontrolü | Puan belli seviyeyi geçince blokluyor | Anlık karar verdiriyor |
Kod tarafında fikir basit ama etkili
class MultiTurnTracker:
def __init__(self, decay=0.9, threshold=0.7):
self.sessions = {}
self.decay = decay
self.threshold = threshold
def analyze(self, session_id, single_turn_score):
session = self.sessions.get(session_id, {
"cumulative": 0.0,
"scores": [],
"patterns": []
})
session["cumulative"] *= self.decay
session["cumulative"] += single_turn_score
session["scores"].append(single_turn_score)
patterns = self._detect_patterns(session)
if session["cumulative"] > self.threshold:
return "BLOCK", session["cumulative"], patterns
self.sessions[session_id] = session
return "PASS", session["cumulative"], patterns
Bunu okurken “bu kadar mı?” diyebilirsiniz. Evet, temel fikir bu kadar sade olabiliyor — çünkü esas yük hesapta değil, stratejide yatıyor. Sistem konuşmayı hatırladığı anda oyun değişiyor. Tamamen.
Dessene bakmak neden ham puandan daha değerli?
Sadece sayı toplamak iyi bir başlangıç ama yetmiyor. Şunu da ekleyeyim: bazı saldırılar düşük puan üretmek için özellikle inceltilmiş olur. O yüzden ben desen analizi olmadan rahat etmem açıkçası. Mesela aynı oturum içinde tekrar eden kelime köprüleri ya da kullanıcıyı belli terimleri benimsetmeye çalışan cümleler direkt dikkat çekiyor (şaşırtıcı ama gerçek). Bu tarz ipuçları makine öğrenmesinden bağımsız olarak yakalanabiliyor — ve bu önemli bir fark. AI Reasoning Sistemleri: Zihin Teorisi Gerçekten Geldi mi? yazımızda bu konuya da değinmiştik.
Aklımdaki üç kontrol genelde şunlar oluyor: tekrar eden kod sözcükler, rol değişimi girişimleri (eh, fena değil). Geçmiş cevaba yaslanan yönlendirmeler. İlk başta bunlar biraz kaba görünüyor. Ama açık söyleyeyim, kaba olmak bazen iyidir. Mesela prod ortamında “hafifçe agresif” kurallar seni daha çok kurtarıyor (şaşırtıcı ama gerçek). Beklediğim kadar cilalı olmayabilir ama pratikte faydalı. Bu konuyla ilgili Vibe Coding Paradoksu: Hafta Sonu Hızına Kurumlar Neden Yetişemiyor? yazımıza da göz atmanızı tavsiye ederim.
Dikkat ettiğim pratik işaretler
- Aynı kavramın farklı cümlelerde giderek sertleşmesi
- Kullanıcının modele yeni bir rol atamaya çalışması
- Daha önce konuşulmamış gizli anahtarların sonradan aktifleşmesi
- Cevapların giderek talimat formuna dönüşmesi
Küçük startup ile enterprise arasında fark nerede?
Açıkçası, Küçük startup tarafında öncelik hızdır. Bir proxy’nin hızlı açılması gerekir; ekip iki haftalık geliştirme penceresinde sorunu halletmek ister. Burada heuristik tabanlı sistem baya mantıklı. Az bağımlılık var, açıklaması kolay ve debug etmek rahat. Log’a bakarsınız… sorun çıkarsa hangi kural patladı hemen görürsünüz. Hepsi bu.
Enterprise dünyasında resim biraz değişiyor. Daha fazla tenant var, daha karmaşık oturum takibi lazım ve yanlış pozitiflere tahammül çok daha düşük. Kurumsal projede ben olsam kural setini modüler tutarım: özelleştirilebilir eşikler, servis bazlı istisnalar. Audit trail olmadan kesinlikle ilerlemem. Aksi halde güvenlik aracı operasyonel dert üretir — bunun acısını yaşayanlar bilir. Erişilebilirlik Skoru Size Yalan Söylüyor: Neye Güvenmeli? yazımızda da bu konuya değinmiştik. Zephyr Events: Küçük Paket, Büyük Yarış Durumu Dersi yazımızda da bu konuya değinmiştik.
Çok konuştum, örnekle göstereyim.
Artılar ve eksiler kısa kısa
- Artılar:
- Düşük gecikme sağlar (bu kritik)
- Neden bloke edildiği anlaşılır
- Eksi taraflar:
- Kural bakım yükü getirir
💡 Bilgi: En iyi sonuç genelde hibrit yaklaşımda çıkıyor; hafif kurallar + oturum takibi + gerektiğinde insan incelemesi.
Nerede iyi çalışır, nerede tökezler?
Açık konuşayım. Bu yöntem her şeyi çözmüyor. Çok sofistike saldırılarda false positive ile false negative arasında yürürsünüz. Bazı meşru uzun diyaloglar risk skoru toplayabilir; bazı ustaca planlanmış enjeksiyonlar ise eşiği zorlamadan dolaşabilir. Yani kusursuzluk yok — olacak da değil.
Beni en çok düşündüren kısım şu oldu: görünmeyen iletişim kalıbını okumaya çalışırken normal kullanıcı davranışını cezalandırmak çok kolaylaşıyor (ben de ilk duyduğumda şaşırmıştım). Bu yüzden üretimde sınırlarınızı iyi çizmeniz lazım; mesela finansal işlemler için sert eşik, genel sohbet için daha yumuşak eşik koymak gibi. Böyle ayrımlar hayat kurtarıyor denebilir. Abartmıyorum.
Bence en doğru yaklaşım şu sırayı izlemek:
- Lekesiz anonimlik yerine kontrollü oturum kimliği kullanın
- Tek seferlik karar yerine kümülatif skor tutun
- Eşik aşımı olduğunda tam blok yerine bazen uyarı/yeniden deneme sunun
- Kural setini düzenli test edin — ciddi fark yaratıyor
- Sahte pozitifleri haftalık raporlayın
- Kullanıcı deneyimini hep göz önünde tutun
Sıkça Sorulan Sorular
Multi-turn prompt injection nedir?
Birkaç mesaj boyunca adım adım kurulan enjeksiyon saldırısıdır. Tek tek zararsız görünen istekler birleşince modele yanlış yönde talimat verebilir. En büyük sorun da tam burada başlıyor zaten…
Neden tek mesajlık filtreler yetmez?
İtiraf edeyim, Çünkü saldırının kritik kısmı çoğu zaman dağıtılmış halde gelir. Filtre yalnızca mevcut satırı görüyorsa geçmiş bağlamı kaçırır. Bu yüzden oturum bazlı analiz şart oluyor.” (ben de ilk duyduğumda şaşırmıştım)
Ml kullanmadan gerçekten koruma sağlanır mı?
özellikle hızlı yanıt gereken proxy senaryolarında gayet makul sonuç verir.
Ama neredeyse tamamen kuralsız olmaz;
kümülatif skor ve pattern analizi şarttır.”
Küçük ekipler için en pratik başlangıç ne olur?
Araya gireyim: Bence önce session tracking ekleyin,
sonra basit decay mekanizması koyun,
ardından birkaç bilinen desen tanımıyla başlayın.
İlk sürüm mükemmel olmak zorunda değil;
işleyen sürüm olması yeterli.
Kaynaklar ve İleri Okuma
Orijinal teknik yazı — Yohann Sidot’un paylaşımı
OpenAI Prompt Engineering Rehberi
OWASP Top 10 for LLM Applications
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
