LLM02 Hassas Bilgi İfşası Nedir?
OWASP LLM Top 10 · KVKK Madde 9 · Türkçe mühendis rehberi

LLM02 Hassas Bilgi İfşası Nedir?

LLM02 Hassas Bilgi İfşası (Sensitive Information Disclosure), OWASP'ın 2025 yılı Büyük Dil Modeli Uygulamaları için İlk 10 Risk listesindeki ikinci maddedir. Tanımı basit ama kapsamı geniştir: bir dil modelinin, açığa çıkmaması gereken kişisel verileri, kimlik doğrulama sırlarını, iş sırlarını, sistem yapılandırmasını veya eğitim verisinden ezberlediği bilgiyi kullanıcıya, loglara ya da bağlı bir sisteme sızdırmasıdır. Bilgi, saldırganın onu istediği için değil, modelin onu tutamadığı için dışarı çıkar.

Bu riski diğerlerinden ayıran şey, ihlalin çoğu zaman "başarılı bir saldırı" gibi görünmemesidir. Bir kullanıcı meşru bir soru sorar, model yardımsever olmaya çalışır ve yanıtın içine başka bir kullanıcının telefon numarasını, bir API anahtarını veya sistem talimatının bir parçasını yerleştirir. Uygulama çökmez, hata log'u düşmez; veri sessizce sızar. İşte bu sessizlik, LLM02'yi tespiti en zor risklerden biri yapar.

İfşa Hangi Yollarla Gerçekleşir?

Hassas bilgi ifşası tek bir açıktan değil, bir yüzeyler kümesinden doğar. Mühendislik açısından beş ana kanal öne çıkar:

• Eğitim verisi ezberleme: Model, eğitim setinde yer alan nadir dizileri (bir e-posta imzası, bir kimlik numarası, bir kredi kartı deseni) ezberler ve doğru istemle bunu yeniden üretir.
• Bağlam penceresi sızıntısı: Aynı oturumda veya bitişik isteklerde sisteme verilen gizli talimatlar, örnekler veya kullanıcı verisi, sonraki yanıtlara taşar.
• Erişimle zenginleştirilmiş üretim (RAG) sızıntısı: Vektör veritabanından çekilen belgeler, yetki sınırı doğrulanmadan bağlama enjekte edilir; bir kiracının verisi başka bir kiracının yanıtında görünür.
• Günlük ve telemetri: İstem ve yanıtlar, maskesiz biçimde log sistemlerine, izleme araçlarına veya üçüncü taraf sağlayıcılara yazılır.
• Çıktı formatlama hataları: Model, hata ayıklama modunda sistem talimatını, ortam değişkenlerini veya iç kimlikleri kullanıcıya yansıtır.

Bu kanalların çoğu, model çıktısına bakan tek bir güvenlik kontrolüyle kapatılamaz; girişten günlüğe kadar her katmanda ayrı bir denetim ister. RAG tarafındaki izolasyon boşluğunu ayrıntılı ele aldığımız RAG kiracı izolasyonu yazısı bu kanallardan birini derinleştirir.

AltayDuel Verisinden Gerçek Türkçe Sızıntı Anları

Soyut tanımlar önemlidir, ama sızıntının Türkçe'de nasıl göründüğünü görmek daha öğreticidir. AltaySec'in kendi kırmızı takım arenası AltayDuel, saldırı ve savunma ajanlarının karşılıklı düello yaptığı bir ortamdır; bu arenadan çıkan 2594 açık düello transkripti (AltaySec iç veri seti) Türkçe'ye özgü ifşa desenlerini belgeleyen bir kaynaktır.

Transkriptlerde tekrar eden üç ifşa kalıbı öne çıkıyor:

Bu kalıpların ortak yanı, hiçbirinin klasik anlamda "hackleme" gibi görünmemesidir. Hepsi nazik, meşru ve yardım isteyen cümlelerdir. Bir OTP kodunun savunucu ajan çöktüğünde nasıl sızdığını adım adım incelediğimiz OTP sızıntısı düello analizinde bu mekanizmayı transkript düzeyinde açtık. Buradaki kritik gözlem şudur: aynı saldırı İngilizce'de reddedilirken Türkçe'de başarıya ulaşabiliyor, çünkü çıktı filtreleri çoğunlukla İngilizce desenlere göre ayarlanmış oluyor.

KVKK Madde 9 Eşlemesi: Bulut LLM = Yurt Dışına Aktarım

Türkiye'de LLM02'yi salt teknik bir risk olarak ele almak eksik kalır. 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 9. maddesi, kişisel verilerin yurt dışına aktarılmasını düzenler. Mühendislik perspektifinden bakıldığında buradaki eşleme nettir: sunucuları yurt dışında konumlanmış bir bulut LLM sağlayıcısına (çoğu büyük ticari model) kişisel veri içeren bir istem gönderdiğinizde, çoğu senaryoda bir yurt dışına aktarım işlemi gerçekleştirmiş olursunuz.

Bu, hukuk bürolarının bolca yorumladığı bir alan; ancak yorumların çoğu sözleşme ve rıza katmanında kalıyor, mühendisin elindeki isteme kadar inmiyor. Oysa sızıntının fiziksel olarak gerçekleştiği yer tam da o istemdir. LLM02 ile Madde 9'u birlikte okuduğunuzda pratik sonuç şudur:

• Bir kullanıcının chatbot'a girdiği TCKN veya telefon, giriş anında maskelenmezse hem LLM02 (ifşa) hem de olası bir Madde 9 aktarımı doğar.
• Aktarımın hukuki dayanağı (açık rıza, yeterlilik kararı veya uygun güvence) yoksa, teknik ifşa aynı anda bir uyum ihlaline dönüşür.
• Veriyi girişte silmek, aktarımı en baştan engellediği için hem en güçlü teknik hem de en güçlü hukuki savunmadır.

Bu ikili okumayı, kurumsal soru-cevap formatında ele aldığımız yapay zeka ve KVKK kurumsal sorular ile KVKK ve LLM güvenliği yazıları tamamlıyor. Madde 9'u mühendis perspektifinden LLM02'ye bağlayan Türkçe teknik kaynak henüz seyrek; bu boşluğu doldurmayı hedefleyen bir çerçeve sunuyoruz.

Türkçe'ye Özgü Maskeleme Neden Farklıdır?

Hazır PII maskeleme araçlarının çoğu İngilizce metin için tasarlanmıştır ve Türkçe'ye getirildiğinde sessizce yanılır. Türkçe'ye özgü birkaç zorluk şunlar:

• Biçimbirim eklentileri: "Ahmet'in", "Ayşe'yle", "05xx numarasına" gibi ekli biçimler, sabit desenle yazılmış maskeleyicilerin varlığı isim veya numara olarak tanımasını zorlaştırır.
• Türkçe kimlik desenleri: TCKN, IBAN'ın TR ön eki, plaka ve kurum sicil formatları, İngilizce merkezli araçlarda ya hiç yoktur ya da eksiktir.
• Büyük-küçük harf ve karakter tuzakları: "i/İ" ve "ı/I" dönüşümleri, desen eşleştirmeyi kaydırarak maskelemenin atlanmasına yol açabilir.

AltaySec'in bu boşluğu kapatmak için geliştirdiği turkish-pii-redactor (AltaySec iç aracı), Türkçe'ye özgü ekli biçimleri ve yerel kimlik desenlerini hedefleyen maskeleme kurallarıyla, istemi modele göndermeden önce hassas alanları etiketleyip yer tutucuyla değiştirir. Aynı morfolojik kaçış yüzeyini saldırı tarafından incelediğimiz Türkçe morfolojik LLM bypass yazısı, neden sabit regex'in yetmediğini gösteriyor. Uygulama tarafında maskeleme prensiplerini KVKK ve PII maskeleme yazısında adımlıyoruz.

Savunma: Tek Kontrol Değil, Katmanlar

LLM02'ye karşı tek bir sihirli filtre yoktur; savunma, veri yaşam döngüsünün her aşamasında ayrı bir kontrol ister. Pratik bir katman haritası:

1. Girişte veri en aza indirme ve maskeleme: Kullanıcı istemi modele ulaşmadan önce PII maskelenir. Sızmayan veri, savunması en ucuz veridir.
2. Bağlam izolasyonu: RAG belgeleri ve sistem talimatları, yetki sınırı doğrulandıktan sonra bağlama girer; kiracılar arası sızıntı için ayrı testler yürütülür.
3. Çıkışta filtreleme: Model yanıtı kullanıcıya ulaşmadan, kimlik desenleri ve sistem-sızıntısı imzaları için taranır. Bu tarama İngilizce'nin yanında Türkçe desenleri de kapsamalıdır.
4. Günlük hijyeni: İstem ve yanıtlar log'a maskesiz yazılmaz; izleme, gizliliği koruyacak biçimde tasarlanır.
5. Sürekli kırmızı takım: AltayDuel gibi düello temelli testlerle, ifşa desenleri düzenli olarak yeniden denenir; savunma bir kez kurulup unutulmaz.

Bu katmanların çalışma zamanında tek bir denetim noktasında toplanması, çıkış filtreleme ve maskelemeyi bir aracıya devretmeyi kolaylaştırır. AltaySec'in LLM güvenlik duvarı (Guardian) yaklaşımı, giriş maskeleme ile çıkış filtrelemeyi aynı hatta yerleştirerek LLM02'yi uygulama kodundan bağımsız bir katmanda ele almayı amaçlar. Sistem talimatının çıktıya yansıması, bu riskin komşusu olan ayrı bir maddedir; onu sistem promptu sızdırma yazısında ele alıyoruz.

Kısa Kontrol Listesi

Bir LLM uygulamasını LLM02 açısından denetlerken sorulacak asgari sorular:

• Kullanıcı istemi modele gitmeden önce PII maskeleniyor mu? Maskeleme Türkçe ekli biçimleri ve yerel kimlik desenlerini kapsıyor mu?
• Kullanılan bulut model yurt dışında mı barınıyor? Öyleyse KVKK Madde 9 için hukuki dayanak belgelenmiş mi?
• RAG bağlamı, yetki sınırı doğrulanmadan belge çekiyor olabilir mi?
• İstem ve yanıtlar log'lara maskesiz düşüyor mu?
• Çıkış filtresi, Türkçe sızıntı desenlerini de tarıyor mu, yoksa yalnızca İngilizce'ye mi ayarlı?
• İfşa senaryoları düzenli kırmızı takım testine tabi mi?

Bu altı sorunun tamamına "evet" diyemiyorsanız, uygulamanızda açık bir LLM02 yüzeyi var demektir. OWASP listesinin tamamını Türkçe olarak gözden geçirmek için OWASP LLM Top 10 Türkçe rehberimizle başlayabilir, kurumsal bir değerlendirme için AltaySec ekibiyle iletişime geçebilirsiniz.

Kaynaklar

• OWASP Top 10 for LLM Applications 2025 — LLM02: Sensitive Information Disclosure
• 6698 sayılı Kişisel Verilerin Korunması Kanunu (Madde 9 — Yurt dışına aktarım)
• MITRE ATLAS — Adversarial Threat Landscape for AI Systems
• NIST AI Risk Management Framework (AI RMF 1.0)
• AltaySec Ekosistemi — açık kaynak araçlar ve veri setleri

İlgili Yazılar

• OWASP LLM Top 10 Türkçe Rehberi
• KVKK ve LLM'lerde PII Maskeleme
• Sistem Promptu Sızdırma (LLM07)
• OTP Sızıntısı: Savunucu Ajanın Yıkılması