OWASP LLM08: Vektör ve Gömme Zafiyetleri
Türkçe madde açıklaması, ATLAS eşlemesi ve 32 maddelik denetim listesi

LLM08 nedir? Kanonik tanım

OWASP LLM08 "Vektör ve Gömme Zafiyetleri" (Vector and Embedding Weaknesses), OWASP GenAI Top 10 for LLM Applications 2025 sürümünde yer alan ve geri getirmeli üretim (Retrieval-Augmented Generation, RAG) mimarilerinde metnin sayısal gömme vektörlerine dönüştürülmesi, saklanması ve geri çağrılması sırasında ortaya çıkan güvenlik zayıflıklarını tanımlayan risk maddesidir. Maddenin kapsamı OWASP'ın kendi metninde dört başlık altında toplanır: yetkisiz erişim ve zayıf erişim denetimi, çok-kiracılı ortamlarda bağlam sızıntısı, gömülü verinin zehirlenmesi ve gömme tersine çevirme yoluyla özgün metnin yeniden elde edilmesi.

Bu maddenin kritikliği, saldırı yüzeyinin isteme değil veriye kaymasından kaynaklanır. Klasik istem enjeksiyonu (LLM01) modele giden metni hedef alırken, LLM08 modelin bilgi tabanını oluşturan vektör deposunu hedef alır. Kurumsal bir asistan yanlış cevap verdiğinde sorun çoğu zaman modelde değil, geri çağrılan belge parçasında ya da o parçaya kimin erişebildiğinde saklıdır. OWASP LLM Top 10 listesinin tümünü Türkçe olarak OWASP LLM Top 10 Türkçe rehberimizde ele almıştık; bu yazı LLM08 maddesinin derinleşmiş alt-sayfasıdır.

Maddenin dört alt-riski

1. Yetkisiz erişim ve zayıf erişim denetimi

Vektör depoları çoğu zaman uygulama katmanının arkasında "iç servis" olarak kabul edildiği için erişim denetimi ihmal edilir. Oysa geri çağırma sorgusu, kaynak belgenin özgün erişim izinlerini (ACL) taşımıyorsa, bir kullanıcı yetkisi olmadığı belgelerin parçalarını modelin cevabı içinde alabilir. Buradaki temel hata, izin denetimini belge alma anına değil, yalnız arayüz giriş anına koymaktır.

2. Çok-kiracılı bağlam sızıntısı

Birden çok müşterinin (kiracının) aynı vektör indeksini paylaştığı SaaS mimarilerinde, kiracı kimliği her sorguya sıkı biçimde bağlanmazsa, bir kiracının sorgusu başka bir kiracının gömme kayıtlarıyla eşleşebilir. Benzerlik araması metadata filtresini "sonradan" uyguladığında ya da hiç uygulamadığında, komşu kiracının verisi cevaba sızar. Bu konuyu ayrıca RAG kiracı izolasyonu yazımızda derinlemesine işledik.

3. Gömülü verinin zehirlenmesi (data poisoning)

Saldırgan, dizine giren belgelere kötü niyetli içerik enjekte ederek geri çağırma sonuçlarını manipüle edebilir. Bu, gizli istem talimatları taşıyan bir belge (dolaylı enjeksiyonun vektör katmanındaki uzantısı) ya da benzerlik uzayında meşru sorguları kendine çeken "tuzak" parçalar olabilir. Kamuya açık ya da kullanıcı tarafından yüklenen kaynakları dizine alan boru hatları en yüksek riski taşır.

4. Gömme tersine çevirme (embedding inversion)

Gömme vektörleri sık sık "geri döndürülemez" sanılır; bu bir yanılgıdır. Akademik çalışmalar, yalnızca gömme vektörlerinden özgün metnin önemli ölçüde yeniden inşa edilebildiğini göstermiştir. Vektör deposu ya da gömme uç noktası sızdığında, saldırgan ham metin hiç görmese bile kişisel veriyi (PII) veya gizli içeriği geri elde edebilir. Bu, gömmelerin en az kaynak metin kadar hassas veri olarak sınıflandırılması gerektiği anlamına gelir.

MITRE ATLAS çapraz-referans tablosu

LLM08 alt-risklerini saldırgan davranışına oturtmak için MITRE ATLAS tekniklerini kullanmak, denetimi somutlaştırır. Aşağıdaki eşleme, kanonik olanları ayırırken zorlama eşlemeleri de açıkça işaretler.

Düzeltme notu: Veri zehirlemesi için doğru ATLAS tekniği AML.T0020'dir; sık yapılan bir hata bunu AML.T0018 ile eşlemektir; oysa AML.T0018 "Backdoor ML Model"dir; yani zehirlemenin bir alt sonucu olan arka kapı davranışını tanımlar, zehirleme eyleminin kendisini değil. Ayrıca AML.T0098 (yapay zekâ ajanı araç kimlik hasadı) bir vektör/gömme zafiyeti değildir; yalnızca RAG çıktısının bir araç çağrısını beslediği ajan zincirlerinde dolaylı bir bağ kurulabilir; kanonik LLM08 eşlemesi gibi sunulmamalıdır. ATLAS matrisinin bu maddeyle kesişimini araç ele geçirme yazımızla birlikte okumak isabetli olur.

32 maddelik denetim kontrol listesi

Aşağıdaki 32 soru dört alt-riske eşit dağıtılmıştır; her biri "evet/hayır" ile ölçülebilir olacak biçimde yazılmıştır. Bir RAG boru hattını denetlerken bu listeyi doğrudan bulgu tablosuna dönüştürebilirsiniz.

A. Yetkisiz erişim ve erişim denetimi (1-8)

1. Geri çağırma sorgusu, kaynak belgenin özgün erişim izinlerini (ACL) çalışma anında uyguluyor mu?
2. İzin denetimi yalnız arayüz girişinde değil, belge alma anında da yapılıyor mu?
3. Vektör deposuna doğrudan ağ erişimi yalnız uygulama servisiyle sınırlı mı?
4. Vektör deposu yönetim uç noktaları kimlik doğrulaması ardında mı?
5. Silinen/yetkisi kaldırılan kullanıcıların erişimi dizin düzeyinde de geri alınıyor mu?
6. Her geri çağırma isteği kimliği doğrulanmış bir kullanıcı bağlamına bağlı mı?
7. Servisler-arası çağrılar en az yetki (least privilege) ilkesiyle sınırlı mı?
8. Erişim reddi olayları kayıt altına alınıp izleniyor mu?

B. Çok-kiracılı bağlam sızıntısı (9-16)

9. Her gömme kaydı zorunlu bir kiracı kimliği metadata alanı taşıyor mu?
10. Kiracı filtresi benzerlik aramasından önce (arama-öncesi) uygulanıyor mu, sonra değil?
11. Kiracı kimliği sorgu bağlamından mı türetiliyor, istemci girdisinden mi (istemci girdisi ise reddedilmeli)?
12. Kiracı başına ayrı indeks/namespace kullanımı değerlendirildi mi?
13. Filtre atlanırsa sistem "boş sonuç" mu döndürüyor, yoksa filtresiz mi arıyor (güvenli varsayılan)?
14. Çapraz-kiracı sızıntısı için otomatik regresyon testi var mı?
15. Önbellek katmanı kiracı sınırına göre bölümlenmiş mi?
16. Yeni bir kiracı eklendiğinde izolasyon testi tetikleniyor mu?

C. Veri zehirleme (17-24)

17. Dizine giren belgeler kaynak güvenilirliğine göre sınıflandırılıyor mu?
18. Kullanıcı tarafından yüklenen içerik ile dâhili içerik ayrı güven düzeylerinde mi işleniyor?
19. Belge alımında gizli talimat/enjeksiyon taraması yapılıyor mu?
20. Her parçanın kaynağı (provenance) ve zaman damgası kaydediliyor mu?
21. Anormal biçimde çok sayıda sorguyla eşleşen "tuzak" parçalar için sapma izleme var mı?
22. Dizin güncellemeleri sürüm kontrollü ve geri alınabilir mi?
23. Zehirli bulunan bir belge dizinden ve önbellekten birlikte kaldırılabiliyor mu?
24. Otomatik alım boru hattında insan onayı gerektiren bir eşik var mı?

D. Gömme tersine çevirme ve gizlilik (25-32)

25. Gömme vektörleri kaynak metinle aynı gizlilik düzeyinde sınıflandırılıyor mu?
26. Vektör deposu bekleyen veri (at-rest) şifrelemesiyle korunuyor mu?
27. Gömme uç noktasına erişim hız sınırlaması ve kimlik doğrulamasıyla korunuyor mu?
28. Kişisel veri, gömme oluşturulmadan önce maskeleniyor/anonimleştiriliyor mu?
29. Gömme vektörlerinin toplu dışa aktarımı denetleniyor ve alarma bağlanıyor mu?
30. Ham vektör döndüren hata ayıklama/uç noktaları üretimde kapalı mı?
31. Vektörler ve kaynak metin arasındaki eşleme (id haritası) ayrı erişim denetimine tabi mi?
32. Bir sızıntı senaryosunda gömmelerin PII içerdiği varsayımıyla olay müdahale planı hazır mı?

Savunma mühendisliği prensipleri

Denetim soruları boşlukları gösterir; kapatma işi ise birkaç tekrar eden prensibe dayanır:

• İzni veriye taşı: Erişim denetimi arayüzde değil, geri çağırma anında ve parça düzeyinde uygulanmalı. Metadata filtresi arama-öncesi çalışmalı; güvenli varsayılan "filtre yoksa sonuç yok" olmalı.
• Gömmeyi hassas veri say: Tersine çevrilebilir olduğu için gömme vektörleri kaynak metinle aynı sınıflandırma, şifreleme ve erişim kaydı disiplinine tabi tutulmalı; PII gömme öncesinde maskelenmeli. Bu prensibi KVKK ve PII maskeleme yazımızla birlikte uygulamak yerinde olur.
• Kaynak izini tut: Her parçanın kökeni ve güven düzeyi kayıtlı olmalı; zehirlenmiş içerik tespit edildiğinde dizinden ve önbellekten geri alınabilmeli.
• Çalışma zamanında denetle: Geri çağırma ile modele giriş arasına bir denetim katmanı koymak, çok-kiracılı sızıntı ve zehirli parça enjeksiyonunu yakalamada en pratik kaldıraçtır.

Bu çalışma-zamanı denetim katmanı, AltaySec'in LLM güvenlik duvarı (Guardian) yaklaşımının merkezindedir: geri çağrılan bağlamı ve modele giden metni kiracı sınırı, enjeksiyon kalıbı ve veri sınıfı açısından süzer. Vektör deposu izlemenin operasyonel tarafını ise RAG güvenlik izleme yazımızda ele aldık.

Türkçe bağlam ve AltaySec ölçümü

LLM08 alt-risklerinin çoğu dilden bağımsızdır; ancak gömme kalitesi ve enjeksiyon tespiti Türkçe içerikte farklı davranır. AltaySec'in kendi ölçümü olan AltayDuel veri kümesindeki Türkçe istem enjeksiyonu örnekleri, dolaylı enjeksiyonun belge katmanına taşındığında İngilizce ağırlıklı sınıflandırıcıların bir bölümünü atlattığını göstermektedir; bu bulgu dış-genel bir gerçek değil, AltaySec'in kendi kıyaslama verisinden çıkan bir gözlemdir. Türkçe morfolojinin gömme uzayında yarattığı sapmaları ayrıca Türkçe morfolojik bypass yazımızda inceledik.

Bu maddeyi düzenleyici çerçeveyle birleştirmek isteyen ekipler için, geri çağırma ve gömme boru hatlarının teknik uyum gereksinimlerini EU AI Act uyum rehberimizdeki teknik kontrol listesiyle çapraz okumak, denetim kapsamını hem güvenlik hem uyum tarafında tamamlar. Bir denetim ya da RAG mimarisi incelemesi için bizimle iletişime geçebilirsiniz.

Kaynaklar

• OWASP Top 10 for LLM Applications 2025 — LLM08: Vector and Embedding Weaknesses
• MITRE ATLAS — AML.T0024: Exfiltration via AI/ML Inference API
• MITRE ATLAS — AML.T0020: Poison Training Data
• MITRE ATLAS — AML.T0018: Backdoor ML Model
• MITRE ATLAS — AML.T0098: AI Agent Tool Credential Harvesting
• Morris et al., "Text Embeddings Reveal (Almost) As Much As Text" (arXiv:2310.06816)

İlgili Yazılar

• OWASP LLM Top 10 Türkçe Rehberi
• RAG Kiracı İzolasyonu ve Vektör DB
• RAG Güvenlik İzleme: Vektör Veritabanı
• RAG Güvenliği Nedir?