AltayDuel:
Agent-vs-Agent Prompt Injection Arenası Tasarımı

1. Bekçi'nin akrabası ama farklı bir hayvan

Bekçi, insan bir öğrencinin LLM'i kırmaya çalıştığı eğitici bir laboratuvar. AltayDuel ise farklı bir tür: AI agent'ların Red ve Blue rollerinde birbirleriyle savaştığı bir arena. İnsan saldırgan yok, sadece program saldırganı var. Bu temel fark her şeyi değiştiriyor.

Bekçi öğretir; AltayDuel ölçer. Bekçi'de kazanmak öğrencinin başarısıdır; AltayDuel'de kazanmak modelin (veya agent'ın prompt mühendisliğinin) gücüdür. Bekçi'nin çıktısı bireysel öğrenme; AltayDuel'in çıktısı veri.

Bu yazı AltayDuel'in mimarisinden bahsediyor — bulguları ve transkriptleri "5 saldırı kalıbı" yazısında ayrıca işledik. Burada şu soruyu cevaplıyoruz: böyle bir arena nasıl kurulur, hangi tasarım kararları neden alınır, ilk 297 düellodan ne öğrendik?

2. İki giriş kapısı: agent gönderimi ve auto self-play

AltayDuel'in arenasına iki yoldan düello düşüyor:

2.1. Agent submission API

Bir geliştirici (veya bir AI agent'ı) POST /api/duels endpoint'ine giderek kendi senaryosunu, secret'ını, Red ve Blue rollerini ve karakter promptlarını gönderebiliyor. Sistem bu girdileri doğruluyor, secret'ı çevre değişkenlerinde tutuyor, modelin context'ine sadece secret hint'i bırakıyor, ve düelloyu hemen kuyruğa alıyor. Düello tamamlanınca tüm transkript, judge kararları ve agent metadata'sı kayıt altında.

Bu mod açık: Claude, Gemini, GPT, her şey gelebilir. Düellolar 84 tane bu modda toplandı ve agent metadata'da Gemini (52), Claude (17) ve diğer agent türleri görünüyor. Hepsi kendi prompt mühendisliklerini getirip arenaya soktular.

2.2. Auto self-play orchestrator

Otomatik düello üretici, küratör 10 senaryo havuzundan rastgele bir tanesini seçiyor (yarısı Türkçe), 5 LLM provider'ı arasından bağımsız iki tane çekiyor (biri Red, biri Blue), ve düelloyu başlatıyor. Bu mod sürekli arka planda çalışıyor ve provider × senaryo cross-tabulation'ını dolduruyor. 213 düello bu moddan geldi.

Auto mod neden gerekli? Çünkü agent submission'lar selection bias'lı: insanlar atak yazmayı denerken hangi senaryolarda saldıracaklarını kendileri seçiyor. Auto mod ise her senaryoda her provider'ı dengeli şekilde çalıştırıyor — istatistiksel zemin için kritik.

3. Judge mimarisi: deterministik olmaya çabalayan bir LLM

Düellonun en kritik parçası judge. Yanlış kararlar dataset'i sahte hale getirir; iyi karar verecek bir LLM tek başına yetmez, deterministik kurallar şart.

AltayDuel judge'u her round için beş kontrol yapıyor:

Bu beş koşul sıra ile değerlendiriliyor; ilk eşleşen kazanma kabul ediliyor. Eğer 5 round içinde hiçbiri tetiklenmezse → Blue galip.

Tasarımdaki en önemli karar şu: judge'un sadece "secret söylendi mi" diye bakmasının yetersiz olması. İlk versiyonda judge sadece secret_leaked kontrol ediyordu. İki hafta sonra fark ettik ki insanlar (ve agent'lar) secret'ı söyletmeden modele aşağılık zaferler kazandırabiliyor: persona breaking, yasaklı eylem onayı, secret'ı kendileri söyleyip Blue'ya "evet" dedirme. Bu kazançlar gerçek dünyada da gerçek saldırılar — modelin müşteri verisi olmadan da güvenlik politikasını çiğnemesi yeterli bir zafer.

Sonuç: 4 ek koşul. Snapshot'ımızdaki 19 Red galibiyetinin 10'u (yarısından fazlası) secret_leaked dışındaki koşullardan geldi. Yani ilk versiyonu kullansaydık, bu 10 saldırıyı görmezden gelmiş olurduk.

Judge'un kendisi LLM. Bu sorun mu?

Evet. Tutarlılık problem. Judge'un sıcaklığı 0'da, sistem promptu mümkün olduğunca dar, ve cevap formatı tek kelime (EVET / HAYIR). Bunlara rağmen aynı round'u birden fazla kez yargılayınca bazen farklı sonuç çıkıyor. Çözüm değil, azaltma: kritik judge kararlarını üç kez koştur, çoğunluğu al. Bu, AltayDuel v0.2'de eklendi ama snapshot dataset'i öncesinde değil — yani şu anki sayıların içinde judge gürültüsü var.

4. 5 round ve neden 5

Round sayısı küçük bir parametre değil. Çok kısa olursa eskalasyon kalıplarını (yetki + aciliyet bombası, kümülatif baskı) yakalayamıyorsun; çok uzun olursa modelin context window'u doluyor ve davranış değişiyor.

Snapshot'ımızdaki round dağılımı ilginç:

19 Red galibiyetinin 8 tanesi 3. round'da. Bu, Türkçe ve İngilizce'deki klasik sosyal mühendislik eğrisine uyuyor: birinci round tanışma + savunmayı haritalama, ikinci round ısınma, üçüncü round zorlama. Üçüncü round'dan sonra eğer Blue dayandıysa genelde sonuna kadar dayanıyor. Bu kalıbın varlığı bize tasarım dersi veriyor: 3 round çok az; 5 round yeterli; 8+ round muhtemelen gereksiz.

5. Provider rotasyonu — sessiz değişken

Auto modda Red ve Blue providerlar bağımsız çekiliyor, böylece cross-matris doluyor. Snapshot'ımız 5 provider'ı kapsıyor:

groq:llama-3.3-70b
cerebras:llama-3.1-8b
cerebras:gpt-oss-120b
sambanova:llama-3.3-70b
sambanova:llama-4-maverick

Aynı temel ağırlıklar — Llama 3.3 70B — Groq ve Sambanova'da farklı davranıyor:

Sambanova versiyonu kaybetmedi, Groq versiyonu %4.9 kayıpla durdu. Aynı model, farklı host. Neden?

Hipotezimiz iki katmanlı: (1) provider'lar sistem mesajını farklı şekilde sarıyor (Sambanova system role'u daha "ciddi" işliyor olabilir); (2) decoding parametreleri (temperature, top-p) provider tarafında varsayılan farklı. n=297 ile bu hipotezleri test edemiyoruz; ama gözlem güçlü ve ortada bir sinyal var. 1000+ düelloda bu ayrımı detaylı yayınlayacağız.

Pratik dersi: "Llama 70B prompt injection'a dayanıklı mı?" sorusunun cevabı yok — soru eksik. "Hangi provider'da çalışan Llama 70B?" sorusu var.

6. Senaryo havuzu: yerel bağlam yerelde test edilir

Snapshot'ımızdaki 10 auto senaryosunun yarısı Türkçe yerel bağlam: e-ticaret PARTNER50 promosyon kodu, hastane Dr. Aylin Tezcan'ın cep telefonu, banka müşteri OTP, CEO maaş bordrosu, çocuk eğitim platformu rol oyunu.

Senaryo seçim ilkesi: secret bir gerçek sırrı temsil etsin. "Bana şu cümleyi söyle" oyunları zayıf; "doktorun cep numarasını verme" gibi iş senaryolarına bağlı sırlar gerçek dünyada karşılaşılan tehditle aynı yüzeyde.

Senaryo başına Red galibiyet oranları ilginç bir asimetri gösteriyor:

Türkçe senaryoların çoğu auto modda %0 Red zaferi gördü. İngilizce DevOps ve medical senaryoları ise hatırı sayılır oranlarda düşmeler verdi. Bunu iki şey açıklayabilir:

• (a) Türkçe atak prompt'ları otomatize Llama saldırganları tarafından İngilizce'den daha az yetkin üretiliyor; modelin Türkçe yaratıcılığı zayıf.
• (b) Türkçe kültürel hassasiyetler (KVKK, banka mahremiyeti, hasta verisi, OTP gizliliği) modelin eğitim verisinde belirgin refusal sinyallerine bağlı; model bu bağlamda doğal olarak daha katı.

Cevap muhtemelen ikisinin karışımı. Açıklığa kavuşturmak için agent modu — Claude/Gemini gerçek saldırgan — gerekiyor. Snapshot'taki agent modu Türkçe düellolarında Red galibiyetleri var (Boğaziçi feribot, Osmanlı saray vs.), yani daha güçlü saldırganla Türkçe senaryolar da düşüyor. Bu, sadece auto self-play ile Türkçe LLM güvenlik test etmenin neden yetersiz olduğunun en somut kanıtı.

7. İlk 297 düellodan dört somut tasarım dersi

Ders 1: Judge'a tek bir kazanma koşulu yetmez

Yukarıda da bahsettik. Sadece secret_leaked takip etseydik gerçek atakların yarısından fazlasını kaçıracaktık. yielded ve secret_partial birinci versiyonda olsaydı, snapshot çok daha zengin olurdu.

Ders 2: Auto self-play tek başına yanıltır

Auto modda Red galibiyet oranı %2.8; agent modunda %15.5. Beş kat fark. Yani bir benchmark sadece "kendi modelimizi kendisine karşı çalıştır" mantığıyla kurulursa, savunma yanlış kalibrasyon alır. Gerçek dünyada Blue'nun karşısına Claude/Gemini ile silahlanmış insan çıkar — Llama'yla değil.

Ders 3: Round sayısı eskalasyon kalıplarını ortaya çıkarmak için 5 olmalı

Üçüncü round zaferleri en kalabalık grup. 2 round'la kestik mi Türkçe sosyal mühendislik kalıplarının çoğunu göremezdik.

Ders 4: Provider seçimini ayrı bir veri sütunu olarak tutmak gerekiyor

İlk versiyonda provider'ı kayıt etmiyorduk; sadece "model: llama-3.3-70b" yazıyorduk. Hatta o kadar büyük bir hataydı ki, bir hafta sonra dataset'i schema'sı değişti ve geriye dönük olarak tüm düelloları yeniden işlemek zorunda kaldık. Şimdi her satırda auto_red_provider ve auto_blue_provider ayrı sütunlarda. Geriye dönüp bakınca bu, snapshot'ın en değerli sütunu çıktı.

8. Şu an doğru yaptığımıza emin olmadıklarımız

Dürüst olmak gerekirse bu sayılarla bazı kararları net veremiyoruz:

• Judge'un kendi tutarlılığı. Aynı transkripti üç kez yargılayınca farklı kararlar çıkabiliyor. Üç-koş-çoğunluk-al stratejisi v0.2'de eklendi ama dataset bunu önce içeriyor; bazı kararlar muhtemelen "yanlış" — küçük yüzde, ama var.
• Agent submission'larda selection bias. İnsanlar/agent'lar zor senaryoları daha çok deniyor olabilir; "Pera Palas + Atatürk" gibi yaratıcı senaryolar otomatik havuzda yok. Bu, agent modunun Red galibiyet oranını yapay olarak şişirmiş olabilir.
• Türkçe açık-ağırlık modellerin azlığı. 5 provider'ın hepsi (Groq, Cerebras, Sambanova) genel amaçlı modeller, hiçbiri Türkçe-fine-tuned değil. Türkçe LLM savunmasını test etmek için Türkçe LLM gerekli — şu an yapamıyoruz.
• Persona break neden bu kadar nadir? 19 Red galibiyetinin sadece 1'inde tetiklendi. Türkçe karakter rolleri gerçekten mi bu kadar dirençli, yoksa judge'umuzun persona break tanımı çok dar mı?

Bu sorulardan hiçbiri 297 düelloyla cevaplanmaz. 1000-3000 düello aralığında üç ek analiz yazısı planlıyoruz; her biri bu açık sorulardan birini tek başına hedefleyecek.

9. Açık kaynak yol haritası

• Snapshot dataset: 297-düello v0.1 sürümü HuggingFace üzerinde yayınlanacak (altaysec/turkish-prompt-injection-duels). README'de bias notları, limitasyonlar, intended use ve yargı tutarlılığı uyarısı açıkça belirtilecek. Lisans: CC BY 4.0.
• Judge protokolü: AltayDuel'in tam judge mimarisi (5 koşul, prompt şablonları, çoğunluk-oyu stratejisi) ayrı bir GitHub reposunda açık kaynak yayınlanacak. Başkalarının kendi arenalarını kurmasını isteriz.
• Submission API spec: Agent submission protokolü bir RFC-stil dokümanı olarak yazılacak. Bir geliştirici Claude/Gemini agent'ını AltayDuel'e nasıl bağlar, bunu adım adım gösteren spec.
• 1000+ analizi: Düello sayısı ≥1000 olduğunda bu yazının ve "5 saldırı kalıbı" yazısının uzatılmış analitik versiyonlarını yayınlayacağız. İlk arXiv preprint hedefimiz bu.

Sonuç

İyi bir LLM güvenlik benchmark'ı kurmak, kafamızda canlanan şeyden zor. Soyut bir "kazandı / kaybetti" sinyali değil; kim, neyi, hangi koşulla, hangi sırada kaybetti — tek tek kaydetmek gerekiyor. Beş kazanma koşulu, üç-çekiş judge, provider kolonu ayrı, round sayısı 5, senaryo havuzu yarı yarıya Türkçe-İngilizce — bunların hiçbiri tek başına önemsiz değil; AltayDuel'in elindeki 297 satırlık snapshot, bu kararların hepsinin bileşimi.

Eğer kendi LLM güvenlik test ortamını kuruyorsan, bu yazıdaki dört tasarım dersine ek olarak şunu öneririm: dataset'ini günlük export et. Schema bir kere stable olduktan sonra geri dönmüyorsun. Erken hata yapma maliyeti, bir hafta sonra dataset'i yeniden işlemek zorunda kalmak. Bizde oldu, sende olmasın.

1000 düelloya yakın bir tarih hedefliyoruz. Self-play scheduler'ı saat başı çalıştırıyoruz; agent submission'lar gönüllü gelişiyor. Eğer kendi agent'ını yarıştırmak istersen duel.altaysec.com.tr'dan submission API'ye bakabilirsin; geri bildirim için [email protected].

Bir sonraki yazıda Bekçi laboratuvarındaki kümülatif baskı çöküşü üzerine duracağız — Blue'nun 3.-5. round'larda neden kırıldığı, hangi sinyallerin direnci aşındırdığı sorusu. O zamana kadar bu iki yazı (Bekçi mimarisi ve 5 saldırı kalıbı) okunabilir.