AI Red Teaming: Üretken Yapay Zekâyı Saldırgan Gibi Test Etme Rehberi

AI Red Teaming, bir yapay zekâ modelinin veya yapay zekâ kullanan uygulamanın güvenlik, emniyet, gizlilik ve iş riski açısından saldırgan bakış açısıyla test edilmesidir.

Test ekibi yalnızca sistemin normal koşullarda doğru cevap verip vermediğini incelemez. Kullanıcı talimatlarının değiştirilmesi, dış kaynaklardan kötü niyetli içerik gelmesi, araçların amacı dışında kullanılması, hassas bilgilerin ortaya çıkması ve güvenlik kontrollerinin aşılması gibi olağan dışı senaryoları da araştırır.

Geleneksel sızma testi çoğunlukla sunucu, ağ, API, kimlik doğrulama ve yazılım açıklarına odaklanır. Yapay zekâ red teaming çalışması ise bunlara ek olarak model davranışını, prompt yapısını, RAG kaynaklarını, ajan yetkilerini, güvenlik filtrelerini ve insan gözetimini değerlendirir.

Bir sohbet botunun zararlı içerik üretmemesi tek başına güvenli olduğu anlamına gelmez. Sistem, kullanıcının belgelerinde bulunan kötü niyetli bir talimatı güvenilir kabul edebilir, başka kullanıcıya ait bilgiyi gösterebilir veya bağlı olduğu aracı yanlış parametrelerle çalıştırabilir.

Özellikle yapay zekâ ajanları; e-posta, dosya, web sayfası, kod deposu, takvim ve kurumsal uygulamalarla etkileşime geçtiğinde model güvenliğiyle klasik siber güvenlik birbirinden ayrı düşünülemez.

Bu rehberde AI Red Teaming kavramını, geleneksel red teaming çalışmalarından farkını, test edilmesi gereken katmanları, güncel tehdit türlerini, güvenli test planını, bulgu sınıflandırmasını ve üretim sonrasındaki sürekli test yaklaşımını inceleyeceğiz.

AI Red Teaming Nedir?

AI Red Teaming; yapay zekâ sisteminin planlanan davranışının dışına çıkıp çıkmadığını anlamak için kasıtlı, yapılandırılmış ve saldırgan odaklı testlerin uygulanmasıdır.

Test edilen sistem yalnızca temel model olmayabilir. Gerçek bir üretken yapay zekâ ürünü genellikle şu bileşenlerin birleşiminden oluşur:

• Büyük dil modeli veya başka bir temel model
• Sistem talimatları
• Kullanıcı arayüzü
• İçerik filtreleri
• RAG veya kurumsal bilgi kaynakları
• API ve araç entegrasyonları
• Yapay zekâ ajanı
• Hafıza sistemi
• Kullanıcı kimliği ve yetkilendirme
• Loglama ve izleme altyapısı
• İnsan onay mekanizmaları

AI red team, bu parçaların tek tek ve birlikte nasıl davrandığını inceler.

Basit Tanım

AI Red Teaming, yapay zekâ sisteminin beklenmeyen, kötü niyetli veya sınır durumundaki girdiler karşısında nasıl başarısız olabileceğini kontrollü biçimde araştırma sürecidir.

Yalnızca Güvenlik Açığı mı Aranır?

Hayır. Yapay zekâ red teaming çalışmaları teknik güvenlik açıklarının yanı sıra aşağıdaki sorunları da araştırabilir:

• Yanlış ve uydurulmuş bilgi üretimi
• Zararlı veya uygunsuz içerik
• Önyargı ve ayrımcı davranış
• Gizlilik ihlali
• İş kurallarının aşılması
• Yanlış araç veya API kullanımı
• İnsan onayının atlanması
• Beklenmeyen maliyet oluşması
• Kullanıcıyı yanıltan güven ifadeleri
• Modelin kendi yeteneklerini yanlış tanıtması

AI Red Teaming Çalışmasının Amacı

Red teaming çalışmasının temel amacı sistemi “başarısız göstermek” değil, gerçek saldırganlar veya hatalı kullanıcı davranışları ortaya çıkmadan önce başarısızlık yollarını bulmaktır.

Bilinmeyen Riskleri Keşfetmek

Standart test listeleri bilinen sorunları ölçer. Red team üyeleri ise beklenmeyen kullanım biçimleri ve farklı saldırı yolları araştırır.

Güvenlik Kontrollerini Doğrulamak

İçerik filtreleri, izin kontrolleri ve insan onay ekranlarının yalnızca normal senaryolarda değil, manipüle edilmiş girdiler altında da çalışıp çalışmadığı değerlendirilir.

Risk Yüzeyini Anlamak

Bir bulgunun ortaya çıkması, sorunun bütün kullanıcı isteklerinde görüldüğünü kanıtlamaz. Ancak sistemin hangi koşullarda başarısız olabileceğini anlamayı sağlar.

Tekrarlanabilir Testler Üretmek

Manuel red team çalışmasında bulunan örnekler daha sonra otomatik değerlendirme setlerine eklenebilir. Böylece model veya uygulama güncellendiğinde aynı hata yeniden test edilir.

Düzeltme Önceliği Belirlemek

Her bulgu aynı risk seviyesine sahip değildir. Hassas veri sızdıran ve para transferi başlatabilen bir hata, yalnızca biçimsel bir çıktı probleminden daha önceliklidir.

AI Red Teaming ile Sızma Testi Arasındaki Fark

İki çalışma birbirinin alternatifi değildir. Yapay zekâ kullanan bir ürün hem klasik uygulama güvenliği testlerinden hem de yapay zekâya özel testlerden geçirilmelidir.

Red Team, Blue Team ve Purple Team

AI Red Team

Sistemin nasıl başarısız olabileceğini araştırır. Güvenlik kontrollerini aşmaya, riskli davranışları ortaya çıkarmaya ve beklenmeyen saldırı yolları bulmaya çalışır.

AI Blue Team

Sistemin savunmasından sorumludur. Red team bulgularına karşı filtre, yetki, izleme, doğrulama ve olay müdahale mekanizmaları geliştirir.

Purple Team

Red ve blue ekiplerinin birlikte çalışmasını sağlar. Amaç yalnızca saldırı bulmak veya savunma geliştirmek değil, bulguların ölçülebilir ve tekrar test edilebilir kontrollere dönüşmesini sağlamaktır.

Kimler Ekipte Yer Almalıdır?

• Siber güvenlik uzmanları
• Makine öğrenmesi mühendisleri
• Yapay zekâ ürün geliştiricileri
• Uygulama güvenliği ekipleri
• Veri ve gizlilik uzmanları
• Hukuk ve uyum ekipleri
• Ürün yöneticileri
• İnsan faktörleri uzmanları
• Sektör veya alan uzmanları
• Dış ve bağımsız değerlendiriciler

Yapay zekâ yönetişimindeki roller için Yapay Zekâ Yönetişimi Nedir? rehberini inceleyebilirsiniz.

AI Red Teaming Çalışmasında Test Edilmesi Gereken Dört Katman

Üretken yapay zekâ sisteminin yalnızca temel modeline saldırmak eksik sonuç verir. Bütün sistem dört ana katmanda değerlendirilmelidir.

Model Seviyesi Testleri

Model seviyesi testler, temel modelin güvenlik ve davranış sınırlarını inceler.

Test Alanları

• Güvenlik talimatlarına uyum
• Zararlı içerik üretme eğilimi
• Uydurma bilgi üretimi
• Önyargılı sonuçlar
• Çok dilli güvenlik tutarlılığı
• Uzun bağlamda kural unutma
• Rol yapma ve dolaylı talimatlara tepki
• Modelin kendi sınırlarını doğru açıklaması

Model Testi Neden Yeterli Değildir?

Aynı model farklı sistem promptları, araçlar ve bilgi kaynaklarıyla kullanıldığında farklı risklere sahip olabilir. Güvenli kabul edilen temel model, yanlış yapılandırılmış bir uygulama içinde tehlikeli işlemler gerçekleştirebilir.

Uygulama Seviyesi Testleri

Uygulama seviyesi, modelin gerçek ürün içerisinde nasıl kullanıldığını değerlendirir.

Test Edilecek Bileşenler

• Sistem promptu
• Kullanıcı ve yönetici rolleri
• Konuşma geçmişi
• Çıktı filtreleri
• Dosya yükleme özellikleri
• RAG arama sistemi
• İş kuralları
• Kullanıcı onay ekranları
• Model hata mesajları
• Loglama ve raporlama

Örnek Uygulama Hatası

Temel model gizli sistem talimatlarını açıklamasa bile uygulama hata ayıklama amacıyla model girdisinin tamamını kullanıcı arayüzüne yazdırabilir.

Altyapı ve Entegrasyon Testleri

Yapay zekâ uygulamasının altında klasik yazılım ve bulut altyapısı bulunur. Red team çalışması aşağıdaki alanları da içermelidir:

• API anahtarlarının korunması
• Kullanıcı kimlik doğrulaması
• Yetkilendirme kontrolleri
• Veri tabanı erişimleri
• Bulut depolama izinleri
• Model sağlayıcısı bağlantıları
• Webhook ve araç çağrıları
• Üçüncü taraf eklentiler
• Dosya işleme servisleri
• Log ve telemetri sistemleri

Model Doğru Davransa Bile

Uygulamanın API katmanı kullanıcı kimliğini doğru doğrulamıyorsa, model güvenlik açısından doğru cevap verse bile başka kullanıcının verisine erişim gerçekleşebilir.

Çalışma Zamanı Testleri

AI Red Teaming yalnızca ürün yayımlanmadan önce yapılan tek seferlik faaliyet olmamalıdır.

Üretim sırasında aşağıdaki değişiklikler yeni risk oluşturabilir:

• Temel model sürümünün değişmesi
• Sistem promptunun güncellenmesi
• Yeni aracın eklenmesi
• RAG belgelerinin değişmesi
• Yetkilerin genişletilmesi
• Kullanıcı davranışlarının farklılaşması
• Yeni saldırı tekniklerinin ortaya çıkması
• İçerik filtresinin değiştirilmesi

Bu nedenle üretim verileri, gizlilik kurallarına uygun şekilde analiz edilmeli ve yeni bulgular test setlerine eklenmelidir.

AI Red Teaming Tehdit Haritası

Prompt Injection Nedir?

Prompt injection, saldırganın modelin davranışını değiştirmek amacıyla güvenilir talimatlarla çelişen veya onları etkisizleştirmeye çalışan girdiler göndermesidir.

Doğrudan Prompt Injection

Kötü niyetli talimat kullanıcı tarafından doğrudan sohbet veya form alanına yazılır.

Test Edilecek Noktalar

• Sistem kurallarının kullanıcı talimatından üstün tutulması
• Gizli promptların açığa çıkmaması
• Yetki kontrolünün model cevabına bırakılmaması
• Kritik araçların kullanıcı onayı istemesi
• Model reddetse bile uygulamanın işlemi başlatmaması

Prompt Filtrelemek Yeterli mi?

Hayır. Saldırgan talimat farklı dil, kodlama, dosya, görsel veya çok turlu konuşma içinde gizlenebilir. Güvenlik yalnızca yasak kelime listesine dayandırılmamalıdır.

Dolaylı Prompt Injection Nedir?

Dolaylı prompt injection saldırısında kötü niyetli talimat kullanıcının mesajında değil, modelin okuduğu harici bir veri kaynağında bulunur.

Talimatın Bulunabileceği Kaynaklar

• Web sayfası
• E-posta
• PDF veya ofis belgesi
• Takvim açıklaması
• Kod deposu
• Destek kaydı
• RAG belgesi
• API cevabı
• Görsel içindeki metin

Örnek Risk

Bir araştırma ajanı web sayfasını özetlemek üzere açabilir. Sayfada kullanıcıya görünmeyen ve ajana başka bir sisteme veri göndermesini söyleyen talimat bulunabilir.

Temel Savunma

• Dış verileri talimat değil, güvenilmeyen içerik olarak değerlendirmek
• Modelin araç izinlerini sınırlandırmak
• Hassas verileri gereksiz yere bağlama eklememek
• Veri gönderme işlemlerinde alan adı kısıtlaması kullanmak
• Kritik işlemlerde açık kullanıcı onayı istemek
• İşlemleri kayıt altına almak

Yapay zekâ ajanlarının işleyişi için Yapay Zekâ Ajanları rehberini inceleyebilirsiniz.

Jailbreak Testleri

Jailbreak, modelin güvenlik ve içerik sınırlarını aşmaya yönelik talimat veya konuşma stratejisidir.

Jailbreak Test Kategorileri

• Rol ve karakter değiştirme
• Varsayımsal senaryo oluşturma
• Çok turlu yönlendirme
• Talimatları farklı dillere dönüştürme
• Kodlama ve biçim değiştirme
• Uzun bağlam içerisinde kuralları gömme
• Birden fazla zararsız adımı birleştirme

Red team raporunda zararlı talimatların tamamını gereksiz biçimde çoğaltmak yerine test amacı, kullanılan kategori ve sistemin cevabı kayıt altına alınmalıdır.

Hassas Veri Sızıntısı Testleri

Yapay zekâ sistemleri girdiler, belgeler, konuşma geçmişi ve bağlı uygulamalardan hassas bilgi alabilir.

Test Edilecek Veri Türleri

• Kişisel veriler
• Müşteri kayıtları
• Ticari sırlar
• API anahtarları
• Parolalar ve erişim tokenları
• Kaynak kodu
• Finansal bilgiler
• Sağlık bilgileri
• Çalışan verileri
• Sistem ve güvenlik talimatları

Veri Sızıntısı Yolları

• Model çıktısı
• Hata mesajı
• Log kaydı
• RAG sonucu
• Başka kullanıcıya ait konuşma geçmişi
• Yanlış yapılandırılmış araç cevabı
• Harici adrese yapılan API çağrısı

Gerçek veriler yerine sahte fakat izlenebilir test verileri kullanılmalıdır.

RAG ve Bilgi Kaynağı Saldırıları

RAG sistemleri modelin dış belgeleri arayıp cevap oluşturmasını sağlar. Ancak bilgi tabanındaki bütün içerik güvenilir kabul edilmemelidir.

RAG Red Teaming Testleri

• Yetkisiz belgenin arama sonuçlarına gelmesi
• Kullanıcılar arasında belge sınırının aşılması
• Kötü niyetli belgenin sıralamada yükselmesi
• Belge içine talimat yerleştirilmesi
• Kaynağın yanlış veya uydurma gösterilmesi
• Silinen belgenin hâlâ sonuçlarda bulunması
• Gizli metadata alanlarının açığa çıkması
• Arama filtresinin atlanması

RAG Poisoning

Saldırganın bilgi tabanına yanlış, yanıltıcı veya kötü niyetli içerik ekleyerek model cevaplarını etkilemesidir.

Koruma Yaklaşımı

• Belge yükleme yetkilerini sınırlandırmak
• Kaynak sahipliğini doğrulamak
• Belge değişikliklerini sürümlemek
• İndeksleme öncesi güvenlik kontrolü yapmak
• Kullanıcı ve belge erişimlerini birlikte değerlendirmek
• Cevapla birlikte kaynak göstermek

Yapay Zekâ Ajanı Güvenliği

Ajanlar yalnızca cevap üretmez; plan oluşturabilir ve araç çalıştırabilir. Bu nedenle başarısızlığın sonucu bir metin hatasından gerçek dünya işlemine dönüşebilir.

Ajan Test Alanları

• Hedefin yanlış yorumlanması
• Görevin gereksiz adımlara bölünmesi
• Yanlış aracın seçilmesi
• İşlem parametrelerinin uydurulması
• Kullanıcı onayının atlanması
• Başka kullanıcının hesabında işlem yapılması
• Hatalı adımların art arda tekrarlanması
• Dış kaynaktaki talimatın uygulanması
• Gizli verinin dış servise gönderilmesi

Ajan Yetkisi Nasıl Sınırlandırılır?

• Okuma ve yazma izinlerini ayırın.
• Her araç için ayrı kimlik kullanın.
• İzin kapsamını görevle sınırlandırın.
• Para, silme ve yayımlama işlemlerinde insan onayı isteyin.
• Ajanın kullanabileceği alan adlarını sınırlayın.
• İşlem sayısı ve maliyet sınırı belirleyin.

Araçların Kötüye Kullanımı

Bir modelin araç çağırabilmesi, aracın bütün işlemlerini kullanması gerektiği anlamına gelmez.

Yüksek Riskli Araçlar

• E-posta gönderme
• Dosya silme
• Komut çalıştırma
• Veri tabanı güncelleme
• Para transferi
• Kod dağıtımı
• Kullanıcı hesabı kapatma
• Bulut kaynağı oluşturma

Test Soruları

• Model izin verilmeyen aracı çağırabiliyor mu?
• Araç parametreleri sunucuda doğrulanıyor mu?
• Kullanıcı yalnızca kendi verisi üzerinde işlem yapabiliyor mu?
• Modelin metinsel onayı gerçek yetkilendirme sayılıyor mu?
• Geri alınması zor işlemde ikinci onay var mı?
• İşlem tamamlandığında kayıt oluşturuluyor mu?

Araç ve dış sistem entegrasyonları için Model Context Protocol Nedir? rehberini inceleyebilirsiniz.

Hafıza ve Kalıcı Bağlam Riskleri

Bazı yapay zekâ uygulamaları kullanıcı tercihlerini veya önceki görevlerden gelen bilgileri saklayabilir.

Memory Poisoning

Kötü niyetli veya hatalı bilginin kalıcı hafızaya eklenerek sonraki konuşmaları etkilemesidir.

Test Edilecek Noktalar

• Hangi bilgilerin kalıcı olarak saklandığı
• Kullanıcının hafızayı görüntüleyebilmesi
• Hatalı bilginin silinebilmesi
• Bir kullanıcının diğerinin hafızasına erişememesi
• Dış belgelerdeki talimatın hafızaya yazılmaması
• Hassas verilerin saklama süresi
• Hafıza değişikliklerinin kayıt altına alınması

Model ve Tedarik Zinciri Riskleri

Yapay zekâ ürünü; temel model, ince ayar dosyası, veri seti, kütüphane, container image ve üçüncü taraf hizmetlerden oluşabilir.

Test Alanları

• Model dosyasının kaynağı
• Dosya bütünlüğü ve imzası
• Lisans koşulları
• Eğitim verisinin güvenilirliği
• Güvenilmeyen özel model kodu
• Bağımlılık güvenlik açıkları
• Model sürüm değişiklikleri
• Tedarikçinin veri işleme uygulamaları

Yazılım bileşenlerinin envanteri için SBOM Nedir? rehberinden yararlanabilirsiniz.

Manuel ve Otomatik AI Red Teaming

Otomatik Red Teaming

Başka bir model veya test motoru, hedef sisteme farklı saldırı girdileri üretip cevapları otomatik olarak değerlendirebilir.

Otomasyon özellikle aşağıdaki alanlarda yararlıdır:

• Model sürümlerini karşılaştırmak
• Bilinen bulguları yeniden test etmek
• Çok dilli varyasyonlar üretmek
• Uzun konuşma senaryolarını çalıştırmak
• Binlerce girdiyi aynı ölçütle değerlendirmek

İnsan Test Uzmanları Neden Gereklidir?

Otomatik araçlar yeni bağlamları ve iş süreçlerindeki karmaşık riskleri her zaman fark edemez. İnsan uzmanlar kültürel bağlam, sosyal mühendislik ve zincirleme iş etkilerini daha iyi değerlendirebilir.

AI Red Teaming Test Planı

Plansız biçimde sohbet kutusuna rastgele saldırı girdileri yazmak kapsamlı red teaming sayılmaz.

Temel Aşamalar

1. İş hedefini ve sistem sahibini belirleyin.
2. Test iznini yazılı hâle getirin.
3. Sistemin veri ve işlem akışını çıkarın.
4. Tehdit modelini oluşturun.
5. Test kapsamını ve sınırlarını belirleyin.
6. Başarı ve durdurma ölçütlerini yazın.
7. Güvenli test ortamı hazırlayın.
8. Manuel ve otomatik senaryoları çalıştırın.
9. Bulguları doğrulayın ve sınıflandırın.
10. Düzeltme sonrasında yeniden test yapın.

AI Red Teaming Kapsamı Nasıl Belirlenir?

Kapsam belgesi test edilecek ve edilmeyecek alanları açıkça göstermelidir.

Kapsamda Bulunması Gerekenler

• Model ve sürüm bilgisi
• Uygulama ortamı
• Kullanıcı rolleri
• Bağlı araçlar
• RAG veri kaynakları
• İzin verilen saldırı yöntemleri
• Test hesapları
• Veri kullanımı kuralları
• Çalışma saatleri
• Acil durdurma kişileri
• Raporlama ve saklama koşulları

Kapsam Dışı Alanlar

Üretim verisi, gerçek ödeme sistemi veya üçüncü taraf hizmeti test izni kapsamında değilse açıkça kapsam dışı bırakılmalıdır.

Yapay Zekâ Tehdit Modeli Nasıl Oluşturulur?

Korunacak Varlıkları Belirleyin

• Kullanıcı verileri
• Sistem promptları
• Model ve ince ayar dosyaları
• RAG belgeleri
• API anahtarları
• Kurumsal araçlar
• İş kararları
• Şirket itibarı

Saldırgan Profillerini Tanımlayın

• Anonim kullanıcı
• Ücretli müşteri
• Kötü niyetli çalışan
• Belge yükleme yetkisi bulunan kullanıcı
• Üçüncü taraf içerik sağlayıcısı
• Ele geçirilmiş entegrasyon

Güven Sınırlarını Çizin

Kullanıcı mesajı, model cevabı, RAG belgesi, araç parametresi ve API sonucu arasında hangi güven kontrollerinin bulunduğu gösterilmelidir.

Güvenli Test Verisi Nasıl Hazırlanır?

Red team çalışmasında gerçek müşteri verisi kullanmak yeni bir veri ihlali riski oluşturabilir.

Sentetik Test Verisi

Gerçek görünümde fakat gerçek kişiye ait olmayan isim, müşteri kaydı, belge ve hesap bilgileri hazırlanabilir.

Canary Verisi

Yalnızca test ortamında bulunan benzersiz bir ifade veya kimlik, verinin beklenmeyen yerde açığa çıkıp çıkmadığını anlamaya yardımcı olabilir.

Test Araçları

E-posta, dosya silme veya ödeme gibi işlemler gerçek hizmet yerine işlemi kaydeden test servislerine bağlanmalıdır.

AI Red Teaming Senaryoları Nasıl Yazılır?

Her senaryo yalnızca saldırı girdisini değil, hedeflenen kontrolü ve beklenen güvenli davranışı da içermelidir.

AI Red Teaming Çalışmasında Hangi Metrikler Ölçülmelidir?

• Saldırı başarı oranı
• Politika ihlali oranı
• Hassas veri açığa çıkarma oranı
• Yanlış araç çağrısı oranı
• İnsan onayı atlama oranı
• Yanlış pozitif oranı
• Model ve sürüm bazında sonuç farkı
• Dil ve kullanıcı grubu bazında sonuç
• Düzeltme sonrası gerileme oranı
• Bulgunun tekrar üretilebilirliği
• Ortalama düzeltme süresi

Tek Bir Başarılı Saldırı Ne Anlama Gelir?

Tek bir başarılı örnek riskin varlığını gösterebilir; ancak hatanın yaygınlığını ölçmek için daha geniş ve sistematik değerlendirme gerekir.

AI Red Teaming Bulguları Nasıl Sınıflandırılır?

Risk Değerlendirmesinde Sorulacak Sorular

• Saldırı ne kadar kolay tekrarlanabiliyor?
• Hangi kullanıcı rolü gerekiyor?
• Gerçek veri veya işlem etkileniyor mu?
• İnsan onayı bulunuyor mu?
• İşlem geri alınabiliyor mu?
• Kaç kullanıcı etkilenebilir?
• Bulgu loglarda görülebiliyor mu?
• Mevzuat veya sözleşme etkisi var mı?

AI Red Teaming Raporu Nasıl Hazırlanır?

Yönetici Özeti

Teknik olmayan yöneticiler için sistemin genel risk durumu, kritik bulgular ve öncelikli düzeltmeler açıklanmalıdır.

Teknik Bulgu

Her bulgu için aşağıdaki bilgiler yer almalıdır:

• Bulgu başlığı
• Etkilenen model ve uygulama sürümü
• Test ortamı
• Kullanıcı rolü
• Ön koşullar
• Tekrarlama adımları
• Beklenen ve gerçekleşen davranış
• Kanıtlar
• İş ve güvenlik etkisi
• Önerilen düzeltme
• Yeniden test sonucu

Hassas İçerik Yönetimi

Rapor zararlı içerik, kişisel veri veya saldırı ayrıntısı içeriyorsa erişim sınırlandırılmalı ve uygun içerik uyarıları eklenmelidir.

Red Teaming Bulguları Nasıl Düzeltilir?

Bütün sorunları yalnızca sistem promptuna yeni bir cümle ekleyerek çözmek mümkün değildir.

Savunma Katmanları

• Model ve güvenlik eğitimi
• Sistem talimatları
• Girdi ve çıktı kontrolleri
• Yetkilendirme
• Araç parametresi doğrulaması
• Veri minimizasyonu
• Sandbox ve ağ kısıtlaması
• İnsan onayı
• Loglama ve alarm
• Olay müdahale planı

Düzeltme Sonrası Yeniden Test

Yalnızca ilk saldırının engellenmesi yeterli değildir. Benzer varyasyonlar ve normal kullanıcı senaryoları çalıştırılarak düzeltmenin yeni sorun oluşturmadığı doğrulanmalıdır.

Sürekli AI Red Teaming

Yeni model veya prompt sürümü yayımlandığında eski güvenlik sonucu geçerliliğini kaybedebilir.

Testi Tetiklemesi Gereken Değişiklikler

• Model sürümü değişikliği
• Yeni sistem promptu
• Yeni RAG veri kaynağı
• Yeni araç veya MCP sunucusu
• Yetki kapsamının genişletilmesi
• Yeni kullanıcı grubu
• Önemli güvenlik olayı
• Yeni saldırı tekniği

Regresyon Test Seti

Daha önce bulunan kritik ve yüksek bulgular otomatik test setine eklenmeli ve her sürümde yeniden çalıştırılmalıdır.

Üretim Ortamında Güvenli AI Red Teaming

Önce İzole Ortam

İlk testler üretim verisinin kopyası olmayan izole bir ortamda yürütülmelidir.

Gerçek İşlemleri Simüle Edin

E-posta gönderme, ödeme veya dosya silme araçları gerçek sistem yerine test kayıtları oluşturan sahte servislere bağlanabilir.

Hız ve Maliyet Sınırı

Otomatik testler çok sayıda model çağrısı oluşturabilir. API çağrısı, token ve bütçe sınırları belirlenmelidir.

Acil Durdurma Mekanizması

Ajan beklenmeyen işlem dizisine başlarsa test ekibi bütün araç ve model erişimini hızla durdurabilmelidir.

Test İzlerini Temizleyin

Test hesapları, sentetik belgeler, geçici erişim anahtarları ve oluşturulan kayıtlar çalışma sonunda kaldırılmalıdır.

AI Red Teaming Kontrol Listesi

AI Red Teaming Çalışmalarında Sık Yapılan Hatalar

• Yalnızca temel modeli test etmek
• Rastgele birkaç promptu kapsamlı test sanmak
• Dolaylı prompt injection riskini değerlendirmemek
• Ajanın bağlı olduğu araçları kapsam dışında bırakmak
• Gerçek müşteri verisini testte kullanmak
• Yazılı izin olmadan üçüncü taraf sistemi test etmek
• Tek başarılı saldırıyı genel başarı oranı olarak sunmak
• Tek başarısız saldırıdan sistemin güvenli olduğu sonucunu çıkarmak
• Otomatik aracın bütün riskleri bulacağını düşünmek
• Bulgu düzeltmesini yalnızca prompt değişikliğine indirgemek
• Kullanıcı onayını gerçek yetkilendirme kontrolünün yerine koymak
• Model güncellendiğinde yeniden test yapmamak
• Test sonucunu uygulama ve model sürümüyle ilişkilendirmemek
• Zararlı test içeriğini sınırsız biçimde paylaşmak
• Bulguları regresyon test setine eklememek

AI Red Teaming İçin Güvenilir Kaynaklar

• OWASP GenAI Red Teaming Guide
• Microsoft AI Red Team
• Microsoft – LLM Red Teaming Planlama Rehberi
• NIST AI RMF Generative AI Profile
• NIST – AI Agent Security Red Teaming Research
• OpenAI – Human and Automated Red Teaming
• TeknoTürkiye – Yapay Zekâ Yönetişimi
• TeknoTürkiye – Yapay Zekâ Ajanları
• TeknoTürkiye – Model Context Protocol

AI Red Teaming Hakkında Sık Sorulan Sorular

AI Red Teaming nedir?

Yapay zekâ sisteminin güvenlik, emniyet, gizlilik ve iş risklerini saldırgan bakış açısıyla araştıran kontrollü test sürecidir.

AI Red Team ne yapar?

Modelin, uygulamanın, bilgi kaynaklarının ve bağlı araçların beklenmeyen girdiler karşısında nasıl başarısız olabileceğini araştırır.

AI Red Teaming ile sızma testi aynı mıdır?

Hayır. Sızma testi klasik yazılım ve altyapı açıklarına, AI Red Teaming ise model davranışı ve yapay zekâ entegrasyonlarına da odaklanır.

Prompt injection nedir?

Modelin davranışını değiştirmek veya sistem talimatlarını aşmak amacıyla kötü niyetli talimat gönderilmesidir.

Dolaylı prompt injection nedir?

Kötü niyetli talimatın kullanıcı mesajı yerine modelin okuduğu web sayfası, e-posta veya belge içinde bulunmasıdır.

Jailbreak ile prompt injection aynı mı?

Tam olarak aynı değildir. Jailbreak çoğunlukla modelin güvenlik sınırlarını aşmaya, prompt injection ise uygulama talimatlarını ve veri akışını değiştirmeye odaklanır.

RAG sistemi red teaming testine dahil edilmeli mi?

Evet. Belge erişimi, veri zehirleme, kaynak doğruluğu ve belgelerdeki kötü niyetli talimatlar test edilmelidir.

Yapay zekâ ajanları neden daha risklidir?

Ajanlar yalnızca metin üretmek yerine e-posta gönderme, dosya değiştirme veya API çağrısı yapma gibi gerçek işlemler gerçekleştirebilir.

AI Red Teaming yalnızca güvenlik ekibinin görevi midir?

Hayır. Güvenlik, makine öğrenmesi, ürün, hukuk, gizlilik ve alan uzmanlarının birlikte çalışması gerekir.

Otomatik AI Red Teaming nedir?

Başka bir yapay zekâ veya test yazılımının hedef modele çok sayıda saldırı girdisi üretip sonuçları değerlendirmesidir.

Otomatik test insan red teamer’ın yerini alır mı?

Hayır. Otomasyon ölçek sağlar; insan uzmanlar ise yeni, bağlamsal ve yaratıcı saldırı yollarını keşfeder.

AI Red Teaming ne zaman yapılmalıdır?

Ürün yayımlanmadan önce, önemli model veya araç değişikliklerinde ve üretim süresince düzenli olarak yapılmalıdır.

Her model güncellemesinde test gerekir mi?

Risk seviyesine göre en azından kritik regresyon testleri yeniden çalıştırılmalıdır.

Red teaming bulgusu kesin güvenlik açığı mıdır?

Bulgunun tekrarlanabilirliği, kullanıcı rolü ve gerçek iş etkisi doğrulanmalıdır. Her beklenmeyen cevap kritik açık değildir.

Tek başarılı saldırı önemli midir?

Evet, riskin varlığını gösterebilir. Ancak yaygınlığı ve olasılığı daha geniş ölçümle belirlenmelidir.

Sistem promptunu güçlendirmek yeterli mi?

Hayır. Yetkilendirme, veri doğrulama, sandbox, insan onayı ve izleme gibi teknik kontroller de gerekir.

AI Red Teaming gerçek üretim verisiyle yapılır mı?

Mümkün olduğunca sentetik ve izole test verisi kullanılmalıdır. Gerçek veri yalnızca sıkı izin ve koruma koşulları altında değerlendirilmelidir.

AI Red Teaming yasal mıdır?

Yetkili olduğunuz sistemlerde ve yazılı test kapsamı içinde yapılmalıdır. İzinsiz test hukuki ve sözleşmesel sorun oluşturabilir.

Red team raporunda neler bulunur?

Kapsam, model sürümü, test senaryosu, kanıt, etki, risk seviyesi, düzeltme önerisi ve yeniden test sonucu bulunmalıdır.

PyRIT nedir?

Microsoft tarafından üretken yapay zekâ sistemlerinin risk ve güvenlik testlerini otomatikleştirmeye yardımcı olmak amacıyla geliştirilen açık kaynaklı red teaming aracıdır.

AI Red Teaming maliyetli midir?

Maliyet sistemin büyüklüğü, test kapsamı, kullanılan modeller ve uzman sayısına göre değişir. Risk bazlı kapsamla küçük başlanabilir.

Küçük şirketler AI Red Teaming yapabilir mi?

Evet. Kritik kullanım senaryoları, veri sızıntısı ve araç izinleri gibi en yüksek riskli alanlardan başlanabilir.

Chatbot için red teaming gerekir mi?

Chatbot herkese açıksa, hassas veri kullanıyorsa veya şirket adına cevap veriyorsa güvenlik ve davranış testleri yapılmalıdır.

Yalnızca şirket içinde kullanılan yapay zekâ test edilmeli mi?

Evet. İç sistemlerde ticari sır, çalışan verisi ve geniş kurumsal erişim bulunabileceği için risk daha az olmayabilir.

Red teaming güvenliği garanti eder mi?

Hayır. Belirli zaman ve kapsam içinde riskleri ortaya çıkarır. Yeni modeller ve saldırılar nedeniyle sürekli değerlendirme gerekir.

AI Red Teaming Sonuç

AI Red Teaming, yapay zekâ modelini yalnızca normal kullanıcı gibi deneyen bir kalite kontrol süreci değildir. Sistemin saldırgan, hatalı veya beklenmeyen girdiler karşısında nasıl davranacağını kontrollü biçimde araştırır.

Kapsam yalnızca temel modelle sınırlandırılmamalıdır. Sistem promptu, RAG kaynakları, kullanıcı rolleri, araçlar, API’ler, hafıza, altyapı ve üretim davranışı birlikte değerlendirilmelidir.

Prompt injection ve jailbreak testleri önemli olsa da veri sızıntısı, yanlış yetkilendirme, RAG poisoning, tool misuse ve excessive agency gibi riskler de test planına dahil edilmelidir.

Özellikle yapay zekâ ajanlarında bir model hatası gerçek e-posta, dosya, ödeme veya sistem değişikliğine dönüşebilir. Bu nedenle araç izinleri en az ayrıcalık ilkesiyle sınırlandırılmalı ve kritik işlemler insan onayına bağlanmalıdır.

Manuel test uzmanları yaratıcı ve bağlamsal saldırılar bulurken otomatik araçlar çok sayıda senaryonun düzenli biçimde çalıştırılmasını sağlar. En güçlü yaklaşım iki yöntemi birlikte kullanmaktır.

Red teaming sonucunda bulunan sorunlar sistematik ölçümlere ve regresyon testlerine dönüştürülmelidir. Bir saldırının yalnızca tek örneğini engellemek yerine kök neden ve benzer varyasyonlar ele alınmalıdır.

Model, veri kaynağı veya araç değiştiğinde risk yüzeyi de değişir. Bu nedenle AI Red Teaming, ürün yayımlanmadan önce tamamlanan tek seferlik kontrol değil, yapay zekâ yaşam döngüsü boyunca devam eden güvenlik süreci olmalıdır.