RAG güvenliği, yapay zekâ uygulamasının harici belgelerden bilgi getirirken kullanıcı yetkisini, veri gizliliğini ve işlem sınırlarını korumasıdır. Kurumsal chatbotlar artık yalnızca sık sorulan soruları yanıtlamıyor. Bir yapay zekâ asistanı şirket belgelerini arayabiliyor, müşteri siparişlerini sorgulayabiliyor, CRM kayıtlarını özetleyebiliyor ve bazı durumlarda dış sistemlerde işlem başlatabiliyor. Tam da bu nedenle “doğru cevap üretmesi” tek başına yeterli bir güvenlik hedefi değildir. Sistemin hangi bilgiyi kimin adına okuyabileceği, hangi işleme yetkili olduğu ve güvenilmeyen bir belgedeki talimatı nasıl ele aldığı da tasarımın merkezinde olmalıdır.
OWASP’ın LLM uygulamaları için güvenlik çalışmaları, prompt injection ve hassas bilgi ifşasını temel riskler arasında ele alır. OWASP ayrıca RAG ve fine-tuning tekniklerinin modelin doğruluğunu artırabilse de prompt injection sorununu kendiliğinden ortadan kaldırmadığını belirtir. Kaynak: OWASP LLM01 Prompt Injection.
Bu rehberin kapsamı
- Prompt injection ve dolaylı talimat saldırılarının mantığı
- RAG belge alma, indeksleme, retrieval ve yanıt zincirindeki güven sınırları
- Multi-tenant veri ayrımı, en az yetki ve kullanıcı bağlamı
- AI agent ve araç çağrılarında onay, denetim ve durdurma mekanizması
- Canlıya çıkmadan önce uygulanabilecek test matrisi
- 30/60/90 günlük kurumsal AI güvenlik yol haritası
Prompt injection nedir?
Bir dil modelinin, işlemesi gereken veriyi yetkili bir talimat sanarak davranışını değiştirmesine yol açan girişimler prompt injection olarak adlandırılır. Saldırgan doğrudan sohbet kutusuna yazabilir; daha tehlikeli senaryolarda ise modelin okuyacağı web sayfasına, PDF belgesine, e-postaya veya veri tabanı kaydına gizlenmiş bir yönlendirme bırakabilir. Bu ikinci durum dolaylı prompt injection olarak bilinir.
Örnek düşünelim: Satın alma asistanı, bir tedarikçi teklifindeki fiyatları özetlemek için belgeyi okuyor. Belgenin içeriği, normal iş verisi gibi görünse de asistanı kullanıcının istemediği başka bir kaynağa yönlendirmeyi amaçlayabilir. Buradaki temel güvenlik hatası, dış kaynak metnini uygulamanın kendi güvenilir talimatlarıyla aynı seviyede ele almaktır. Bir sistem mesajına “Bu tür saldırıları yok say” yazmak yararlıdır ama tek başına güvenlik kontrolü değildir.
RAG mimarisinde görünmeyen üç veri sınırı
Retrieval-Augmented Generation (RAG), model yanıtını kurumun belgeleri gibi seçilmiş kaynaklarla destekler. Ancak güvenlik üç ayrı aşamada kurulmalıdır:
1. Belge alma ve indeksleme: Dosyanın kimden geldiği, hassasiyet sınıfı, güncelliği ve saklama süresi bilinmelidir. Taranan belgelerde gizli bilgiler, kötü amaçlı bağlantılar veya yanıltıcı talimatlar bulunabilir.
2. Retrieval ve yetkilendirme: Arama sonucu, yalnızca arama açısından benzer olduğu için kullanıcıya gönderilmemelidir. Kullanıcının ilgili belgeyi okuma yetkisi, vektör arama sonucunu uygulamaya taşımadan önce veya doğrulanabilir bir erişim filtresiyle uygulanmalıdır. Çok kiracılı (multi-tenant) bir sistemde müşterilerin veri alanları kesin biçimde ayrılmalıdır.
3. Yanıt ve araç kullanımı: Modelin ürettiği yanıt, hassas veri politikalarına tabi olmalıdır. İşlem yapan araçlar ise yalnızca modelin önerisiyle sınırsız yetkiye sahip olmamalıdır. Özellikle e-posta gönderme, ödeme, müşteri kaydı değiştirme ve dosya silme gibi işlemler ayrı yetkilendirme ve uygun durumlarda insan onayı gerektirir.
En önemli altı güvenlik riski
- Dolaylı prompt injection: Modelin okuduğu belgeler veya web içerikleri üzerinden yönlendirilmesi.
- Hassas veri ifşası: Kişisel veri, ticari sır, sistem anahtarı veya başka bir müşterinin belgesinin yetkisiz yanıtta görünmesi.
- Aşırı ajan yetkisi: Sadece bilgi vermesi gereken asistanın değişiklik yapabilen API’lere geniş erişim sahibi olması.
- Tenant izolasyonu hatası: Bir müşterinin arama sonuçlarının başka müşteriye karışması.
- Güvenilmeyen çıktı kullanımı: Model çıktısının kontrol edilmeden SQL, HTML, shell veya iş akışı parametresi olarak değerlendirilmesi.
- Gözlemlenebilirlik eksikliği: Hangi belgeye erişildiği, hangi araç çağrısının yapıldığı ve işlemi kimin onayladığının incelenememesi.
OWASP’ın 2025 LLM Top 10 çalışması hassas bilgi ifşasını da ayrı bir risk olarak sınıflandırır. Özellikle kişisel veriler, finansal bilgiler, işletme sırları ve erişim anahtarlarının uygulama bağlamında korunması gerekir. Kaynak: OWASP LLM02.
Güvenli kurumsal AI mimarisi nasıl kurulur?
İyi bir tasarım, modelin önünde ve arkasında çalışan deterministik güvenlik kontrolleri içerir. Kimlik yönetimi uygulama katmanında yapılır; belge arama çağrısı kullanıcı/rol/tenant bağlamını taşır; erişim yetkisi sunucuda doğrulanır. Model, gerekli olmayan kimlik bilgilerini prompt içinde görmez. API araçları küçük ve belirli izinlere sahiptir: Örneğin bir destek asistanının ticket.read yetkisi, ticket.delete yetkisini gerektirmez.
Araç çağrıları yapılandırılmış şemalarla doğrulanmalı, beklenmeyen parametreler reddedilmeli, hız ve maliyet sınırları tanımlanmalıdır. Yüksek etkili işlemlerde insan onayı, yalnızca sohbetteki bir “Evet” kelimesi yerine kullanıcıya gösterilen somut işlem özeti üzerinden alınmalıdır. Bunlara loglama, veri maskeleme, anahtar rotasyonu ve güvenli hata davranışı eklenmelidir.
Prompt filtreleri, sınıflandırıcılar ve model tabanlı güvenlik kontrolleri faydalı savunma katmanları olabilir. Fakat hiçbiri erişim kontrolünün, ağ sınırlarının veya araç yetkilerinin yerine geçmemelidir. Güvenliğin son savunması modelin doğru karar vereceği varsayımı üzerine kurulamaz.
Canlıya çıkmadan önce uygulanacak sekiz test
- Farklı kullanıcı rolleriyle aynı belge sorgusunu çalıştırın; yetkisiz belge hiçbir aşamada görünmesin.
- İki ayrı müşteri/tenant için benzer dosyalar oluşturun; sonuçların karışmadığını doğrulayın.
- Güvenilmeyen belgelerin içerdiği talimat benzeri metinler karşısında modelin araç yetkilerinin değişmediğini test edin.
- Destek asistanının yalnızca okunabilir, sınırlandırılmış araçları çağırabildiğini kanıtlayın.
- Gizli anahtar, kimlik bilgisi ve kişisel veri için hem giriş hem çıkış politikalarını sınayın.
- Hatalı API çıktısı ve zaman aşımında sistemin yetki genişletmeden güvenli şekilde durduğunu doğrulayın.
- Anormal token kullanımı, büyük veri dışa aktarımı ve beklenmeyen araç çağrılarına alarmlar tanımlayın.
- Bir olayın hangi kullanıcı, belge, model sürümü ve araç çağrısıyla ilişkili olduğunu loglardan takip edebildiğinizi doğrulayın; loglarda gizli veriyi gereksiz saklamayın.
Bu testleri yalnızca üretimden önce bir kez değil, yeni belge kaynağı, araç veya model sürümü eklendiğinde de tekrar edin. Özellikle rol ve tenant sınırlarının otomatik regresyon testleriyle izlenmesi önemlidir.
İş değeri ile güvenliği birlikte tasarlamak
Her AI sistemi kritik işlem yapmaz. Yalnızca kamuya açık SSS belgelerini yanıtlayan bir bot ile finansal kayıt güncelleyen bir ajan aynı risk seviyesinde değildir. Daha düşük riskli bir pilotta önce salt okunur entegrasyonlar, kaynak gösterimi ve sınırlı kullanıcı gruplarıyla başlayıp yetkileri ölçülü olarak genişletebilirsiniz. Bu yaklaşım AI projesinin iş değerini test ederken saldırı yüzeyini kontrol altında tutar.
RAG güvenliği için kurumsal mimari: Beş bağımsız kontrol noktası
Tek bir “güvenli prompt” yerine uygulama katmanında doğrulanan birden fazla sınır tasarlayın. Bu sınırların her biri farklı bir hatayı önlemeye yöneliktir:
| Katman | Güvenlik kontrolü | Doğrulanacak soru |
|---|---|---|
| Kullanıcı/kimlik | SSO, oturum yönetimi, MFA, role/tenant eşleme | Bu isteği kim yaptı ve hangi kuruma bağlı? |
| Belge alma/indeks | Kaynak doğrulama, sınıflandırma, kötü amaçlı dosya analizi | Belge güvenilir mi, ne kadar süre saklanacak? |
| Retrieval | Belge düzeyinde ACL, tenant filtresi, yetki kontrolü | Kullanıcı bu parçayı gerçekten görebilir mi? |
| Model/çıktı | Hassas veri politikası, kaynak atfı, uygun çıktı doğrulama | Yanıt izinli ve dayanaklı mı? |
| Tool/agent | Dar yetkili servis hesapları, onay, oran limiti, denetim | Modelin önerdiği işlemi uygulama gerçekten yapabilir mi? |
1. Vektör veritabanında tenant izolasyonu
Çok kiracılı bir SaaS ürününde bütün müşterilerin embedding’lerini aynı fiziksel altyapıda tutmak mümkün olabilir; fakat bu mantıksal ayrımın doğrulandığı anlamına gelmez. Retrieval sorgusu her zaman sunucuda doğrulanan tenant ve kullanıcı yetkisine bağlı olmalıdır. Tenant kimliği yalnızca istemciden gelen serbest bir parametre olmamalıdır. Belge yükleme, indeks yeniden oluşturma, silme, yedekleme ve arama yolları aynı yetki modelini izlemelidir.
Örnek kabul kriteri: A müşterisinin yüklediği “Fiyatlandırma.pdf” belgesi, B müşterisinin benzer kelimelerle yaptığı aramada hiçbir koşulda alıntı, özet veya kaynak URL olarak görünmemelidir. Bu kontrolü yalnızca uygulamanın ana sohbet kutusunda değil, admin API ve toplu arama işlerinde de test edin.
2. Güvenilmeyen içerik ile sistem talimatını ayırın
Kurumsal bilgi tabanına eklenen bir PDF, e-posta veya internet sayfası güvenilir bir sistem talimatı değildir. Belgedeki “şu işlemi yap” ifadesi, kullanıcının o belgeyi okuma isteğinden farklıdır. İçeriği veri olarak işaretlemek, modelin okuyabileceği bağlamı ve araç yetkilerini sınırlamak önemlidir. Ancak bu ayrım prompt düzeyinde yüzde yüz garanti sağlamaz; yetki denetimi modelin dışındaki uygulama kodunda bulunmalıdır.
Risk azaltma örnekleri: Belge kaynağını ve erişim sınıfını metadata ile taşımak; modelin yetkili araçlarını görev bazında sınırlamak; beklenmeyen dış veri gönderimi için ağ çıkış politikasını uygulama seviyesinde zorunlu kılmak; saldırgan denemelerinin etkisini ayrı test ortamında ölçmek.
3. API araçları için dar yetki ve açık işlem onayı
Bir destek asistanının sipariş durumunu okuma yetkisi olması, sipariş iptal etme hakkını gerektirmez. Okuma, oluşturma, düzenleme ve silme operasyonlarını ayrı servis yetkileriyle sınırlayın. İşlem yapabilen ajanlara mümkünse görev süresiyle sınırlı kimlik bilgileri verin. Ödeme, müşteri verisi dışa aktarımı veya toplu kayıt değişikliği gibi etkisi büyük işlemler için kullanıcının işlem özeti üzerinden verdiği açık onayı kontrol edin.
Modelin ürettiği JSON şemaya uyuyor diye işlem güvenli kabul edilmemelidir: iş kuralları, rol yetkisi, tutar sınırı, tenant ayrımı ve tekrar edilen isteklerin davranışı sunucuda doğrulanır. Tool sonuçlarına tekrar modele dönülmeden önce gereksiz hassas veri temizliği ve kapsam sınırlaması yapılabilir.
4. Modelin yanlış yanıtını güvenlik olayından ayırın
Halüsinasyon, eksik kaynak gösterme ve yanlış müşteri verisi üretme güvenilirlik sorunudur; bazı durumlarda güvenlik veya gizlilik olayına dönüşebilir. Bu ayrımı uygulama kayıtlarında yapın. Örneğin “model yanlış prosedürü özetledi” kalite sorunu olabilir; “başka tenant’a ait gizli belgeyi yanıtladı” erişim kontrolü ihlalidir. İkinci olayda yalnızca prompt’u değiştirmek yeterli olmayabilir.
İş açısından doğru ölçümler: Yetkisiz belgenin retrieval sonucuna girme oranı, hassas veri ifşası test sonucu, kaynak atfı doğruluğu, istenmeyen araç çağrısı engelleme oranı, olay tespit süresi ve insan onayının doğru uygulanma oranı.
5. Denetlenebilirlik ve durdurma mekanizması
Bir agent beklenmedik sayıda işlem yaptığında yalnızca sohbet ekranını kapatmak yeterli olmayabilir. Araç erişim belirteçlerini iptal edebilmek, ağ çıkışını sınırlandırabilmek, işlem kuyruğunu durdurabilmek ve hangi kullanıcı isteğinin hangi araç çağrısına yol açtığını korelasyon kimliğiyle izleyebilmek gerekir.
OWASP’ın Agentic Applications Top 10 çalışması, araçların kötüye kullanılması, kimlik/yetki istismarı, bellek zehirlenmesi ve ajanlar arası güven sorunları gibi riskleri ayrıca vurgular. Bu yaklaşım, basit chatbot güvenliği ile gerçek işlem yapabilen ajan güvenliğinin aynı şey olmadığını gösterir. Kaynak: OWASP Agentic Top 10.
RAG sistemi için senaryo temelli test matrisi
| Test senaryosu | Beklenen güvenli davranış | Gözlenecek kanıt |
|---|---|---|
| A kullanıcısı B tenant belgesini sorar | Yetkisiz içerik retrieval/yanıtta görünmez | Yetki kontrolü ve sonuç logu |
| Belge içinde talimat benzeri satırlar var | İçerik veri olarak ele alınır; araç yetkisi değişmez | Model sonucu ve tool çağrı kaydı |
| İşlem aracı yetkisiz kullanıcıdan çağrılır | Sunucu ısrarla reddeder | Yetkilendirme sonucu |
| Yanıtta gizli kimlik bilgisi bulunabilir | Veri politikası devreye girer, olay kaydedilir | Test ve redaksiyon kaydı |
| Model aşırı sayıda araç çağırır | Kota/oran sınırı uygulanır; gerekirse durdurulur | Limit ve alarm kaydı |
| Index silinen belgeyi hâlâ döndürür | Silme/retention politikası uygulanır | Silme ve yeniden indeks testi |
| Ajan kısmi API hatası alır | Yetki genişletmeden güvenli şekilde durur | Hata ve rollback izi |
Bu testleri saldırı üretmek için değil, kendi yetkili ortamınızda güven sınırını doğrulamak için tasarlayın. Her testin sürüm, model, indeks, kullanıcı rolü ve araç konfigürasyonuyla birlikte kayıt altına alınması regresyon analizini kolaylaştırır.
30/60/90 günlük kurumsal AI güvenlik planı
İlk 30 gün — Envanter ve erişim: Hangi asistanın hangi veriyi ve aracı kullanabildiğini haritalayın. Hassas bilgi sınıflarını tanımlayın; sunucu tarafı kimlik/tenant filtrelerini doğrulayın. Kritik API’lere ayrılmış servis hesapları oluşturun.
31–60. gün — Test ve gözlemleme: Prompt injection, yetkisiz retrieval ve araç kötüye kullanımı için güvenli test kümesi hazırlayın. Hassas veri loglarını maskeleyin, araç çağrıları için korelasyon kimliği kullanın, maliyet ve oran sınırı alarmlarını deneyin.
61–90. gün — Operasyonel güvence: İleri düzey ajan işlemlerine insan onayı ekleyin, acil durdurma prosedürünü tatbik edin, kullanıcı/tenant ayrımı için otomatik regresyon testini dağıtım hattına alın. Bulguları risk ve iş etkisine göre sıraya koyun.
Bu plan bir uyumluluk sertifikası değil, yönetilebilir bir başlangıç temposudur. Finansal işlem yapan ajanlar veya yüksek hassasiyetli veriler için daha kapsamlı güvenlik değerlendirmesi gerekebilir.
RAG güvenliğinde en sık yanlış varsayımlar
- “Model bizim şirket verimizle eğitildi, dolayısıyla güvenilir.” Eğitim veya fine-tuning, kullanıcı erişim kontrollerinin yerini almaz.
- “Vektör veritabanı kendi içinde güvenli, yetkilendirme gerekmez.” Uygulama düzeyi belge ve tenant politikaları yine gerekir.
- “Sistem prompt’u gizliyse saldırgan talimatları geçemez.” Güvenilmeyen içerik yine model davranışını etkileyebilir.
- “Ajan sadece API çağırıyor, risk sınırlı.” API’nin yetkisi genişse yapılan değişikliğin etkisi büyük olabilir.
- “Yalnızca yanıtları loglamak yeterli.” Kaynak belge kimliği ve araç kararlarının denetlenebilirliği de önemlidir.
Sık sorulan sorular
RAG kullanmak prompt injection’ı engeller mi?
Hayır. RAG, harici bilgi getirir; dolayısıyla güvenilmeyen içeriğin modele ulaşabileceği yeni bir yüzey de oluşturabilir. Yetkilendirme, içerik sınırları ve araç kontrolü gerekir.
Sistem prompt’unu gizlemek yeterli mi?
Hayır. Sistem prompt’u içinde parola veya API anahtarı tutmayın. Gizleme, bağımsız kimlik ve erişim kontrollerinin yerine geçemez.
Her AI aracına insan onayı mı gerekli?
Hayır. Risk düzeyine göre karar verilir. Salt okunur, düşük etkili işlemler otomatikleştirilebilir; geri alınması zor, finansal veya hassas veri değiştiren işlemlerde güçlü onay mekanizması gerekir.
RAG sisteminde veri sızıntısı en çok nerede olur?
Tek bir noktada olmak zorunda değildir. Yetkisiz retrieval sonucu, yanlış tenant filtresi, geniş araç yetkileri, hassas veri içeren loglar veya dış API’ye gereksiz veri gönderimi sızıntı yüzeyleri oluşturabilir.
Prompt injection filtreleri yüzde yüz koruma sağlar mı?
Hayır. Giriş/çıkış filtreleri savunmaya yardımcı olabilir; ancak kesin bir engel değildir. Kritik erişim ve işlem kuralları deterministik uygulama kontrolleriyle korunmalıdır.
Chatbot’tan AI agent’a geçerken ilk ne değişmeli?
Salt okunur cevap üreten sistemden işlem yapan sisteme geçildiğinde araç yetkileri, onay akışı, hata telafisi, denetim logu ve acil durdurma kapasitesi yeniden tasarlanmalıdır.
Sonuç: Güvenilir kurumsal AI, yalnızca iyi bir model ve hızlı bir vektör veritabanından oluşmaz. Güven sınırlarını ve yetkileri tasarlayan, doğrulanabilir testlerle sürdüren bir mimari gerektirir. Genel API ve uygulama riskleri için OWASP Top 10 2025 rehberimize göz atabilirsiniz. Ancyra’nın LLM & RAG, özel AI geliştirme ve siber güvenlik çözüm alanlarını birlikte değerlendirebilirsiniz.
Kaynaklar: OWASP LLM01 · OWASP LLM02 · OWASP GenAI güvenlik sözlüğü · OWASP Agentic Top 10