AI Red Teaming Playbook
Bir LLM Uygulaması Nasıl Test Edilir?

Red team'in amacı ne olmalı?

AI red teaming, modelin sınırlarını zorlayan bir test disiplinidir; ama tek başına "jailbreak bulma yarışı" değildir. Kurumsal tarafta amaç, LLM uygulamasının hangi şartlarda yanlış karar verdiğini, hangi veriye yanlış eriştiğini, hangi aracı yanlış kullandığını ve bu durumun kurum için ne anlama geldiğini ortaya koymaktır.

Bu ayrım önemli. Bir modelin uygunsuz bir cümle üretmesi ile aynı modelin yetkisiz bir veriyi dışarı taşıması aynı risk değildir. Bir chatbotun politika dışı yanıt vermesi ile ödeme aracını yanlış parametreyle çağırması aynı etkiyi doğurmaz. Red team testinin kalitesi, bulduğu örnek sayısıyla değil, bulgunun kurum riskine ne kadar temiz bağlandığıyla ölçülür.

İyi bir test çıktısı, blue team'in eline doğrudan aksiyon verir: hangi log tutulacak, hangi izin sınırı değişecek, hangi RAG kaynağı karantinaya alınacak, hangi tool çağrısı insan onayına bağlanacak?

Testten önce mimari çıkarımı

LLM uygulamasını test etmeden önce sistemin nasıl çalıştığını anlamak gerekir. Model tek başına mı cevap veriyor, yoksa RAG ile doküman mı okuyor? Tool calling var mı? Kullanıcı yetkisi modele nasıl taşınıyor? Model çıktısı sadece ekranda mı gösteriliyor, yoksa başka sisteme e-posta, SQL, komut veya ticket olarak mı gidiyor?

Bu sorular cevaplanmadan yapılan test, yüzeysel kalır. Çünkü saldırı yüzeyi modelin kendisinden çok modelin bağlı olduğu akışlarda ortaya çıkar. Bir destek asistanı için kritik yüzey müşteri verisidir; bir hukuk asistanı için doküman kaynağıdır; bir agent için tool parametreleridir; bir iç operasyon asistanı için kullanıcı yetkisidir.

Bu aşamada basit bir tablo yeterlidir: varlık, kaynak, güven seviyesi, modelin erişimi, eylem yetkisi, log durumu ve insan onayı. Test planı bu tablo üzerinden yazılır.

Yedi test alanı

1. Prompt sınırı

Model sistem talimatı, geliştirici talimatı ve kullanıcı talimatı çakıştığında hangisini izliyor? Testin ilk alanı budur. Burada amaç çalışan payload listesi üretmek değil, modelin talimat hiyerarşisini hangi durumlarda gevşettiğini görmektir.

2. RAG ve dış veri

Doküman, e-posta, web sayfası veya ticket içinde modele yazılmış talimatlar varsa, model bunları veri olarak mı okuyor, yoksa emir gibi mi uyguluyor? RAG sistemlerinde en kritik ayrım budur. Kaynağın kimden geldiği, retrieval puanı, doküman etiketi ve kullanıcı yetkisi birlikte test edilmelidir.

3. Tool calling

Model hangi araçları çağırabiliyor? İzinli araçlar kötüye kullanılabiliyor mu? Parametreler uygulama tarafında doğrulanıyor mu? Bir red team testi, yalnızca model cevabına değil tool çağrı zincirine de bakmalıdır. Çünkü en ciddi etki çoğu zaman modelin söylediğinde değil, yaptığındadır.

4. Yetki sınırı

Kullanıcı A'nın görebildiği veri ile kullanıcı B'nin görebildiği veri ayrılıyor mu? Model, kendi bağlamında gördüğü şeyi her kullanıcıya taşıyabiliyor mu? LLM uygulamalarında klasik yetki kontrolü hâlâ temel savunmadır. Modelin "bu kullanıcı görebilir" demesi yeterli değildir.

5. Veri sızıntısı

Model sistem promptunu, gizli anahtarları, kişisel veriyi, müşteri bilgisini veya kurum içi dokümanı açığa çıkarabiliyor mu? Bu test, yalnızca doğrudan soru sormakla sınırlı olmamalıdır. Özetleme, dönüştürme, çeviri, raporlama ve format değiştirme gibi masum görünen görevler de veri sızıntısı yüzeyidir.

6. Bellek ve kalıcılık

Saldırı oturum bittikten sonra etkisini sürdürüyor mu? Modelin belleğe yazdığı bilgi sonraki konuşmayı etkiliyor mu? Kullanıcılar arası bağlam karışıyor mu? Bellek katmanı olan sistemlerde red team testi, yalnızca anlık cevabı değil sonraki davranışı da ölçmelidir.

7. Gözlemlenebilirlik

Bir saldırı denemesi yapıldığında güvenlik ekibi bunu görebiliyor mu? Hangi kullanıcı, hangi doküman, hangi retrieval sonucu, hangi tool çağrısı ve hangi çıktı ile olay oluştu? Log yoksa bulgu yalnızca "model kırıldı" seviyesinde kalır; operasyonel savunmaya dönüşmez.

Bulguyu nasıl yazmak gerekir?

AI red team bulgusu, klasik pentest bulgusundan farklı değildir: etki, tekrar üretilebilirlik, kapsam, kök neden ve önerilen kontrol net olmalıdır. Fark, bulgunun yalnızca teknik zafiyet değil, model davranışı ve uygulama mimarisi kesişiminde durmasıdır.

İyi bir bulgu şu sorulara cevap verir: Saldırgan hangi kanaldan etki etti? Model neyi yanlış yorumladı? Hangi veri veya araç bundan etkilendi? Kullanıcı yetkisi nasıl aşıldı? Blue team bu olayı loglardan görebilir miydi? Kurum bunu hangi kontrolle kapatabilir?

Bulguyu "model kandırıldı" diye yazmak zayıftır. Daha doğru ifade şuna benzer: "RAG kaynağından gelen dış talimat, sistem talimatından ayrıştırılmadığı için model doküman içeriğini uygulama talimatı gibi yorumladı; bu durum yetkisiz veri özetlemesine yol açabilir." Bu cümle saldırıyı değil, güvenlik kararını anlatır.

Blue team devri

Red team çalışmasının değeri, blue team'e devredilen kontrol setiyle artar. Her bulgunun sonunda uygulanabilir bir savunma maddesi olmalıdır. Prompt sertleştirme bazı durumlarda gerekir, ama tek çözüm değildir. Daha kritik kontroller genelde uygulama katmanındadır: RAG kaynak etiketi, tool izin listesi, parametre doğrulaması, insan onayı, bellek karantinası, log zenginleştirme ve alarm kuralı.

Bu devir yapılmadığında test bir defalık gösteriye dönüşür. Yapıldığında ise kurum aynı sınıf saldırılara karşı kalıcı savunma kazanır. AI red teaming'in gerçek karşılığı budur: bulguyu kontrole çevirmek.

Kurumsal kontrol listesi

• Modelin eriştiği veri kaynakları listelendi mi?
• RAG kaynakları güven seviyesine göre etiketleniyor mu?
• Tool calling varsa izin listesi ve parametre doğrulaması var mı?
• Kritik eylemler insan onayına bağlandı mı?
• Kullanıcı yetkisi model kararından bağımsız doğrulanıyor mu?
• Model çıktısı başka sisteme gidiyorsa format ve aksiyon sınırı var mı?
• Bellek kayıtları amaç, süre ve erişim sınırına göre ayrıldı mı?
• Prompt, retrieval, tool çağrısı ve çıktı zinciri olay araştırmasına yetecek şekilde loglanıyor mu?
• Red team bulguları alarm kuralına veya uygulama kontrolüne çevriliyor mu?

Sonuç

AI red teaming, LLM uygulamasını kırmaya çalışır; ama bunu yalnızca kırmak için yapmaz. Amaç, sistemin nereden etkilenebileceğini görmek ve bu etkiyi azaltacak savunmayı kurmaktır.

İyi bir test; mimariyi çıkarır, saldırı yüzeylerini ayırır, bulguyu kurum riskine bağlar ve blue team'e uygulanabilir kontrol bırakır. Bu yaklaşım olmadan red team çalışması ilgi çekici olabilir, ama kalıcı güvenlik üretmez.