On-Premises RAG için Prompt Injection Savunmaları: Retrieval-Augmented Generation Sertleştirme

RAG güven modelini neden değiştirir

Retrieval-augmented generation düzenli bir mimari gibi görünür: modeli özel altyapıda tutun, yanıtları onaylı koleksiyonlara dayandırın, hassas istemleri dış servislere göndermeyin. Pratikte çekilen metin istemin parçası haline gelir. Saldırgan neyin geri getirileceğini etkileyebilir veya kaynak belgelere talimat gömebilse, API ağ geçidinize hiç dokunmadan modeli yönlendirebilir.

On-premises kurulum bazı bulut tedarik zinciri endişelerini azaltır; ancak uygulama katmanındaki kötüye kullanımı ortadan kaldırmaz. Yalnızca ağ yollarını sertleştirirken çekilen içeriği güvenilir veri sayan ekipler, genellikle iç kırmızı takım çalışmalarında veya güvenilmeyen belge kaynaklarının olduğu ilk ciddi pilotlarda dolaylı prompt injection ile karşılaşır.

Doğrudan ve dolaylı injection

Doğrudan prompt injection kullanıcı mesajını veya sistem istemini hedefler: kullanıcı politikaları geçersiz kılmaya, sistem talimatlarını sızdırmaya veya yasaklı araç çağrıları tetiklemeye çalışır. Tipik önlemler katı rol ayrımı, politika istemleri, çıktı filtreleme ve araç izin listeleridir.

Dolaylı prompt injection talimatları belgelerin, kayıtların, e-postaların veya sonradan geri getirme kümesinde yer alan web sayfalarının içine gizler. Model, bunları yalnızca bağlam olarak gördüğü için bu talimatlara uyumlu şekilde yanıt verir. Bu, içeriklerin tamamının güvenilir personel tarafından yazılmadığı wiki, destek kanalları veya müşteri yüklemeleri içeren RAG boru hatlarında özellikle önemlidir.

Savunma, modele iletilen her parçanın düşmanca metin içerebileceğini varsaymayı gerektirir. Bu varsayım geri getirme tasarımını, parça sınırlarını, metadata işlemeyi ve araçların LLM’e nasıl açıldığını şekillendirmelidir.

Birinci katman: geri getirmenin ne döndürebileceğini sınırlamak

İndekste saldırı yüzeyini azaltarak başlayın. Açık belge sınıfları ve güven katmanları kullanın: örneğin yüksek güven indeksinde politika el kitapları, kullanıcı üretimi içerik ayrı bir indekste ve daha sıkı kurallarla. Yalnızca vektör araması güveni anlamaz; uygulamanız katman metadata’sını istem birleştirme adımına taşımalıdır.

Parça hijyeni uygulayın: web yakalamalarından HTML ve gömülü betikleri temizleyin, kodlamaları normalize edin, ilgisiz kaynakları tek opak blokta birleştirmeyin. Daha küçük, iyi atfedilmiş parçalar hangi belgenin yanıtı etkilediğini günlüğe yazmayı ve katmana özel politikalar uygulamayı kolaylaştırır.

Mümkün olduğunda geri getirme anında eşik ve çeşitlilik kısıtları ekleyin; böylece zehirli tek bir belge, tekrarlayan neredeyse mükerrer parçalarla bağlam penceresine hâkim olamaz.

İkinci katman: talimatları güvenilmeyen kanıttan ayırın

İstem birleştirme modelin rolünü belirsiz bırakmamalı. Uygulanabilir bir desen, geri getirilen materyali güvenilmeyen kanıt olarak etiketlenmiş bloklarla sarmak ve bu blokların içindeki talimatların izlenmemesi gerektiğini açıkça belirtmektir. Bu tek başına yeterli değildir; ancak diğer kontrollerle birlikte iç testlerde başarılı kaçışları belirgin şekilde azaltır.

Hizmetler arasında dağınık dizeler yerine sürümlü sistem istemleri kullanın. Görev izin veriyorsa çıktı şemaları veya kısıtlı çözümleme ekleyin; böylece model makine tarafından ayrıştırılabilir yanıtlara yönlendirilir ve aşağı akış doğrulayıcıları kontrol edebilir.

Üçüncü katman: araçlar, kimlik ve veri sızıntısı

RAG sıklıkla SQL, API veya bilet sistemlerini çağıran ajanların önünde yer alır. Model araç çağrısı üretmeye ikna edilirse dolaylı injection metin üretiminden eyleme dönebilir. Azaltımlar şunları içerir:

• Kapsamlı kimlik bilgileri: araç çağrıları için çalışma zamanı kimliği, geniş kullanıcı taklidi yerine iş akışının gerektirdiği en düşük ayrıcalıklara sahip olmalıdır.

• Hassas araçlar için insan onayı: operasyonel ajan yönetişimiyle uyumlu olarak yüksek etkili eylemler açık onay kuyruklarından geçer.

• Giden filtreleme: üretilen içerik sırlar, iç URL’ler veya veri sızıntısı girişimleriyle eşleşen ek kalıpları içermeye çalıştığında engelleme veya uyarı.

Günlükleme, güvenlik ekiplerinin yalnızca ham istemlere güvenmeden olayı yeniden kurabilmesi için geri getirilen belge kimlikleri, araç çağrıları ve kullanıcı oturumlarını ilişkilendirmelidir.

Test, izleme ve sahiplik

Evreleme ortamlarında periyodik düşmanca regresyon paketleri çalıştırın: seçilmiş zehirli belgeler, tablolara gömülü masum talimatlar ve çok dilli gizleme. Model veya embedding yükseltmelerinden sonra politikaların ve filtrelerin hâlâ geçerli olduğunu izleyin.

Ürün ve güvenlik sahipliği açık olmalı: yeni koleksiyonları kim onaylar, geri getirme parametrelerini kim değiştirebilir, model veya embedding sürümü değiştiğinde kim imzalar. On-premises RAG sıklıkla eksik GPU’dan değil, belirsiz hesap verebilirlikten dolayı sessiz bir yapılandırma değişikliğinden sonra davranış kaydığında başarısız olur.

Operasyonel panolarda reddetme artışları, olağandışı araç çağrı kalıpları, düşük güvenli kaynakların hakim olduğu geri getirme kümeleri ve ortalama bağlam uzunluğundaki ani değişimler izlenmelidir. Teknik sinyalleri, kullanıcılar bildirmeden önce nitel kaymayı fark etmek için temsili transkriptlerin periyodik incelemesiyle eşleştirin.

Bütünsel bakış

Etkili savunma birikimlidir. Ağ segmentasyonu ve özel barındırma çıkarımın nerede çalıştığını belirler; RAG’e özgü kontroller ise geri getirilen metnin davranışı ele geçirip geçiremeyeceğini belirler. Belge koleksiyonlarını potansiyel düşmanca kabul edin, politikayı istemde kanıttan ayırın, araç etki alanını minimize edin ve yığın her değiştiğinde tekrarlanabilir testlerle duruşunuzu kanıtlayın.

Kurumsal müşterilerle çalışırken, savunmaların çoğu teknikten çok süreç disiplinine takılır: hangi koleksiyonun hangi güven sınıfına ait olduğu kim tarafından onaylanıyor, yeni bir bağlayıcı veya araç eklendiğinde tehdit modeli yeniden mi yazılıyor? Bu sorulara net yanıtlar olmadan en iyi mimari bile zamanla gevşer.

Öne çıkan görsel: Kirill Sh — Unsplash.