Bir LLM Firewall'ın İçi: Hibrit Mimari Anatomisi
Regex + ML katmanları, gecikme bütçesi ve fail-open/fail-closed kararı

LLM Firewall Mimarisi Nedir?

Bir LLM firewall, uygulama ile dil modeli arasında konumlanan ve hem gelen istemi (prompt) hem de modelin ürettiği yanıtı denetleyen bir ters proxy katmanıdır. Ağ güvenlik duvarının paket başlıklarına baktığı yerde LLM firewall metnin anlamına bakar: prompt injection, sistem promptu sızdırma, jailbreak kalıpları, kişisel veri sızıntısı ve zararlı içerik üretimini yakalamayı hedefler. Mimari olarak tek bir bileşen değil, sıralı çalışan bir katman zinciridir: ucuz ve deterministik kontroller (regex, sözcük listeleri, sezgisel kurallar) önce; pahalı ve olasılıksal kontroller (ML sınıflandırıcı) yalnızca gerektiğinde devreye girer.

Bu katmanlı (staged) tasarım tesadüf değil, ekonomik bir zorunluluktur. Üretim sistemlerinde tespit adımlarının çoğu birkaç milisaniye mertebesinde tutulmak zorundadır; bir istemin milyonda birini yakalamak için her isteğe 1,1 GB'lık bir modeli koşturmak ne gecikme ne de maliyet açısından savunulabilir. Dolayısıyla iyi bir LLM firewall, ne zaman ucuz kalıp eşleştirmenin yeteceğini ve ne zaman ML'e tırmanmak (escalate) gerektiğini bilen bir yönlendirme mantığı üzerine kuruludur.

Temel kavramlar için LLM firewall nedir ve AI firewall seçim rehberi yazılarımıza bakabilirsiniz; bu makale ise kutunun içini açar.

Altı Katmanlı İstek/Yanıt Hattı

Referans mimarimizde bir istek, LLM'e ulaşana ve yanıt kullanıcıya dönene kadar altı denetim katmanından geçer. İlk üçü isteği (ingress), son üçü yanıtı (egress) denetler:

1. Normalizasyon: Unicode denkleştirme, Türkçe'ye özgü büyük/küçük harf katlaması (i/İ, ı/I), boşluk ve görünmez karakter temizliği. Obfüskasyon saldırılarının çoğu burada nötralize edilir.
2. Regex / kural motoru (ingress): Bilinen injection kalıpları, komut sızdırma ifadeleri ve kara liste eşleştirmesi. Deterministik ve mikrosaniye-milisaniye mertebesinde.
3. ML sınıflandırıcı (koşullu): Yalnızca üst katmanlar bir şüphe sinyali ürettiğinde ya da politika onu zorunlu kıldığında devreye alınır. Ağır katman budur.
4. Yanıt kalıp denetimi (egress): Model çıktısında sistem promptu izleri, canary token'lar ve şablon sızıntısı taraması.
5. PII / gizlilik maskeleme: Yanıttaki kişisel veri kalıplarının (TCKN, e-posta, telefon vb.) maskelenmesi. Ayrıntı için KVKK PII maskeleme yazımıza bakın.
6. Karar ve günlükleme: Katmanların verdiği sinyaller birleştirilir, izin/blok/maskeleme kararı verilir ve olay gizlilik-korumalı biçimde kaydedilir.

Bu katmanların çoğu deterministik ve hızlıdır; hattın gerçek gecikme riski neredeyse tamamen 3. katmanda, yani ML sınıflandırıcıda toplanır. İç referans sürümümüz Guardian v3.1.0, bu hattı 114 otomatik testle doğrular.

Regex Katmanı: Ucuz İlk Savunma ve ML'i Tetikleme

Regex/kural katmanı, hibrit mimarinin iş yükü dağıtıcısıdır. İki görevi vardır: (1) bilinen, yüksek kesinlikli saldırı kalıplarını tek başına yakalayıp bloklamak; (2) emin olamadığı gri bölgeleri işaretleyip ML katmanına tırmandırmak. İyi ayarlanmış bir kural setinde isteklerin büyük çoğunluğu ya net temizdir ya da net kötüdür; ML'e devredilen yalnızca aradaki belirsiz azınlıktır. Bu, gecikme bütçesini ayakta tutan tek mekanizmadır.

Türkçe bağlamında bu katman ekstra yük taşır. Morfolojik türetme, ekleme ve harf katlaması, İngilizce için yazılmış kalıpları kolayca atlatabilir; AltaySec'in kendi ölçümlerinde (AltayDuel veri seti ve guardrail-arena denemeleri) Türkçe'ye özel varyasyonların İngilizce odaklı filtrelerde belirgin kaçış oranları ürettiğini gözlemledik. Bu yüzden normalizasyon ve kural katmanı, Türkçe'ye özgü kalıplarla ayrıca sertleştirilir. İlgili saldırı kalıpları için Türkçe morfolojik LLM bypass yazımıza bakabilirsiniz.

Kritik tasarım ilkesi: regex katmanı asla tek başına yeterli sayılmamalıdır. Kalıp eşleştirme, daha önce görülmemiş semantik saldırıları (örneğin nezaket eskalasyonu ya da rol yapma senaryoları) kaçırır. Bu yüzden mimari, kalıbı değil amacı yakalaması gereken durumlar için ML katmanına bir tırmanma yolu bırakır.

ML Katmanı ve "Varsayılan Kapalı" Kararı

Hibrit mimarinin en çok yanlış anlaşılan tarafı ML sınıflandırıcının varsayılan olarak kapalı tutulmasıdır. Bu bir yetersizlik değil, bilinçli bir kaynak kararıdır. Referans dağıtımımızda ML modeli yaklaşık 1,1 GB bellek gerektirir ve firewall'ın koştuğu ortam paylaşımlı bir sunucudur. Modeli her istekte, her deploymentta zorunlu tutmak, aynı donanımı paylaşan diğer servisleri bellek baskısı altında bırakır ve gecikmeyi öngörülemez kılar.

Bu yüzden karar mantığı şudur: ML, her isteğin değil, kural katmanının şüphelendiği ya da politikanın yüksek riskli işaretlediği isteklerin katmanıdır. Bu üç faydayı birden verir:

• Bellek: Model yalnızca gerektiğinde yüklenir/çalıştırılır; taban maliyet düşük kalır.
• Gecikme: İsteklerin çoğu ağır katmana hiç uğramadan mikro-milisaniye mertebesinde sonuçlanır.
• Dağıtılabilirlik: Firewall, 1,1 GB'lık modeli zorunlu kılmadan mütevazı donanımda da çalışabilir; ML bir yükseltme olarak açılır.

Başka bir deyişle hibrit mimari, ML'i "her zaman açık" bir vergi olmaktan çıkarıp "gerektiğinde çağrılan" bir uzman haline getirir. Çalışma zamanı guardrail tasarımının bütününe dair çalışma zamanı LLM guardrail'leri yazımız bu kararı daha geniş bağlama oturtur.

Gecikme Bütçesi: P95'i Nasıl Bölersiniz

Bir LLM firewall'ının varlık sebebi güvenliktir, ama pratikte kabul görmesini belirleyen şey gecikmedir. Gerçek sistemlerde tespit hattı için tipik bir hedef, uçtan uca P95 ~200 ms mertebesinde bir bütçedir; çok katmanlı adaptörler dikkatli tasarlandığında ortalama katkı birkaç milisaniye seviyesinde tutulabilir. Bütçe düşüncesi şöyle işler: toplam bütçeyi katmanlara pay olarak dağıtırsınız ve hiçbir katmanın payını aşmasına izin vermezsiniz.

Deterministik katmanlar (normalizasyon, regex, yanıt kalıp denetimi, PII maskeleme) bu bütçenin küçük bir dilimini tüketir; bunlar CPU'da doğrudan çalışan, tahmin edilebilir maliyetli işlemlerdir. Bütçenin ezici çoğunluğunu potansiyel olarak tek bir katman —ML sınıflandırıcısı— tüketir. Bu yüzden gecikme mühendisliği, aslında "ML'i ne sıklıkta çağırıyoruz?" sorusunun mühendisliğidir. Kural katmanı isteklerin çoğunu ML'e uğratmadan kapattığında P95 sağlıklı kalır; kural katmanı çok gevşek olup her şeyi ML'e devrettiğinde P95 patlar.

Not: Katman bazlı milisaniye payları ortama, donanıma ve model boyutuna göre değişen iç ölçüm değerleridir; burada mimari ilkeyi veriyoruz, ortama özgü kesin rakamları değil. Pratik çıkarım nettir: gecikme bütçesini korumanın yolu ML'i hızlandırmak değil, ona daha az sıklıkla ihtiyaç duymaktır — yani regex/sezgisel katmanı iyi ayarlamaktır.

Fail-Open mu, Fail-Closed mu? Karar Matrisi

Her firewall'ın cevaplaması gereken en zor soru şudur: bir katman çöktüğünde, zaman aşımına uğradığında ya da belirsiz kaldığında ne yaparsın? İki uç vardır. Fail-open (arıza anında geçir) kullanılabilirliği önceler: firewall bir isteği değerlendiremezse isteği geçirir. Fail-closed (arıza anında blokla) güvenliği önceler: değerlendiremediği isteği reddeder. Yanlış seçim ya sessiz bir güvenlik açığı ya da bir hizmet kesintisi üretir.

Pratik cevap tek bir mod değil, katmana ve riske göre değişen bir matristir:

Kilit ilke: egress her zaman ingress'ten daha muhafazakâr olmalıdır. Bir kötü isteği yanlışlıkla geçirmek genellikle geri alınabilir; kişisel veri ya da sistem promptu içeren bir yanıtı kullanıcıya göndermek geri alınamaz. Bu yüzden yanıt katmanları belirsizlikte bloklamaya, istek katmanları ise düşük riskte geçirmeye meyilli tasarlanır.

Sınırlar ve Dürüst Çerçeve

Bu yazıda anlattığımız hat, AltaySec'in iç referans mimarisidir (Guardian v3.1.0, 114 test) ve rakamlar iç ölçümlerdir; her ortama genellenebilir mutlak değerler olarak okunmamalıdır. Amacımız bir ürün vaadi vermek değil, satıcı kutu-diyagramlarının Türkçe'de nadiren açtığı mimari kararları — katman sırası, ML'in koşulluluğu, gecikme bütçesi ve fail-open/closed matrisi — dürüst biçimde görünür kılmaktır.

Hibrit regex+ML mimarisinin de sınırları vardır. Regex katmanı yeni semantik saldırıları kaçırır; ML katmanı Türkçe gibi düşük kaynaklı dillerde İngilizce eğitimli modellerin taşıdığı kör noktalardan etkilenir; ve hiçbir firewall, arkasındaki uygulamanın zayıf yetki modelini telafi edemez. Firewall bir katmandır, tek savunma değil. Uygulama düzeyinde tehdit modelleme için prompt injection tehdit modeli yazımız tamamlayıcıdır.

Kendi LLM firewall katmanınızı tasarlıyor ya da mevcut kurulumunuzun gecikme/güvenlik dengesini değerlendirmek istiyorsanız, referans mimarimiz ve Türkçe saldırı veri setlerimiz üzerinden konuşmak için bizimle iletişime geçebilirsiniz.

Kaynaklar

• OWASP Top 10 for LLM Applications — LLM01: Prompt Injection
• NIST AI Risk Management Framework (AI RMF 1.0)
• MITRE ATLAS — Adversarial Threat Landscape for AI Systems (Matrices)
• Multi-Agent Firewall Architecture for Privacy Protection of Sensitive Data in Interactions with Language Models (arXiv 2607.08282)

İlgili Yazılar

• LLM Firewall Nedir?
• AI Firewall Seçim Rehberi
• Çalışma Zamanı LLM Guardrail'leri
• LLM Uygulamalarında Prompt Injection Tehdit Modeli