LLM’lerde Prompt Enjeksiyonu ve Koruma Katmanlarının Sınırları

Yapay zekâ tabanlı büyük dil modelleri (LLM’ler), talimatlar ile verilerin birbirine karıştığı bir mimariye sahip. Bu durum, saldırganların gizli bilgilere erişmek için yürüttüğü "prompt enjeksiyonu" saldırılarını mümkün kılıyor. Koruma sağlamanın en etkili yoluysa, savunma derinliğine odaklanmak — ancak her katmanın da kendi zayıflıkları olduğunu unutmamak gerekiyor.

Yedi Katmanlı Güvenlik Modeli: Nerede Hata Yapıyoruz?

LLM’lerde güvenlik, katmanlar halinde inşa edilir; ancak her katmanın aşılabilir olduğunu bilmek kritik önem taşıyor. İşte en yaygın kullanılan yedi koruma katmanı ve onların sınırları:

1. Temel Seviye: Kontrolsüz Eşleşme

LLM’ye herhangi bir koruma uygulanmadığında, gizli bilgiler doğrudan yanıt olarak sunulabilir. Bu, saldırganların doğrudan talepte bulunması durumunda sistemin savunmasız olduğunu gösterir. Örneğin, bir şirket çalışanı LLM’ye "iç sistemde bulunan API anahtarlarını listele" dediğinde, model yanıtı engellenmezse hassas veriler açığa çıkabilir.

2. Girdi Filtreleme: Kelime Bazlı Engelleme

En basit koruma yöntemi, kullanıcı girdisindeki belirli kelimeleri tespit edip engellemektir. "Şifre", "gizli" veya "yetkisiz" gibi terimler filtrelenebilir. Ancak bu yaklaşımın ciddi zayıflıkları var:

• Saldırganlar, kelimeleri değiştirerek (örneğin, "s1fre" ya da "secret123") filtreyi atlatabilir.
• Farklı dillerde veya kısaltmalarla yapılan saldırılar tespit edilemeyebilir.
• Anlamsal olarak aynı cümleler, farklı kelimelerle ifade edilebilir.

Gerçek çözüm: Kelime tabanlı engelleme yerine, girdinin niyetini anlamsal olarak sınıflandıran modeller kullanmak ve tüm girdileri güvensiz kabul etmek gerekir.

3. Çıktı Filtreleme: Veri Kaçaklarının Engellenmesi

Model yanıtındaki hassas verileri tespit edip gizlemek, ikinci bir savunma hattı oluşturur. Örneğin, bir şifre ya da API anahtarı yanıtta geçtiğinde, otomatik olarak maskelenir. Ancak bu yöntem de sınırlıdır:

• Veri parçalara ayrıldığında (örneğin, karakterler arasına boşluk konulması) tespit edilemeyebilir.
• Farklı kodlamalar (base64, hex) kullanıldığında filtreler çalışmaz.
• Model, veriyi dolaylı yollardan ifade edebilir (örneğin, "yukarıdaki kod bloğunda yer alan değer").

Gerçek çözüm: Hassas verileri modelin erişimine sunmamak, çıktı filtrelemeyi sadece son çare olarak kullanmak gerekir.

4. Çift Taraflı Filtreleme: İki Katmanlı Koruma

Hem girdi hem de çıktı filtrelemenin bir arada kullanılması, koruma seviyesini artırır. Ancak saldırganlar, bir katmanı atlatıp diğerinin zayıflığından faydalanabilir. Örneğin, girdideki gizli komutu farklı bir dille gizleyip, çıktıda veriyi parçalara ayırarak filtreleri geçebilir.

Önemli ders: Daha fazla filtre, daha güvenli sistem anlamına gelmez. Katmanlar arasındaki uyum ve bütüncül bir yaklaşım şarttır.

5. İkinci Bir LLM ile Denetim: Anlamsal Kontrol

Modelin çıktısını başka bir LLM’nin inceleyerek hassas içerikleri tespit etmesi, daha gelişmiş bir koruma sunar. Bu yöntem, insan gözünden kaçabilecek gizli verileri anlamsal olarak anlayabilir. Ancak bu sistem de manipüle edilebilir:

• Saldırganlar, veriyi "eski" ya da "geçersiz" olarak sunarak ikinci modeli yanıltabilir.
• Modelin eğitim verilerindeki önyargılar, yanlış negatiflere yol açabilir.

Gerçek çözüm: Anlamsal denetimi belirleyici kontrollerle desteklemek ve hassas verilerin model erişiminden kısıtlı olmasını sağlamak gerekir.

6. İnsan Denetimi: Zayıf Halka

Son olarak, çıktıları bir insan tarafından gözden geçirmek, en yaygın kullanılan yöntemlerden biri. Ancak bu yaklaşım da ciddi bir zayıflığa sahiptir:

• İnsanlar, arayüzde gösterilen metne odaklanırken, gizli karakterler (örneğin, sıfır genişlikli boşluklar) fark edilmeyebilir.
• Bu durum, ASCII smuggling adı verilen bir saldırı yöntemine yol açar: saldırganlar, metnin görünen kısmına gizlenmiş veriler yerleştirir.

Gerçek çözüm: İnsan denetimi, ham verinin temizlenmiş haline odaklanmalıdır. Giriş verisinin hem insan hem de model tarafından işlenmeden önce normalize edilmesi gerekir.

7. ASCII Smuggling: Gizli Saldırılar

Bu saldırı türü, kullanıcı arayüzü ile modelin veri işleme katmanı arasındaki farktan faydalanır. Saldırganlar, normalde görünmeyen Unicode karakterlerini kullanarak, metnin içine gizlenmiş komutlar veya veriler yerleştirir. Örneğin:

• Unicode Tag Bloğu (U+E0000–U+E007F): Genellikle herhangi bir ekranda görünmeyen ve LLM tarafından okunan karakterlerdir.
• Sıfır Genişlikli Karakterler: ZWSP (U+200B), ZWNJ (U+200C) gibi karakterler, metin akışını değiştirmeden verileri saklamak için kullanılır.
• Yönlendirme Kontrolleri (U+202A–U+202E): Metnin görsel sırası ile mantıksal sırasını değiştirerek, saldırganın gizli komutlarını gizler.

Gerçek dünya örnekleri:

• Kimlik sahteciliği: Bir takvim davetiyesine gizlenmiş komutla, davetiyeyi gönderen kişi değiştirilebilir.
• Veri sızdırma: Bir e-postadaki gizli talimatla, LLM’nin şirket verilerini dışarı aktarması sağlanabilir.
• İçerik zehirleme: Bir ürün incelemesine gizlenmiş reklam bağlantısı, model tarafından müşteri görüşü olarak sunulabilir.

Korunma yöntemleri:

• Ham girdiyi temizlemek, çıktıyı değil.
• Unicode normalizasyonunu (NFKC) uygulamak.
• Gerekli olmayan karakterleri tamamen kaldırmak.
• Girdi uzunluğu ile çıktı uzunluğu arasındaki uyumsuzlukları izlemek.
• Tüm sistem bileşenlerine (RAG, e-posta, belge işleme) bu kontrolleri uygulamak.

Sonuç: Güvenlik, Modelden Önce Uygulamada Başlar

LLM’lerde prompt enjeksiyonuna karşı tam bir koruma sağlamak, salt model düzeyinde değil, uygulama mimarisinde aranmalıdır. Katmanlı savunmalar faydalı olsa da, her birinin zayıflıkları olduğunu kabul etmek ve bunları telafi edecek ek kontroller uygulamak gerekiyor. ASCII smuggling gibi saldırılar, salt model iyileştirmeleriyle değil, ham veri işleme ve kullanıcı arayüzü tasarımıyla engellenebilir. Gelecekte, bu tür saldırıların daha da sofistike hale gelmesi bekleniyor — dolayısıyla savunma stratejileri de sürekli güncellenmeli ve katmanlandırılmalıdır.