Kategori Rehberi · LLM Güvenliği · AI Red Teaming

AI Red Teaming Nedir?
Yapay Zekâ Red Team Türkiye Rehberi

Yapay zekâ sistemleri artık üretim ortamlarında karar veriyor, para transferi tetikliyor, hasta ve müşteri verisiyle konuşuyor. Peki bu sistemleri gerçek bir saldırgan gibi kim sınıyor? Bu rehber, AI red teaming'in ne olduğunu, klasik sızma testinden nerede ayrıldığını, hangi metodoloji ve araçlarla yürütüldüğünü ve Türkçe bağlamın neden ayrı bir disiplin gerektirdiğini objektif biçimde ele alıyor.

TLDR: AI red teaming, yapay zekâ sistemlerini (LLM, RAG, agent) gerçek bir saldırganın gözüyle kasıtlı olarak kırmaya çalışan çekişmeli bir güvenlik test disiplinidir. Klasik penetrasyon testinden temel farkı: hedef, koddaki deterministik açıklar değil, doğal dille programlanan olasılıksal model davranışıdır. Metodoloji genellikle OWASP LLM Top 10 (2025) zafiyet sınıflarını, MITRE ATLAS taktik-teknik matrisini ve NIST AI RMF / AI 600-1 yönetişim çerçevesini temel alır; otomasyon tarafında Microsoft PyRIT ve garak gibi açık kaynak iskeletler kullanılır. Türkçe dağıtımlar için İngilizce şablonlar yetmez — morfoloji, kod-karışımı, KVKK ve TC kimlik gibi yerel bağlam ayrıca test edilmelidir. Bu yazıda tanım, fark, saldırı yüzeyi, metodoloji, araçlar, süreç adımları ve kimler için gerektiği ele alınıyor.

AI Red Teaming Nedir?

AI red teaming (yapay zekâ red team), bir yapay zekâ sistemini — özellikle büyük dil modeli (LLM), erişimli üretim (RAG) mimarisi veya otonom agent'ı — gerçek bir saldırganın yaratıcılığıyla, kasıtlı ve sistematik biçimde kırmaya çalışan çekişmeli (adversarial) bir güvenlik test disiplinidir. Amaç, sistemin güvenlik kurallarını atlatan zafiyetleri — prompt injection, jailbreak, veri sızıntısı, yetki aşımı, model manipülasyonu — üretime çıkmadan veya bir kötü niyetli aktör bulmadan önce tespit etmek, belgelendirmek ve önceliklendirmektir.

Terim, askeri ve siber güvenlik geleneğindeki "kırmızı takım" kavramından gelir: savunmayı test etmek için bilinçli olarak saldırgan rolünü üstlenen ekip. Klasik siber güvenlikte red team ağı, uç noktaları ve insan faktörünü hedef alır. AI red teaming ise saldırı yüzeyini modelin kendisine — yani doğal dille programlanabilen, olasılıksal davranan bir bileşene — kaydırır.

Kritik ayrım şudur: geleneksel yazılımda güvenlik açığı koddadır ve deterministiktir. Bir LLM'de ise "zafiyet" çoğu zaman modelin davranışındadır: doğru bağlamda, doğru kelimelerle sorulduğunda modelin yapmaması gereken şeyi yapması. Bu yüzden AI red teaming, klasik güvenlik testinin bir uzantısı değil, kendi metodolojisi, araç seti ve uzmanlık alanı olan ayrı bir disiplindir.

AI Red Teaming ile Klasik Sızma Testi (Pentest) Arasındaki Fark Nedir?

En sık karıştırılan nokta budur. Bir kurum "biz zaten penetrasyon testi yaptırıyoruz" dediğinde çoğu zaman ağ ve uygulama katmanını kastediyor. Oysa LLM tabanlı bir ürünün asıl saldırı yüzeyi, o testlerin dokunmadığı bir yerdedir: modelin kendisiyle yürütülen doğal dil diyaloğu.

Boyut Klasik Sızma Testi AI Red Teaming
HedefAğ, uygulama, altyapı, kodModel davranışı (LLM/RAG/agent)
Zafiyetin doğasıDeterministik (SQLi, XSS, RCE)Olasılıksal (davranışsal, bağlama bağlı)
TekrarlanabilirlikAynı girdi → aynı çıktıAynı girdi bazen çalışır, bazen çalışmaz
Saldırı aracıExploit kodu, payload, tarayıcıDoğal dil promptu, sosyal manipülasyon
Başarı ölçütüErişim/yetki elde etmePolitika ihlali, sızıntı, istenmeyen eylem
Referans çerçeveOWASP Top 10, PTES, OSSTMMOWASP LLM Top 10, MITRE ATLAS, NIST AI RMF
Yeniden testYama sonrası tek sefer doğrulamaSürekli — her model/prompt güncellemesinde

En pratik fark tekrarlanabilirlikte gizlidir. Klasik pentest'te bir açık ya vardır ya yoktur; exploit çalışır ve tekrar çalışır. LLM'de aynı jailbreak promptu üç denemenin ikisinde başarılı, birinde başarısız olabilir. Bu, olasılıksal bir sistemi test etmenin doğasıdır ve raporlamayı da değiştirir: "şu zafiyet var" yerine "şu saldırı sınıfı, şu koşullarda, şu başarı oranıyla çalışıyor" dersiniz.

İkinci fark yamanın anlamıdır. Klasik açığı kod düzeltmesiyle kapatırsınız. Bir LLM davranışını ise sistem promptu sertleştirmesi, girdi/çıktı filtreleri, korkuluklar (guardrails) veya modelin ince ayarıyla "zayıflatırsınız" — nadiren tamamen ortadan kaldırırsınız. Bu yüzden AI red teaming tek seferlik bir denetim değil, model her güncellendiğinde tekrarlanan sürekli bir döngüdür.

AI Red Teaming'in Saldırı Yüzeyi: LLM, RAG ve Agent

Modern bir yapay zekâ ürünü tek bir "model" değildir; birbirine bağlı katmanlardan oluşur ve her katman kendi saldırı yüzeyini ekler. Red team, bu yüzeyleri ayrı ayrı ele almak zorundadır.

1. LLM katmanı — doğrudan prompt yüzeyi

En temel yüzey, kullanıcının modele doğrudan gönderdiği prompttur. Buradaki başlıca saldırı sınıfı prompt injection: modeli, geliştiricinin sistem talimatlarını yok sayıp saldırganın talimatlarını izlemeye ikna etmek. Jailbreak (rol yapma, hipotetik senaryo, kademeli eskalasyon), sistem promptu sızdırma ve çıktı manipülasyonu bu katmanda yaşar.

2. RAG katmanı — dolaylı enjeksiyon yüzeyi

Model harici bir bilgi tabanından (vektör veritabanı, doküman deposu) içerik çekiyorsa, saldırgan promptu doğrudan yazmak zorunda değildir. Zararlı talimatı modelin okuyacağı bir dokümana, web sayfasına veya kayıda gömer — buna dolaylı prompt injection denir. RAG güvenliği, bilgi tabanının bütünlüğünü, kaynak izolasyonunu ve çekilen içeriğin güvenilir talimat gibi işlenmemesini kapsar.

3. Agent katmanı — eylem yüzeyi

Sistem araç çağırabiliyorsa (e-posta gönderme, kod çalıştırma, API tetikleme, ödeme başlatma), risk katlanır. Bir chatbot'a yapılan injection yanlış bir cümle üretirken, bir agent'a yapılan injection gerçek ve geri alınamaz eylemler doğurabilir. Aşırı yetki (excessive agency), araç zehirleme, bellek zehirleme ve ajanlar arası (A2A) manipülasyon bu katmanın vektörleridir.

Özet: Aynı ürün üç ayrı red team odağı gerektirir — prompt yüzeyi (LLM), veri yüzeyi (RAG) ve eylem yüzeyi (agent). Sadece chatbot'a "kötü şeyler yazmayı" denemek, modern bir yapay zekâ sisteminin saldırı yüzeyinin yalnızca üçte birini kapsar.

AI Red Teaming Metodolojisi Nasıl Çalışır?

Olgun bir AI red teaming çalışması gelişigüzel "modeli kandırmaya çalışmak" değildir; tanınan çerçeveler üzerine oturur. Bu çerçeveler hem kapsamı garantiler hem de bulguları ortak bir dille raporlamayı sağlar.

OWASP LLM Top 10 (2025) — zafiyet sınıflandırması

OWASP LLM Top 10, LLM uygulamalarındaki en kritik zafiyet kategorilerini standartlaştırır ve red team'in test kapsamını tanımlamak için doğal bir kontrol listesidir:

KodZafiyetRed team odağı
LLM01Prompt InjectionDoğrudan/dolaylı talimat ele geçirme
LLM02Hassas Bilgi İfşasıPII, sistem sırrı, eğitim verisi sızıntısı
LLM03Tedarik ZinciriZehirli model/adaptör/veri kaynağı
LLM04Veri ve Model ZehirlemeEğitim/ince ayar verisi manipülasyonu
LLM05Hatalı Çıktı İşlemeÇıktının XSS/SQLi olarak akması
LLM06Aşırı YetkiAgent'ın izin sınırını aşması
LLM07Sistem Promptu SızıntısıGizli talimat/kural ifşası
LLM08Vektör/Embedding ZafiyetleriRAG kaynak zehirleme, embedding tersine çevirme
LLM09Yanlış BilgiHalüsinasyon ve güven manipülasyonu
LLM10Sınırsız TüketimKaynak tüketimi, model çalınması, DoS

MITRE ATLAS — saldırgan taktik ve teknikleri

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems), klasik güvenlikteki MITRE ATT&CK'in yapay zekâ karşılığıdır. Keşif, kaynak geliştirme, ilk erişim, model erişimi, çalıştırma, savunma atlatma, keşif, sızdırma ve etki gibi taktikleri; her taktik altında somut teknikleri kataloglar. Red team, saldırı zincirini ATLAS teknik kimlikleriyle haritalayarak "ne denedik, hangi taktik altında, sonuç ne oldu" izini bırakır — bu, bulguların savunma ekibiyle ortak bir dilde konuşulmasını sağlar.

NIST AI RMF ve AI 600-1 — yönetişim çerçevesi

NIST AI Risk Management Framework (Govern-Map-Measure-Manage döngüsü) ve üretken yapay zekâya özel NIST AI 600-1 profili, red teaming'i bir yönetişim faaliyeti olarak konumlandırır. Burada red team çıktısı, "Measure" (ölç) fonksiyonuna girdi sağlar: tespit edilen riskler ölçülür, önceliklendirilir ve "Manage" (yönet) aşamasında azaltılır. Bu, tek atışlık bir teknik test yerine sürekli bir risk yönetimi çevrimi kurar.

Pratik yaklaşım: OWASP LLM Top 10 neyi test edeceğinizi (zafiyet sınıfları), MITRE ATLAS nasıl saldıracağınızı (taktik/teknik), NIST AI RMF ise bulguları ne yapacağınızı (yönetişim) tanımlar. Üçü birlikte, savunulabilir ve tekrarlanabilir bir metodoloji oluşturur.

AI Red Teaming Araçları: PyRIT, garak ve Otomasyon

İnsan uzmanın yaratıcılığı yeri doldurulamaz olsa da, kapsamı ve tekrarlanabilirliği ölçeklemek için otomasyon iskeletleri kullanılır. Bu araçlar, yüzlerce saldırı probunu farklı varyasyonlarla model üzerinde çalıştırıp sonuçları puanlar.

AraçNe yaparYaklaşım
Microsoft PyRITOtomatik red teaming iskeleti; saldırı üretimi, çok turlu orkestrasyon ve puanlamaProgramlanabilir, LLM-destekli saldırgan
garakLLM zafiyet tarayıcısı; jailbreak, sızıntı, toksisite, enjeksiyon problarıProb kütüphanesi + dedektör
Giskard / promptfooTest paketi ve regresyon; güncellemelerde davranış kayması yakalamaDeğerlendirme odaklı
OWASP GenAI kaynaklarıKılavuz, tehdit matrisi ve test rehberleriMetodolojik referans

Otomasyonun kritik sınırı şudur: bu araçların prob kütüphaneleri ağırlıklı olarak İngilizcedir ve küresel modellere göre kalibredir. Türkçe bir dağıtımı yalnızca varsayılan garak/PyRIT probularıyla taramak, dilsel ve yerel saldırı yüzeyini büyük ölçüde ıskalar. Bu noktada iki katman birleşir: otomasyon geniş ama sığ kapsamı verir; insan red team ise Türkçeye özgü, bağlama duyarlı ve yaratıcı saldırıları üretir. Olgun bir çalışma ikisini de içerir.

AltaySec'in araştırma tarafında yürüttüğü Türkçe LLM injection veri seti ve AltayDuel agent arenası da tam olarak bu boşluğu — İngilizce prob kütüphanelerinin göremediği Türkçe saldırı kalıplarını — sistematik biçimde toplamak için kuruldu.

Türkçe ve Yerel Bağlam Neden Kritik?

Bu, Türkiye'de faaliyet gösteren kurumlar için AI red teaming'in en çok atlanan boyutudur. Küresel güvenlik tedarikçilerinin filtreleri ve test araçları İngilizce için tasarlanır; Türkçe onlar için "sonradan eklenen bir dil" olarak kalır. Bu boşluk üç eksende somutlaşır:

1. Dilsel eksen — morfoloji ve kod-karışımı

Türkçe sondan eklemeli bir dildir; tek bir kök, ekler yığılarak onlarca biçime bürünür. Anahtar kelime tabanlı bir güvenlik filtresi "şifre" kelimesini yakalarken "şifrelerimizi", "şifreleyerek" veya araya harf/boşluk sokulmuş varyasyonları kaçırabilir. Ayrıca Türkçe-İngilizce kod karışımı (aynı cümlede iki dil), İngilizce merkezli filtrelerin kör noktasıdır. Red team, bu morfolojik ve kod-karışımı varyasyonları bilinçli olarak üretmelidir.

2. Kültürel eksen — bağlama gömülü manipülasyon

Otorite dili, aciliyet, nezaket üzerinden kademeli eskalasyon gibi sosyal manipülasyon kalıpları kültüre göre değişir. Türkçe bir kurumsal asistanı "müdür bey acil istedi" çerçevesiyle ikna etmek, İngilizce prob kütüphanelerinde bulunmayan yerel bir vektördür. Bu kalıplar ancak dili ve kültürü bilen bir ekip tarafından üretilebilir.

3. Yasal eksen — KVKK ve yerel PII

Yerel veri koruma yükümlülükleri saldırı hedeflerini doğrudan belirler. TC kimlik numarası, IBAN, VKN gibi Türk PII biçimleri İngilizce PII dedektörlerinin (SSN formatı gibi) yakalamadığı kalıplardır. Dahası, KVKK Madde 6 özel nitelikli veriler (sağlık, dini inanç, cinsel hayat, biyometrik) çoğu yabancı filtrenin tanımadığı ayrı bir kategoridir. Türkiye'de bir red team çalışması, bu yerel PII ve özel nitelikli veri sızıntı vektörlerini ayrıca hedeflemek zorundadır.

Sonuç: İngilizce test paketiyle "temiz" çıkan bir model, Türkçe morfolojik varyasyonlar, kültürel manipülasyon ve KVKK-özgü PII karşısında hâlâ savunmasız olabilir. Yerel bağlam, isteğe bağlı bir ekleme değil, kapsamın zorunlu parçasıdır.

AI Red Teaming Süreç Adımları Nelerdir?

Yapılandırılmış bir çalışma tipik olarak altı aşamadan geçer. Bu adımlar, klasik pentest yaşam döngüsünü yapay zekânın olasılıksal doğasına uyarlar.

  1. Kapsam ve tehdit modelleme: Hangi sistem test edilecek (LLM/RAG/agent)? Hangi araçlara erişimi var? En değerli varlık ne — PII mi, sistem promptu mu, eylem yetkisi mi? Kırmızı çizgiler (üretimde çalıştırma, gerçek veri) ve kurallar belirlenir.
  2. Zafiyet haritalama: OWASP LLM Top 10 sınıfları kapsama alınır, MITRE ATLAS taktikleri hedeflenir; ürüne özel saldırı senaryoları tasarlanır.
  3. Otomatik tarama (geniş katman): garak/PyRIT ile yüzlerce prob çalıştırılır; hızlı, tekrarlanabilir bir taban ölçüm alınır.
  4. Manuel çekişmeli test (derin katman): İnsan uzman, otomasyonun bulduğu zayıf noktaları derinleştirir; çok turlu eskalasyon, Türkçe morfolojik bypass ve bağlama özel manipülasyon uygular.
  5. Doğrulama ve puanlama: Olasılıksal doğa nedeniyle her bulgu tekrar edilerek başarı oranı ölçülür; şiddet, olasılık ve etkiye göre önceliklendirilir. Algoritmik doğrulama (ör. sızan bir TC/IBAN'ın gerçekten geçerli olup olmadığı) yanlış pozitifleri eler.
  6. Raporlama ve yeniden test: Bulgular OWASP/ATLAS diline eşlenir, azaltım önerileri (sistem promptu sertleştirme, girdi/çıktı korkulukları, insan onayı) verilir; azaltım sonrası yeniden test edilir. Model her güncellendiğinde döngü tekrarlanır.

Beşinci ve altıncı adımlar, AI red teaming'i klasik testten en çok ayıran yerdir: tek atışlık bir "geçti/kaldı" yerine, sürekli ölçülen ve azaltım sonrası doğrulanan bir risk çevrimi. Çalışma zamanında sürekli izleme sağlayan korkuluk (guardrail) katmanları, red team bulgularını üretimde canlı bir savunmaya dönüştürmenin yoludur.

AI Red Teaming Kimler İçin Gerekli? (7545 / EU AI Act)

Kısa cevap: müşteriye ya da çalışana dönük herhangi bir LLM/RAG/agent çalıştıran her kurum. Uzun cevap, regülasyonun bunu giderek bir uyum gerekliliğine dönüştürmesiyle ilgilidir.

  • Bankacılık ve sigorta: Müşteri chatbot'ları ve poliçe asistanları KVKK ve finansal düzenleme kapsamındaki verilerle çalışır; sızıntı ve yetki aşımı doğrudan yaptırım riskidir.
  • Sağlık: KVKK Madde 6 özel nitelikli sağlık verisi en yüksek koruma sınıfındadır; hasta asistanı ve triyaj botları çekişmeli test olmadan üretime alınmamalıdır.
  • Kamu ve savunma: Vatandaşa dönük yapay zekâ hizmetleri hem veri hassasiyeti hem de manipülasyon/dezenformasyon riski taşır.
  • E-ticaret ve telekom: Yüksek hacimli, otomatik agent akışları aşırı yetki ve dolaylı enjeksiyona açıktır.

Düzenleyici çerçeve tarafında iki gelişme yönü belirleyici. EU AI Act, yüksek riskli yapay zekâ sistemleri için risk yönetimi, sağlamlık testi ve çekişmeli değerlendirme yükümlülükleri getirir; AB pazarına dokunan Türk kurumları da bu kapsama girer. Türkiye tarafında ise TBMM gündemine gelen Yapay Zekâ Kanunu düzenleme çalışmaları (kamuoyunda 7545 sayılı teklif olarak anılan girişim dahil) benzer bir yönde ilerliyor; buna KVKK'nin mevcut yükümlülükleri ve NIST AI RMF gibi gönüllü çerçevelerin yaygınlaşması ekleniyor. Eğilim nettir: çekişmeli test, "iyi olurdu" statüsünden "belgelenmesi beklenen" statüsüne geçiyor.

Bu noktada bir kurumun iki tamamlayıcı ihtiyacı olur: üretime çıkmadan önce sistemi kıran bir LLM pentest / red team çalışması ve üretimde canlı savunma sağlayan bir korkuluk katmanı. Red teaming zafiyetleri bulur; korkuluk katmanı bulunan sınıfları çalışma zamanında engeller. İkisi aynı madalyonun iki yüzüdür.

Sık Sorulan Sorular

AI red teaming ile jailbreak aynı şey mi?

Hayır. Jailbreak, modelin güvenlik kurallarını atlatan tek bir saldırı tekniğidir. AI red teaming ise jailbreak dahil onlarca saldırı sınıfını (veri sızıntısı, dolaylı enjeksiyon, aşırı yetki, model çalınması) yapılandırılmış bir metodolojiyle test eden kapsayıcı disiplindir. Jailbreak, red team'in kullandığı tekniklerden yalnızca biridir.

Sadece otomatik araçlarla (garak, PyRIT) red teaming yeterli mi?

Yeterli değildir. Otomatik araçlar geniş ama sığ bir taban kapsama verir ve prob kütüphaneleri ağırlıklı İngilizcedir. Çok turlu eskalasyon, bağlama özel sosyal manipülasyon ve Türkçe morfolojik bypass gibi vektörler insan uzman gerektirir. Olgun bir çalışma otomasyon ve manuel testi birleştirir.

AI red teaming ne sıklıkla yapılmalı?

Klasik yıllık pentest ritmi LLM'ler için yetersizdir. Model, sistem promptu, RAG bilgi tabanı veya araç seti her güncellendiğinde davranış değişebilir. Bu yüzden red teaming, sürüm bazlı ve süreklilik esasıyla — ideal olarak çalışma zamanı izlemeyle desteklenerek — yürütülmelidir.

Türkçe bir modeli İngilizce test paketiyle sınamak neden yetmez?

İngilizce prob kütüphaneleri Türkçenin sondan eklemeli morfolojisini, kod-karışımı kalıplarını, kültürel manipülasyon çerçevelerini ve KVKK/TC kimlik gibi yerel PII biçimlerini kapsamaz. İngilizce testte "temiz" çıkan bir model, Türkçe saldırı yüzeyinde hâlâ savunmasız olabilir.

Sonuç

AI red teaming, yapay zekâ ürünlerinin klasik güvenlik testinin dokunmadığı katmanını — modelin kendi davranışını — gerçek bir saldırgan gibi sınayan ayrı bir disiplindir. Deterministik değil olasılıksal, tek atışlık değil sürekli, ve İngilizce şablonlarla değil yerel bağlamla yürütülmesi gereken bir çalışmadır. OWASP LLM Top 10 kapsamı, MITRE ATLAS taktik dilini, NIST AI RMF yönetişim çevrimini ve PyRIT/garak otomasyonunu birleştiren yapılandırılmış bir yaklaşım, "modeli kandırmaya çalışmak"tan çok daha savunulabilir sonuçlar üretir.

Türkiye'de faaliyet gösteren kurumlar için asıl mesaj yereldir: Türkçe morfoloji, kültürel manipülasyon ve KVKK-özgü PII, kapsamın zorunlu parçalarıdır. EU AI Act ve gündemdeki yapay zekâ düzenlemeleriyle birlikte çekişmeli test, iyi bir uygulama olmaktan belgelenmesi beklenen bir yükümlülüğe evriliyor. AltaySec olarak bu alanda hem araştırma (Türkçe injection veri seti, AltayDuel arenası) hem de saha tarafında — LLM red team çalışmaları ve üretimde Guardian korkuluk katmanı ile — Türkçe bağlamı merkeze alan yerli bir yaklaşım geliştiriyoruz.

Sistemini kırmadan üretime alma. Bir LLM chatbot, RAG asistanı veya agent üretiminizi Türkçe bağlamda çekişmeli olarak test ettirmek, ardından bulunan sınıfları çalışma zamanında engellemek istiyorsanız: AltaySec hizmetlerini inceleyin veya Guardian korkuluk katmanına göz atın. Kurum bazlı değerlendirme için: [email protected].

Bu yazıya atıf:

Yurtsevenler, F. E. (2026). AI Red Teaming Nedir?
Yapay Zekâ Red Team Türkiye Rehberi. AltaySec.
https://altaysec.com.tr/arastirmalar/ai-red-teaming-nedir.html