Backdoored LLM Tespiti Nasıl Yapılır?
Backdoor Tespiti Neden Zordur?
Backdoored LLM tespiti klasik güvenlik taramasına benzemez. Zararlı davranış her istekte görünmez. Model yüzlerce normal prompt karşısında güvenli, tutarlı ve yararlı yanıt verirken belirli bir tetikleyici kalıbında politika dışı davranabilir.
Bu tetikleyici tek bir kelime olmak zorunda değildir. Yazım hatası, nadir karakter dizisi, markdown yapısı, belirli bir rol tanımı, dil değişimi veya sistem promptuna benzeyen gömülü bir ifade backdoor davranışını tetikleyebilir.
Ölçekli Tespit İçin Üç Katman
1. Trigger Arama
İlk katmanda modelin anormal davranış ürettiği tetikleyici uzayı aranır. Bu süreç rastgele prompt denemesi değildir. Dil, format, görev tipi, kullanıcı rolü, veri sınıfı ve tool yetkisi gibi değişkenler kontrollü şekilde kombinlenmelidir.
2. Davranış Farkı Analizi
İkinci katmanda aynı model ailesi, aynı görev ve benzer promptlar arasında davranış farkı ölçülür. Model belirli koşulda gereksiz özgüven kazanıyor, güvenlik politikasını atlıyor veya normalde reddettiği görevi kabul ediyorsa bu bir sinyaldir.
3. Tool ve RAG Etki Testi
Üçüncü katman model cevabından daha önemlidir. Modelin tool çağırdığı, dosya okuduğu, retrieval yaptığı veya başka servisleri tetiklediği sistemlerde backdoor yalnızca metin çıktısı değildir. Arka planda yapılan API çağrısı da test edilmelidir.
Kurumsal Kontrol Listesi
- Onaylı model registry dışında model çalıştırmayın.
- Yeni modeli yalnızca benchmark skoruna göre kabul etmeyin.
- Davranış testlerini Türkçe, İngilizce ve karma dil promptlarla yapın.
- RAG veri setine gömülü talimatları ayrıca test edin.
- Tool çağrılarını model cevabından bağımsız loglayın.
- Model sürümleri arasında risk farkı raporu üretin.
- Güvenlik testlerini model güncelleme sürecinin parçası yapın.
Eresus Yaklaşımı
Eresus Security, backdoored LLM tespitini model dosyası, prompt yüzeyi, RAG bağlamı ve tool execution zinciriyle birlikte değerlendirir. Kurum içinde açık kaynak model kullanıyorsanız veya üçüncü parti bir LLM'i kritik iş akışlarına bağlıyorsanız, model kabul süreciniz red team testleriyle doğrulanmalıdır.
Sık Sorulan Sorular
Bu konuda ilk adım ne olmalı?
Önce varlık, veri, kimlik ve iş etkisi birlikte haritalanmalıdır. Böylece güvenlik testi araç odaklı değil risk odaklı ilerler.
Profesyonel destek ne zaman gerekir?
Sistem üretime yakınsa, hassas veriye erişiyorsa veya bulgular birden fazla ekibi etkiliyorsa bağımsız güvenlik değerlendirmesi gerekir.
Uygulama Notları
AI güvenliği incelenirken ilk soru modelin ne cevap verdiği değil, sistemin hangi yetkiyle ne yapabildiğidir. Aynı prompt güvenli görünebilir; fakat arka tarafta CRM, dosya deposu, ticket sistemi veya SQL aracı bağlıysa risk seviyesi tamamen değişir.
Pratik değerlendirme için ekip şu dört katmanı ayrı ayrı yazmalıdır:
- Kullanıcıdan gelen giriş ve sistem prompt sınırları.
- Retrieval kaynağı, index yetkisi ve hassas veri filtresi.
- Tool çağrıları, API token kapsamı ve onay mekanizması.
- Log, izleme, alert ve olay müdahale akışı.
Karar Çerçevesi
AI uygulaması yalnızca metin önerisi veriyorsa risk daha çok veri sızıntısı ve yanlış yönlendirme üzerinden okunur. Uygulama tool çağırıyor, dosya yazıyor, ticket açıyor, ödeme başlatıyor veya müşteri kaydı güncelliyorsa değerlendirme agent runtime güvenliğine döner.
Bu ayrım önemlidir çünkü prompt filtreleri runtime yetki hatasını çözmez. Filtre modeli ikna etmeye çalışır; güvenli runtime ise agent yanlış ikna edilse bile neye erişemeyeceğini belirler.
Profesyonel Destek Eşiği
Aşağıdaki durumlardan biri varsa konu artık yalnızca iç kontrol maddesi değildir:
- Production verisi veya müşteri hesabı etkilenebilir.
- Yetki sınırı birden fazla rol ya da tenant üzerinden çalışır.
- Bulgu zincirlenince veri sızıntısı, kalıcı erişim veya operasyon kesintisi doğurabilir.
- Ekipte test kanıtını yeniden üretecek ve remediation önceliği çıkaracak zaman yoktur.
Eresus Security bu noktada bulguyu sadece raporlamakla kalmaz; istismar kanıtı, etki analizi, remediation sırası ve retest kriteriyle birlikte ele alır. Böylece ekip “ne açık?” sorusundan “neyi, hangi sırayla kapatmalıyız?” kararına geçer.
Saha Kontrol Notları
Bu başlık pratikte yalnızca teorik risk olarak ele alınmamalıdır. AI sistemlerinde zafiyetin etkisi, modelin bulunduğu ortam ve bağlı olduğu veri kaynaklarıyla birlikte değişir.
İnceleme sırasında şu kanıtlar toplanmalıdır:
- Model veya agent hangi ortamda çalışıyor?
- Hangi kullanıcı veya servis hesabı kullanılıyor?
- Hassas veri kaynakları ayrı etiketlenmiş mi?
- Model dosyası veya artefact kaynağı doğrulanmış mı?
- Yükleme anında kod çalıştırma riski var mı?
- Retrieval sonuçları kullanıcı yetkisine göre filtreleniyor mu?
- Tool çağrıları ayrı loglanıyor mu?
- Kritik aksiyonlarda onay mekanizması var mı?
- Test ortamı production verisinden ayrılmış mı?
- Olay halinde hangi loglardan geri dönüş yapılacak?
Uygulama Kontrol Listesi
- Güvenilmeyen model dosyaları izole ortamda açılmalı.
- Model registry erişimi minimum yetkiyle çalışmalı.
- Hash, imza veya provenance bilgisi tutulmalı.
- Agent tool izinleri görev bazlı ayrılmalı.
- Memory ve retrieval kaynakları ayrı güven sınırı olarak ele alınmalı.
- Prompt testleri runtime aksiyon testleriyle desteklenmeli.
- Her bulgu iş etkisiyle birlikte raporlanmalı.
Karar Noktası
Bu risk müşteri verisine, üretim API’sine, geliştirici ortamına veya model yükleme hattına dokunuyorsa bekletilmemelidir. Eresus Security bu tip incelemelerde dosya, runtime, tool ve veri sınırını birlikte test ederek gerçek saldırı yolunu kanıtlar.
Ek Kontrol Soruları
- Bu risk hangi varlıkları etkiliyor?
- Hangi kullanıcı rolleri bu akışa erişebiliyor?
- Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
- Bulgunun müşteri verisine etkisi var mı?
- Loglardan olayın izi sürülebiliyor mu?
- Düzeltme sonrası retest nasıl yapılacak?
- Geçici önlem ile kalıcı çözüm ayrıldı mı?
- İş etkisi teknik ekibin dışında da anlaşılır mı?
- Benzer hata için önleyici kontrol eklenebilir mi?
- Ekip bu kontrolü release sürecine bağlayabilir mi?
- Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
- Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?
İlgili Araştırmalar
AI Model Dosyalarında Backdoor Riski
Pickle, PyTorch, ONNX, Keras ve GGUF model dosyalarında backdoor riskinin neden klasik dosya taramasından daha derin olduğunu inceliyoruz.
AI SecurityAI Chatbot Backdoor Riski
Kurumsal AI chatbotların nasıl arka kapıya dönüşebileceğini, veri sızıntısı ve yetki kötüye kullanımı risklerini inceliyoruz.