AI Red Teaming Nedir? LLM Güvenlik Testi Rehberi (2026)

2025 yılının başında büyük bir Türk finans kurumu, müşteri danışmanlık yapay zekasını canlıya almadan bir hafta önce özel bir güvenlik ekibine verdi. Ekip üç saat içinde on bir farklı açık buldu. Bunların bir kısmı modeli ırkçı tavsiyeler vermeye zorlayan prompt dizileriydi. Bir kısmı gizli sistem talimatlarını sızdıran sorgulardı. Biri ise modeli rakip bankaların ürünlerini önermeye yönlendiren bir jailbreak zinciriydi. Hiçbiri önceki statik testlerde, kural tabanlı filtrelerde ya da birim testlerinde yakalanmamıştı.

Bu hikaye artık istisnai değil. Kurumsal AI dağıtımları hızlandıkça, sistem güvenliğini test etmenin yeni bir disipline dönüştüğü bir dönemden geçiyoruz. Bu disiplinin adı AI red teaming.

AI Red Teaming Nedir?

Red teaming, bir sistemi korumaya çalışan tarafın değil, ona saldırmaya çalışan tarafın bakış açısını benimseyerek yapılan güvenlik testidir. Kavramın kökeni askeri planlamaya dayanıyor: Soğuk Savaş döneminde ABD ordusu, savunma stratejilerindeki körleşmeyi kırmak için düşman tarafını simüle eden ekipler kurdu. Bu ekiplerin görevi kendi sistemlerini kırmaktı; birebir rakibin gözüyle. Siber güvenlik bu mantığı devraldı ve sertifikalı bir disipline dönüştürdü; oradan da yapay zeka sistemlerine taşındı. Testin değeri tam olarak bu perspektif kaymasından gelir: kendi sistemini “düşman gibi” sorgulamak.

Geleneksel siber güvenlik red teaming’inden temel fark, saldırı yüzeyinin tanımsız olmasıdır. Bir web uygulamasını test ederken giriş noktaları bellidir; SQL injection, XSS, açık portlar gibi teknikler sistematik biçimde uygulanabilir. LLM testinde ise giriş alanı doğal dildir ve teorik olarak sonsuzdur. Modelin bir güvenlik açığı sergilemesi için gerekli prompt belirli bir kelimeden, belirli bir ton değişikliğinden ya da birden fazla konuşma turunda kurulan bağlamdan kaynaklanabilir.

AI red teaming’in özgün zorluğu da buradan geliyor. Model deterministik değildir; aynı prompt farklı çalıştırmalarda farklı yanıtlar üretebilir. Bu da testin kapsamlı olmasını güçleştiriyor.

Neden LLM’ler Özel Güvenlik Testi Gerektirir?

Klasik yazılım güvenlik araçları LLM’lere doğrudan uygulanamaz. Fuzzing araçları rastgele byte dizileri üretir; bir dil modelinin doğal dilde cevap veren davranış katmanına bu teknikler ulaşmaz. Statik kod analizi, model ağırlıklarını değil uygulama kodunu inceler; model seviyesindeki riskleri görmez.

Buradaki asıl kırılma noktası determinizm farkı. Geleneksel yazılım aynı girdiye aynı çıktıyı verir; bir açık belgelendiğinde, düzeltilene kadar orada tutarlı biçimde durur. LLM’ler stokastiktir: model bir isteğe A yanıtını verirken, aynı isteğin hafif bir dil varyasyonuna B yanıtını verebilir. Güvenlik politikası sembollere değil anlama bağlı olduğundan, imza tabanlı filtreleme yetersiz kalır.

LLM’lerin özel test gerektirdiği temel nedenler şöyle sıralanabilir:

Birincisi, giriş yüzeyi pratik olarak sınırsız. Kullanıcı, modele metin, kod, tablo, hatta bozuk karakter dizisi gönderebilir. Dil zenginliği, ton değişimleri, çok dilli kombinasyonlar ve rol yapma kurgularının her biri ayrı bir vektör. “Beklenen girdi” kavramı burada anlamlı değil.

İkincisi, güvenlik açıkları semantiktir. Bir buffer overflow belirli bir bayt dizisiyle tetiklenir; LLM açıkları ise anlama gömülüdür. Bir dilde engellenen içerik, aynı anlamı taşıyan başka bir dildeki ifadeyle geçebilir.

Üçüncüsü, emergent behavior. Büyük modeller eğitim sırasında öğretilmemiş yetenekler sergiler. Bu yetenekler bilinmiyorsa güvenlik testi de onları kapsayamaz.

Dördüncüsü, bağlam birikmesi. Çok turlu konuşmalarda model önceki turları taşır. Saldırgan birinci turda zararsız görünen sorgularla bağlam kurar; beşinci turda bu bağlam bir güvenlik açığını tetikler.

Beşincisi, davranış zamanla kayar. Modeller fine-tune edilir, güncellenir, bağlam değişir. Dün güvenli olan bir prompt yarın farklı yanıt verebilir. Tek seferlik bir test bu kaymayı yakalayamaz.

Red Teaming Metodolojisi: Adım Adım

1. Kapsam Belirleme ve Tehdit Modeli

Her kapsamı belirsiz test, eksik bulgularla biter. Test öncesinde şu soruların yanıtı yazılı olarak netleştirilmelidir:

• Test edilecek model hangisi? Hangi sürümü, hangi deployment ortamı?
• Sistem promptu dahil mi, yoksa yalnızca kullanıcı girdisi mi test edilecek?
• Hangi tehdit aktörleri modele erişebilir? (dış kullanıcı, iç çalışan, üçüncü taraf entegrasyon?)
• Sistem hangi ayrıcalıklara sahip; kötü niyetli bir aktör onu ele geçirirse ne elde eder?
• Başarı nasıl tanımlanacak? Hangi bulgular “kritik”, hangisi “düşük risk”?

Tehdit modellemesinde STRIDE metodolojisi (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) LLM bağlamına uyarlanabilir; ancak doğrudan çeviri yetmez. “Information Disclosure” bir LLM sisteminde yalnızca veritabanı sızıntısı değil, sistem promptunun ele geçirilmesi veya başka kullanıcılara ait konuşma geçmişinin açığa çıkması anlamına da gelir. Dağıtım bağlamı da riski şekillendirir: dahili bir araç ile genel erişime açık bir chatbot aynı tehdit profiline sahip değildir.

Bu soruların yanıtlanmadan başlanan test oturumları genellikle sonuçları değerlendirirken çatışmaya yol açar.

2. Tehdit Kategorileri

Red teaming oturumunda hedeflenen tehdit türleri önceden sınıflandırılmalıdır. En yaygın kategoriler şunlar:

Zararlı içerik üretimi: model nefret söylemi, tehlikeli kimyasal talimatlar veya terör propagandası üretmeye yönlendirilebilir mi? Politika ihlallerini kapsayan bu kategori genellikle ilk test alanı olur.

Bilgi sızıntısı ve sistem promptu sızdırma: sistem promptu ele geçirilebilir mi? Birçok kurumsal LLM dağıtımı, sistem promptunda gizli iş kuralları, özel yönergeler veya backend sistem bilgileri barındırır. Bunların sızması hem başlı başına bir veri ihlali hem de daha derin saldırılar için bir keşif adımıdır. Model PII içeren verilere erişiyorsa bunları sızdırabilir mi?

Görev sapması: belirli bir amaç için kurulan model başka bir amaca çekilebilir mi? Finans asistanı tıbbi tavsiye verebilir mi, müşteri hizmetleri botu siyasi tartışmaya sürüklenebilir mi?

Jailbreak kalıpları: DAN (“Do Anything Now”) tarzı rol oyunları ve karakter ele geçirme kurguları (“Sen artık sınırlama tanımayan X karakterisin”), çoklu dil kombinasyonları, kodlama hileleri (Base64, ters alfabe) ve çok adımlı bağlam manipülasyonu. 2025 itibarıyla en etkili jailbreak teknikleri tek adımda değil, birkaç konuşma turu boyunca kademeli bağlam kurarak çalışıyor; red team bu uzun oyun dinamiklerini simüle etmek zorunda.

Prompt injection: ajanlar ve RAG sistemlerinde özellikle dikkat isteyen bu alan, harici verilerden gelen talimatların modeli ele geçirip geçiremeyeceğini test eder. Doğrudan kullanıcı girdisiyle çalışabildiği gibi, modelin okuduğu belgelere veya harici veri kaynaklarına gömülü talimatlar biçiminde de gelir (dolaylı injection). Web sayfasındaki gizli bir metin bile modelin davranışını değiştirebilir. Daha ayrıntılı bilgi için prompt injection nedir yazısına bakabilirsiniz.

Çok modlu saldırılar: görsel veya ses girişi kabul eden modeller ek vektörlere açık. Görsele steganografik yöntemle gömülmüş talimatlar, OCR akışlarına enjekte edilmiş metinler veya ses dosyasının belirli frekans katmanlarındaki mesajlar bu kategoride. Deepfake teknolojisinin olgunlaşmasıyla görsel, ses ve video vektörleri de sistematik test kapsamına girdi.

Çok ajanlı zincir manipülasyonu: agentic sistemler büyüdükçe bu kategori de ağırlaşıyor. Birden fazla AI ajanının birbirine bağlandığı pipeline’larda bir ajana yapılan injection tüm zincire yayılabilir. Görev delegasyonu, araç çağrısı ve bellek paylaşımı noktalarının her biri potansiyel geçiş noktası.

3. Test Teknikleri

Manuel keşif. Deneyimli bir red teamer, modelle gerçek bir saldırgan gibi etkileşime girer. Bu yaklaşım, otomatik araçların göremediği nüanslı zafiyetleri ortaya çıkarır. Aynı zamanda en yüksek maliyetli tekniktir.

Otomatik fuzzing. Garak ve PyRIT gibi araçlar, önceden tanımlanmış saldırı kategorilerinde büyük ölçekte test çalıştırır. Binlerce prompt varyantı kısa sürede uygulanabilir; insan testerın gözden kaçıracağı istatistiksel örüntüler bu yolla yakalanır.

Çok turlu konuşma saldırıları. Saldırı tek bir promptta değil, birden fazla konuşma turunda kurulur. Model, güvenli görünen birkaç turdan sonra hassas içerik üretmeye yönlendirilebilir.

Çapraz dil testleri. Model Türkçe güvenlik politikaları için fine-tune edilmiş ama İngilizce ya da Arapça sorgulara karşı zayıf kalıyor olabilir. Dilsel eşdeğerlik açıkları, özellikle çok dilli deployment’larda sıkça karşılaşılan bir zafiyet türüdür.

LLM destekli red teaming. Hibrit akışta öne çıkan bir teknik: bir model, başka bir modele karşı saldırı promptları üretir. Otomasyon geniş yüzeyi hızla tarar, insan red teamer’lar araçların bulamayacağı yaratıcı vektörleri araştırır; en etkili programlar ikisini bir arada yürütür.

4. Araçlar ve Çerçeveler

Microsoft PyRIT. Python tabanlı, açık kaynaklı red teaming çerçevesi. Saldırı stratejisi, orchestrator ve hedef katmanlarını birbirinden ayıran modüler yapısıyla büyük ölçekte otomatik test çalıştırmaya ve farklı senaryo kombinasyonları kurmaya uygun. Azure OpenAI ve diğer model sağlayıcılarıyla entegre çalışır.

Garak. NVIDIA destekli LLM zafiyet tarayıcısı. Hallüsinasyon, jailbreak, prompt injection, toxicity ve veri sızıntısı gibi kategorilerde yüzlerce hazır “probe” barındırır. Komut satırından çalıştırılabilir yapısı CI/CD pipeline entegrasyonunu kolaylaştırır; farklı modellere ve API uç noktalarına karşı otomatik tarama yapabilir.

Promptfoo. Hem prompt güvenlik testi hem de regresyon testi için kullanılabilir. Model çıktılarını önceden tanımlanmış beklentilerle karşılaştırır; farklı model sürümleri arasında güvenlik davranışı karşılaştırması yapılabilir.

PromptBench. Akademik araştırmalar için geliştirilmiş adversarial değerlendirme kütüphanesi. Standart NLP görevlerinde model sağlamlığını sistematik biçimde ölçer.

NVIDIA NeMo Guardrails. Test aracının ötesinde hem guardrail tanımlama hem de test için kullanılır. Red teaming sırasında belirlenen açıkları hemen guardrail kuralına dönüştürme iş akışını destekler.

Düzenleyici Çerçeveler: NIST, MITRE ATLAS ve AB AI Act

NIST AI RMF, 2023’ten itibaren kurumsal AI güvenlik standartlarının referans belgesi. Çerçevenin “Measure” işlevi altında red teaming açıkça bir değerlendirme yöntemi olarak tanımlanıyor.

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems), siber güvenlik alanındaki ATT&CK çerçevesinin AI karşılığı. AI saldırı taktikleri ve tekniklerini kategorize eden bu taksonomi, red teaming kapsamını planlarken başvurulabilecek sistematik bir kaynak.

Avrupa Birliği Yapay Zeka Yasası (AI Act) ise tabloyu gönüllülükten zorunluluğa taşıyor. 2024’te yürürlüğe giren yasa, geçiş dönemleriyle birlikte yüksek riskli sistemler için uyum yükümlülüklerini devreye soktu. Madde 9 kapsamında yüksek riskli AI sistemleri için belgelenmiş bir risk yönetim süreci şart; yasanın getirdiği başlıca gereklilikler şunlar:

• Risk yönetim sistemi: dağıtım öncesinde sistematik risk değerlendirmesi zorunlu.
• Test ve doğrulama: modelin hedeflenen amaçları doğru yerine getirdiğinin ve güvenlik açıklarının belgelendiğinin kanıtlanması gerekiyor.
• İnsan denetimi: kritik kararların AI tarafından bağımsız verilmemesi; insan onayı mekanizmaları.
• Şeffaflık: kullanıcıların bir AI sistemiyle etkileşimde olduklarını bilmeleri.

“Sistematik risk değerlendirmesi” ve “test ile doğrulama” maddeleri fiilen organize bir red team sürecini gerektiriyor; red teaming bulguları bu uyum dosyasının doğrulanabilir bileşeni olarak kullanılabiliyor. Türkiye’deki kurumlar için de durum yakın vadede belirleyici: AB ile ticari ilişkisi olan veya AB pazarına hizmet veren şirketler bu gereklilikleri görmezden gelemeyecek.

Yapay zeka güvenliği yazısında bu çerçevelerin genel AI güvenlik yaklaşımlarıyla nasıl ilişkilendiğini daha geniş bir perspektiften bulabilirsiniz.

Büyük Laboratuvarlar ve Gerçek Dünyadan Vakalar

OpenAI, GPT-4 lansman öncesi. OpenAI, GPT-4’ü kamuoyuyla paylaşmadan önce birkaç ay boyunca dahili ve harici yüzlerce red teamer ile çalıştı. Bu süreçte biyolojik silah talimatları, siber saldırı kodu üretimi, kimlik taklidi ve yüksek riskli dezenformasyon gibi onlarca zafiyet kategorisi belirlendi; güvenlik önlemleri sistem çıkmadan önce güncellendi.

Meta ve purple teaming. Meta, Llama güvenlik raporlarında red team ile blue team’i (savunma) bir arada çalıştıran “purple teaming” metodolojisini belgeledi: açık bulunduğu anda savunma güncelleniyor, süreç döngüsel işliyor. LLaMA 3 öncesinde 350’yi aşkın bağımsız araştırmacıyla yürütülen çalışmada farklı dillerdeki güvenlik davranışı tutarsızlıkları ve çok turlu saldırı kalıpları ortaya çıktı; sonuçlar model kartıyla birlikte yayımlandı.

Anthropic. Claude modelleri için yayımladığı sistem kartlarında red team sürecini yapılandırılmış biçimde anlatıyor. Constitutional AI yaklaşımıyla model değerlerini belirleyip bu değerlere aykırı davranışları sistematik biçimde test ediyor.

Google DeepMind. Gemini serisi için güvenlik değerlendirme raporları yayımladı; çok modlu yetenekler devreye girince test kapsamını görsel saldırı vektörlerine genişletti.

Çok dilli deployment açıkları. Büyük bir Avrupa bankasının müşteri hizmetleri LLM’i, İngilizce sorgulara karşı sıkı güvenlik davranışı sergilerken aynı soruların Romence versiyonlarında bu filtreleri atladı. Sorun, güvenlik ince ayarlarının yalnızca İngilizce verilerle yapılmış olmasından kaynaklanıyordu. Benzer bir vakada bir bankanın chatbotu, farklı dillerde iç içe geçirilmiş bir jailbreak serisiyle sistem promptunu sızdırdı; kurum sorunu ancak haftalar sonra fark edebildi.

Kurumsal Red Teaming Programı Nasıl Kurulur?

Dahili ekip mi, dışarıdan hizmet mi?

Dahili bir red team’in avantajı, sistemi ve iş bağlamını derinlemesine bilmesidir. Dezavantajı, aynı zihin haritasını paylaşan bir ekibin “kör nokta” üretmesidir. Dışarıdan hizmet alan bir ekip taze bakış açısı getirir ama sistemi öğrenmesi zaman alır.

Pratikte çoğu kurum ikisini birleştirir. Dahili ekip rutin testleri yürütür; dışarıdan uzmanlar yılda bir ya da iki kez daha derin bir değerlendirme yapar. Bu kombinasyon hem kör nokta riskini hem de maliyeti dengeler.

Bir ayrıntı daha: manuel test aşamasına teknik olmayan ama yaratıcı düşünen ekip üyelerini de katın. Red teaming yalnızca güvenlik uzmanlarına özgü bir iş değil; farklı geçmişlerden gelen bakış açıları, uzmanların rutinleştirdiği kalıpların dışında beklenmedik vektörler bulur.

Test sıklığı ve tetikleyiciler

Red teaming, tek seferlik bir etkinlik değil. Üretim ortamları canlı; yeni prompt kalıpları ve değişen kullanıcı davranışları sürekli yeni vektörler üretiyor. Aşağıdaki durumlarda yeni bir test oturumu planlanmalıdır:

• Model yeni bir sürüme geçirildiğinde
• Sistem promptu ya da güvenlik politikası güncellendiğinde
• Yeni bir kullanım alanı veya kullanıcı kitlesi eklendiğinde
• Kamuoyuna açık bir jailbreak tekniği modeli hedef aldığında

Bulguları önceliklendirme ve raporlama

Red teaming sonuçları ham haliyle eyleme dönüştürülemez. Her bulgu için şu bilgilerin raporlanması gerekiyor:

• Zafiyetin kategorisi ve spesifik tetikleyicisi
• Yeniden üretim adımları (reproducibility)
• Olası etkisi (kullanıcı zararı, marka riski, yasal risk)
• Önerilen düzeltme yaklaşımı (guardrail mı, fine-tuning mi, sistem prompt değişikliği mi?)

Belgelenmemiş test, yapılmamış test gibidir: iki oturum arasında karşılaştırma yapabilmek de, düzeltme sonrası yeniden test edebilmek de kayda bağlı.

Red Teaming ve Guardrails: Birbirini Tamamlayan İki Katman

Red teaming açıkları bulur. LLM guardrails ise bu açıkları kapatır. İkisi birbirinin alternatifi değil; birbirini besleyen iki ayrı süreç.

Red teaming olmadan guardrail tasarımı, bilinmeyen tehditlere karşı kör savunma yapmak anlamına gelir. Guardrail olmadan red teaming, bulguların uygulamaya geçirilmediği akademik bir egzersiz kalır.

Olgun bir güvenlik programında bu döngü şöyle çalışır: red teaming yeni bir zafiyet kategorisi ortaya çıkarır → guardrail politikası güncellenir → sonraki red teaming oturumu yeni politikanın etkinliğini sınar → yeni vektörler ortaya çıkar → döngü devam eder. Döngü bitmez; güvenlik bir ürün özelliği değil, süregiden bir süreçtir.

Constitutional AI gibi eğitim zamanı hizalama yöntemleri bu denkleme üçüncü bir katman ekler: modeli zararlı davranışları reddetmeye eğitmek. Ama eğitim zamanı hizalama tek başına yeterli değildir; red teaming, hizalamanın gerçek dünya saldırılarına karşı ne ölçüde tutarlı kaldığını doğrular.

Gelecek: Otonom Red Team Ajanları

Alandaki belki de en ilginç ve en paradoksal gelişme: AI’ler artık başka AI’leri test ediyor.

Araştırmacılar, bir LLM’in hedef modele karşı saldırı senaryoları üretip bunları denediği, sonuçlardan öğrenip yeni saldırılar türettiği otonom döngüler kurdu. Bu yaklaşım, insan red teamer’ların ulaşamayacağı ölçekte saldırı uzayını tarıyor.

Paradoks şu: bu otonom test ajanlarının kendisi de güvensiz olabilir. Red team ajanı ele geçirilirse, hedef sistemi test etmek yerine ona saldırmak için kullanılabilir. “AI kendi güvenliğini test ediyor” fikri bir çözüm olduğu kadar yeni bir risk katmanı da.

AI red teaming önümüzdeki birkaç yılda sektörün standart kalite kapısı haline gelecek. GDPR veri işleme pratiklerini nasıl yeniden şekillendirdiyse, AB Yapay Zeka Yasası da güvenlik testini zorunlu bir uyum adımına dönüştürüyor. Bu süreçle şimdiden ilgilenen ekipler daha az geriden koşacak.

Eylem Adımları

Kurumsal bir AI deployment’ı varsa ya da planlıyorsanız, red teaming programını kurmak için makul bir başlangıç noktası şu:

Önce tehdit modeli. Sistemi kim kullanıyor, hangi veriye erişiyor, hangi çıktılar karar süreçlerini etkiliyor, kötü niyetli bir aktör bu sistemden ne elde etmek ister? Bu soruların yanıtı olmadan test kapsamı net olamaz.

Sonra ilk manuel oturum. Dışarıdan deneyimli bir red teamer ile sınırlı kapsamlı bir test yapın. Neyi aradığınızı öğrenmek için bile bu oturum değerli.

Ardından otomasyona geçiş. Garak veya PyRIT ile tekrarlanabilir test süreçleri kurun; her ikisi de ücretsiz ve açık kaynak. Her bulguyu kayıt altına alın; iki oturum arasında karşılaştırma yapabilmek için.

Son olarak, guardrail döngüsünü bağlayın. Red teaming bulguları doğrudan guardrail güncellemelerine dönüşecek bir iş akışı tanımlanmazsa, test raporları sonunda çekmecelerde kalır. Model veya politika her değiştiğinde yeni bir döngü tetiklensin.

Prompt engineering ile hem güçlü hem de güvenli sistem promptları nasıl yazılır konusunu da araştırıyorsanız, iyi bir sistem promptunun saldırı yüzeyini baştan nasıl daraltabileceğini görmek için o yazıya da göz atabilirsiniz.

AI red teaming, büyük bir bütçe gerektiren bir lüks değil. Kurumsal AI sistemlerinin üretim ortamına çıkmadan önce geçmesi gereken bir güvenlik olgunluk adımı. Sistemin ne kadar zeki olduğu değil, kötüye kullanıma karşı ne kadar dirençli olduğu, uzun vadeli güveni belirleyecek olan şey.