Gelişmiş Korumalar

Genel Bakış

Apinizer AI Gateway, istek ve yanıtları aşağıdaki koruma katmanlarından geçirebilir:

• Kişisel Veri (PII) Maskeleme — kimlik numarası, IBAN, telefon gibi kişisel verilerin maskelenmesi
• İstem Koruması — jailbreak / prompt injection kalıplarının tespiti
• Veri Sızıntısı Koruması (DLP) — API anahtarı, özel anahtar, JWT gibi sırların yanıtta sızmasının engellenmesi
• Konu-Dışı Koruması — gateway'in amaçlanan konu kapsamı dışındaki isteklerin işaretlenmesi
• Tekrar-Fırtınası (Loop) Koruması — kısa sürede tekrarlanan aynı isteğin tespiti
• Aşırı Boyut Koruması — aşırı büyük isteklerin reddedilmesi
• Bağlam Bütünlüğü Koruması — sohbet geçmişine sahte rol/talimat enjekte edilmesinin engellenmesi
• Dayanaklılık (Groundedness) Koruması — LLM yanıtının, aynı istekte enjekte edilen RAG bağlamına dayanıp dayanmadığının (halüsinasyon) denetimi

Bu korumaların dördü (kişisel veri maskeleme, istem koruması, veri sızıntısı koruması ve konu-dışı koruması) ayrıca kodlanmış içeriği çözerek tarayabilir — bkz. Kodlanmış İçeriğin Çözülmesi.

Politika sırası: korumalar prompt'u kuran politikalardan sonra

İstem koruması, veri sızıntısı koruması ve bağlam bütünlüğü; Prompt Şablonu, Prompt Süsleyici ve RAG politikalarından sonra çalışmalıdır. Denetim, modele gidecek prompt'un tam hâli üzerinde yapılmalıdır; daha erken çalışan bir koruma sonradan eklenen içeriği göremez.

Kişisel veri maskeleme bu kuralın dışındadır. Maskelemenin RAG'den önce mi sonra mı çalışacağı sizin veri sınırı tercihinizdir ve Apinizer bu politikanın yerini değiştirmez. Maskelemeyi RAG'den önce koyduğunuzda kullanıcının kişisel verisi gömme (embedding) sağlayıcısına hiç ulaşmaz.

Politika listesini bu kurala aykırı bir sırayla kaydederseniz Apinizer sırayı kayıt anında otomatik olarak düzeltir ve neyi neden taşıdığını bir bilgi notuyla bildirir. Böylece Develop ekranında gördüğünüz sıra ile izleme ekranındaki gerçek çalışma sırası her zaman aynı kalır.

Kapsam: AI, MCP ve A2A Gateway'lerinde Kullanım

Yukarıdaki sekiz korumadan beşi — Kişisel Veri (PII) Maskeleme, İstem Koruması, Veri Sızıntısı Koruması (DLP), Konu-Dışı Koruması ve Tekrar-Fırtınası (Loop) Koruması — yalnızca AI Gateway proxy'lerinde değil, MCP Gateway ve A2A Gateway proxy'lerinde de eklenebilir ve çalışır:

• MCP'de taranan içerik, bir araç çağrısının argümanlarıdır (JSON-RPC params.arguments) ve araç çağrısının sonucudur.
• A2A'da taranan içerik, gönderilen görevin mesaj parçalarıdır (parts[] — hem metin hem yapılandırılmış veri).

Bu beş koruma dışındaki türler — Aşırı Boyut Koruması, Bağlam Bütünlüğü Koruması ve Dayanaklılık Koruması dahil — bir LLM çağrısına doğrudan bağlı olduğu için (token/maliyet hesaplaması, sohbet geçmişi yapısı veya RAG bağlamı) yalnızca AI Gateway'lerinde kullanılabilir. Aynı kısıtlama Semantik Önbellek, Token Kotaları ve Hız Sınırlaması, Prompt Süsleyici, Prompt Şablonları ve RAG politikaları için de geçerlidir — bu politikalardan biri bir MCP veya A2A Gateway'ine eklenmeye çalışıldığında kaydetme adımında reddedilir.

Kodlanmış İçeriğin Çözülmesi

Bir kullanıcı istemini base64, onaltılık (hex), yüzde kodlaması (%41) ya da \u0041 biçiminde göndermek, korumaların gördüğü metni değiştirir ama modelin anladığı metni değiştirmez. Modeller bu kodlamaları eğitim sırasında çözmeyi öğrendiği için yük hedefine ulaşır; desen tabanlı bir koruma ise telde yalnızca anlamsız bir karakter dizisi görür. OWASP, bu tekniği ayrı bir tehdit olarak değil, istem enjeksiyonunu (LLM01) filtreden geçiren bir taşıma yöntemi olarak sınıflandırır.

Bu nedenle Kişisel Veri Maskeleme, İstem Koruması, Veri Sızıntısı Koruması ve Konu-Dışı Koruması politikalarının her birinde Kodlanmış içeriği çöz seçeneği bulunur. Seçenek açıkken koruma, taramadan önce istemdeki kodlanmış parçaları çözer ve çözülen metni de denetler.

Varsayılan olarak kapalıdır

Seçenek kapalıyken davranış bugünkü hâliyle birebir aynıdır. Mevcut proxy'lerinizin davranışı, siz açmadıkça değişmez.

Çözülen içerik yalnızca denetlenir, değiştirilmez

Çözülen metin taranır, ama hiçbir zaman isteğin gövdesine geri yazılmaz. Bunun pratik bir sonucu var: kodlanmış içerikte kişisel veri veya sır bulunduğunda istek maskelenmez, reddedilir.

Nedeni teknik bir zorunluluk. Maskelenmiş bir değeri base64 bloğunun içine geri yazmak, çağıranın gönderdiği yükün yapısını bozar; iç içe veya kısmi kodlamalarda hangi baytın nereye denk geldiği de güvenilir biçimde eşlenemez. Geriye iki seçenek kalır: ya kodlanmış kişisel veriyi maskesiz olarak sağlayıcıya iletmek — ki bu tam olarak maskelemenin engellemek için var olduğu sızıntıdır — ya da isteği reddetmek. Apinizer ikincisini seçer.

Buna bağlı olarak Veri Sızıntısı Koruması'nda maskele aksiyonlu bir kural, çözülmüş içerikte eşleştiğinde engelle'ye yükseltilir. İşaretle aksiyonu ise olduğu gibi kalır, çünkü işaretleme zaten içeriği değiştirme iddiasında değildir.

İstem Koruması ve Konu-Dışı Koruması'nda böyle bir yükseltme yoktur: bu iki koruma zaten yalnızca tespit eder, kuralınızda ne yazıyorsa o uygulanır.

Yanlış eşleşmeye karşı

Karma (hash) değerleri, UUID'ler ve API anahtarları da base64 ya da onaltılık görünür. Bunları çözmeye kalkmak anlamsız bayt yığınları üretir ve her isteği "gizli içerik taşıyor" gibi gösterirdi. Apinizer çözülen çıktının okunabilir metin oranına bakar; eşiği geçemeyen çıktı sessizce atılır. Bu sayede SHA-256 özeti veya rastgele bir anahtar içeren normal bir istem etkilenmez.

Buna karşılık okunabilir bir JSON'a çözülen bir JWT yükü denetlenir — bu bir yanlış eşleşme değil, istenen davranıştır: içindeki kişisel veri de kapsama girer.

Sınırlar

• Sıkıştırılmış içerik (gzip, deflate) çözülmez. Bu bilinçli bir karardır: desteklenen kodlamaların hepsi çözüldüğünde küçülür, dolayısıyla üstel büyüme riski yoktur; sıkıştırma ise bu güvenceyi ortadan kaldırırdı.
• İç içe kodlama üç kata kadar çözülür; ayrıca girdi boyutu, aday parça sayısı ve toplam çözülen metin için üst sınırlar vardır. Bir sınıra ulaşıldığında tarama kısmi sonuçla sürer ve bu durum izleme kaydına işlenir — sessizce kesilmez.
• Akış (streaming) yanıtlarında parça-parça çözme yapılmaz; tamponlanarak taranan yol kapsam içindedir.
• Çözme başarısız olursa istek reddedilmez: özgün metin üzerinde yapılan tarama zaten çalışmıştır, çözme yalnızca ek bir yüzey açar. Bozuk bir base64 göndererek isteği bilerek reddettirmek mümkün değildir.

Ekrandan Açma

Dört korumanın (Kişisel Veri Maskeleme, İstem Koruması, Veri Sızıntısı Koruması, Konu-Dışı Koruması) politika ekranında bir Kodlanmış İçeriği Çöz anahtarı bulunur:

Koruma	Anahtarın bulunduğu bölüm
Kişisel Veri Maskeleme	Maskeleme Ayarları
Veri Sızıntısı Koruması (DLP)	Genel Bilgiler
İstem Koruması / Konu-Dışı Koruması	İçerik Kapsamı

Anahtarı açıp politikayı kaydetmeniz ve Dağıt'a tıklamanız yeterlidir. Aynı ayara APIops REST API (API Referansı: AI Gateway) ile ya da politika JSON'unda decodeEncodedContent alanını true yaparak da ulaşabilirsiniz.

Taranacak Mesaj Rolleri

İstem Koruması ve Konu-Dışı Koruması, sohbet geçmişindeki hangi mesaj rollerinin (system, user, assistant, tool) taranacağını/karşılaştırılacağını üç ayrı anahtarla seçmenize izin verir: sistem mesajlarını dahil et, asistan mesajlarını dahil et, araç (tool) mesajlarını dahil et.

Aynı anahtarlar, İKİ politikada TERS varsayılan

Bu üç anahtar İstem Koruması'nda ve Konu-Dışı Koruması'nda aynı isimleri taşır ama varsayılan yönleri birbirinin tersidir — bir politikadaki alışkanlıkla diğerini yapılandırmayın:

	İstem Koruması	Konu-Dışı Koruması
Varsayılan (üçü de boş/ayarlanmamış)	Hepsi taranır — bugünkü tam-tarama davranışı	Yalnızca son user mesajı karşılaştırılır — bugünkü davranış
Anahtarın anlamı	Hariç tutma anahtarı: kapatmak taramayı daraltır	Dahil etme anahtarı: açmak karşılaştırmayı genişletir
Bir anahtarı false/kapalı yapmak	O rolü taramadan çıkarır	(zaten varsayılan — etkisi yok)
Bir anahtarı true/açık yapmak	(zaten varsayılan — etkisi yok)	O rolü karşılaştırmaya ekler ve aşağıdaki mod değişimini tetikler

İstem Koruması: hariç-tutma anahtarları

İstem Koruması bugün istekteki her mesajı (rolü ne olursa olsun) tarar — bu üç anahtar taramayı daraltmak için vardır, genişletmek için değil. includeSystemPrompts alanı yalnız role: "system" mesajlarını değil, Anthropic isteklerindeki üst düzey system alanını da kapsar — ikisi aynı anahtarla yönetilir, çünkü ikisi de aynı sistem-istemini taşıyan iki farklı yüzeydir.

• Bilinmeyen/tanınmayan bir rol asla hariç tutulmaz. developer, function, sağlayıcıya özgü bir rol adı ya da hiç role alanı taşımayan bir mesaj — bu üç anahtarın etkilediği yalnız system/assistant/tool olduğu için — her zaman taranır. Bir korumanın, tanımadığı bir rol etiketi yüzünden saldırgan içeriği es geçmesi engellenir.
• Boş kalan bir tarama, ham gövdeye düşer. Rol filtresi sonrasında taranacak hiçbir içerik kalmazsa (örn. istek yalnızca system mesajı içeriyor ve includeSystemPrompts=false), koruma sessizce boş geçmez — isteğin ham gövdesini tarar. Sonuç: bu anahtarlarla tarama hiçbir zaman hiç yapılmamış hale gelmez, yalnızca hedefli biçimde daraltılır (fail-closed).

Konu-Dışı Koruması: dahil-etme anahtarları + mod değişimi

Konu-Dışı Koruması bugün yalnızca sohbetteki son user mesajını konu embedding'i ile karşılaştırır. Bu üç anahtardan herhangi biri açıldığında koruma "son mesaj" modundan "tüm konuşma" moduna geçer — karşılaştırmaya giren metin artık tek bir mesaj değil, seçtiğiniz roller dahil konuşmanın tamamıdır.

Eşiğinizi yeniden gözden geçirin

Mod değişimi yalnız kapsamı değil, embedding'e giden metnin boyutunu ve dolayısıyla benzerlik dağılımını da değiştirir — konuşmanın tamamı tek bir mesajdan daha "seyreltik" bir embedding üretir. Herhangi bir rol anahtarını açtıktan sonra mevcut Benzerlik Eşiği'nin hâlâ doğru ayrımı yaptığını doğrulayın; embedding çağrısının girdi boyutu da büyüdüğü için maliyet etkisini göz önünde bulundurun.

Kapsam: yalnız AI/OpenAI-Anthropic formatı

Bu üç anahtar yalnız OpenAI/Anthropic biçimli messages (ve İstem Koruması'nda Anthropic system) alanını okuyan AI proxy koluna uygulanır. Bir MCP Gateway veya A2A Gateway üzerindeki aynı politika, o protokollerin kendi içerik biçimini (JSON-RPC argümanları / parts[]) tarar ve bu anahtarlardan etkilenmez.

Ekrandan Açma

İstem Koruması ve Konu-Dışı Koruması'nın politika ekranında, yukarıdaki Kodlanmış İçeriği Çöz anahtarıyla aynı İçerik Kapsamı bölümünde üç ayrı anahtar bulunur: Sistem Mesajlarını Dahil Et, Asistan Mesajlarını Dahil Et, Araç (Tool) Mesajlarını Dahil Et. Aynı ayarlara APIops REST API (API Referansı: AI Gateway) ile ya da politika JSON'unda includeSystemPrompts / includeAssistantPrompts / includeToolPrompts alanları ayarlanarak da ulaşabilirsiniz.

Kişisel Veri (PII) Maskeleme

İstek ve yanıt içeriğini (akış dahil) bilinen kişisel veri kalıplarına karşı tarar.

Hazır Doğrulayıcılar

Tür	Örnek	Checksum
TC Kimlik Numarası	12345678901	Var (11. hane doğrulama)
Türkiye IBAN	TR330006100519786457841326	Var (mod97)
Türkiye telefon numarası	+905XXXXXXXXX	—
E-posta	ornek@sirket.com	—
Kredi kartı numarası	4111111111111111	Var (Luhn)
IP Adresi (IPv4/IPv6)	192.168.1.1	— (yapısal doğrulama, DNS sorgusu yapılmaz)
URL	https://ornek.com/yol	— (yalnızca http/https/ftp/ftps şeması + geçerli host kabul edilir)
Pasaport No	A1234567	Yok — basılı pasaportta check-digit bulunmaz; yüksek false-positive riski, alan adı bazlı kalıpla daraltılması önerilir
Sosyal Güvenlik No (ABD)	123-45-6789	— (ayraç zorunlu; ayraçsız 9 hane kabul edilmez, kart/telefon ile karışmasını önler)
Sürücü Belgesi No (TR)	A12345678	Yok — best-effort yapısal kalıp; Pasaport ile aynı false-positive uyarısı geçerli
IBAN (Genel, ülke-bağımsız)	DE89370400440532013000	Var (mod97) — Türkiye IBAN'dan ayrı, ISO 13616 kapsamındaki tüm ülkeleri kapsar
Kripto Cüzdan Adresi	1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa, bc1q..., 0xAbC...	Zorunlu — BTC (base58check), bech32 (segwit v0) veya ETH (EIP-55 karışık-harf) formatlarından biri geçerli checksum taşımalıdır

Checksum'u olmayan türlerde (Pasaport, Sürücü Belgesi) yalnızca yapısal bir kalıp kontrolü yapılır — bu, gerçek bir belge numarasıyla aynı şekle sahip rastgele bir metni de eşleştirebilir. Bu iki tür için taramayı belirli bir alan/header adıyla daraltmak üzere alan adı bazlı kalıp tipini kullanmanız önerilir.

Kapsam dışı bırakılanlar

Tarih, tıbbi terim ve isim/soyisim (NRP) gibi türler bilinçli olarak eklenmedi — bunlar yalnızca regex ile güvenilir biçimde ayırt edilemez (doğal dil işleme gerektirir) ve regex-only bir yaklaşım aşırı false-positive üretir.

Hazır doğrulayıcılara ek olarak, kendi özel regex veya alan adı bazlı (örn. belirli bir header/parametre adı) kalıplarınızı tanımlayabilirsiniz.

Kural Listesini Yönetme

Yeni bir PII Maskeleme politikası boş bir kural listesiyle açılır — Apinizer'ın diğer formlarındaki davranışın aynısı: yalnızca istediğiniz kuralları eklersiniz. Kural listesinin üstündeki toplu aksiyonlar:

Aksiyon	Ne yapar
Varsayılan Seti Ekle	Yukarıdaki hazır doğrulayıcıların hepsi için birer maskeleme kuralını tek tıkla ekler. Zaten tanımlı olan kurallar atlanır; butona ikinci kez basmak listeyi çoğaltmaz.
Preset'ten Ekle	PII Patterns kataloğundan seçtiğiniz kalıpları ekler. Modal başlığındaki kutuyla katalogun tamamını tek tıkla seçebilirsiniz.
Tanım Ekle	Sıfırdan tek bir kural oluşturur.
Tümünü Temizle	Listedeki tüm kuralları tek adımda kaldırır; onay ister. Yeni bir AI proxy ile birlikte otomatik gelen dolu Default PII Mask politikasını sıfırlamak için de kullanılır.

not

Kural listesindeki değişiklikler, politikayı kaydedene kadar kalıcı olmaz. Kural listesi boş bırakılan bir politika hiçbir şey maskelemez — ekranda bu durum uyarı olarak gösterilir.

bilgi

Akış (streaming) yanıtlarda: PII maskeleme, chunk sınırında bölünen bir kimlik numarasını da yakalayabilmek için bir tampon (carry) mekanizması kullanır — örn. bir kimlik numarasının ilk yarısı bir chunk'ta, ikinci yarısı sonraki chunk'ta gelse bile eşleşme kaçırılmaz.

Desen Yazma ve Deneme

Desenler Java düzenli ifade sözdizimini kullanır (java.util.regex.Pattern) — gateway eşleştirmeyi bu motorla yapar. JavaScript veya PCRE ile birebir aynı değildir: lookbehind sabit genişlik ister, adlandırılmış grup (?<ad>...) biçiminde yazılır, \p{L} gibi Unicode sınıfları desteklenir.

PII Patterns ekranındaki Deseni Dene paneli, deseni kaydetmeden önce örnek bir metin üzerinde çalıştırır. Test sunucuda, gateway ile aynı motorda koşar; dolayısıyla panelde gördüğünüz eşleşmeler ve maskelenmiş çıktı, çalışma anında olacak olanın birebir aynısıdır.

uyarı

Aşırı geri-izleme (catastrophic backtracking) üretebilen desenler çalışma anında atlanır. Gateway her deseni bir ReDoS kontrolünden geçirir; kontrolü geçemeyen desen istek işlenirken hiç uygulanmaz — kural açık görünür ama hiçbir şeyi maskelemez. Test paneli bu durumu kaydetmeden önce "ReDoS riski" olarak bildirir.

Eşleşen Değere Ne Olur

Maskeleme biçimi kural bazında seçilir:

Biçim	Girdi	Çıktı
Tamamını değiştir (varsayılan)	05321234567	***
İlk N karakteri koru (N=4)	05321234567	0532*******
Son N karakteri koru (N=4)	05321234567	*******4567
İlk N karakteri maskele (N=4)	05321234567	****1234567

Varsayılan biçim değerin tamamını *** ile değiştirir ve hiçbir şey sızdırmaz. Kısmî biçimler çıktının uzunluğunu korur ve değerin bir bölümünü bilerek açıkta bırakır; kalan parça tek başına bile kişiyi tanımlayabileceği için (örneğin telefonun son dört hanesi) bilinçli seçilmelidir. Değiştirme metni de yapılandırılabilir — kısmî biçimlerde metnin ilk karakteri maskeleme karakteri olarak kullanılır.

Korunacak karakter sayısı değerin uzunluğuna eşit ya da büyükse hiçbir şey maskelenmemiş olurdu; böyle bir durumda güvenli tarafa düşülür ve değerin tamamı değiştirilir.

Kalıcı Yer Tutucu ve Sahte Değer Modları

Yukarıdaki dört biçime ek olarak iki mod daha vardır — ikisi de eşleşen değerin hiçbir parçasını açıkta bırakmaz, ama sabit *** yerine daha kullanışlı bir çıktı üretir:

Mod	Çıktı	Örnek
Sıralı yer tutucu	Aynı istek içinde tutarlı, tip-etiketli bir yer tutucu ({TİP}_{SIRA} biçiminde, özelleştirilebilir)	12345678901 → <TCKN_1>, ikinci bir TC kimlik no eşleşmesi → <TCKN_2>
Sahte (sentetik) değer üret	Kendi doğrulayıcısından (varsa checksum dahil) geçen, uydurma ama biçimsel olarak geçerli bir değer	Gerçek bir IBAN → geçerli mod97 checksum'lı başka bir IBAN; gerçek bir kredi kartı → ayrılmış test BIN'i (4111) ile başlayan, Luhn'dan geçen bir numara

Her yeni sahte değer, bağımsız rastgele veriden üretilir — yerini aldığı orijinal değerden hiçbir zaman hesaplanmaz. Bu bilinçli bir tasarım kararıdır: HIPAA Safe Harbor, kimlik-giderme kodunun yerini aldığı veriden türetilmemiş olmasını şart koşar; GDPR Madde 4(5) ise kişiyi yeniden tanımlayabilecek ek bilginin takma addan gerçekten ayrı tutulmasını ister. Orijinal değerden hesaplanan bir sahte değer (örneğin onun hash'i) tek-yönlü görünse de, elinde aday bir değer olan biri aynı sahte değeri kendisi üreterek eşleşmeyi kontrol edip o kişinin verisinin geçip geçmediğini doğrulayabilirdi. Apinizer'ın sahte değerlerinde böyle bir bağ yoktur — sahte değerden orijinale dair hiçbir şey yeniden hesaplanamaz ya da test edilemez.

Bu iki mod için önemli davranış kuralları:

• Tutarlılık, tek istek içindir: aynı istekte aynı orijinal değer her göründüğünde aynı yer tutucuyu/sahte değeri alır (örn. bir kullanıcı mesajında geçen bir TC kimlik no ile onu tekrar eden bir sonraki mesajdaki aynı numara, aynı <TCKN_1> etiketine düşer). Farklı istekler arasında ise aynı orijinal değer farklı bir sahte değere düşer (rainbow-table saldırısına karşı koruma) — bir isteğin çıktısında görülen bir yer tutucu/sahte değer, başka bir isteğin trafiğiyle korele edilemez.
• Varsayılan olarak geri döndürme (rehydration) yoktur: orijinal değer, siz o kural için bilerek geri-döndürülebilir takma adlandırmayı açmadıkça hiçbir aşamada saklanmaz ya da geri verilmez — bkz. aşağıda Geri Döndürülebilir Takma Adlandırma (Unmask). Varsayılan ayarda Maskele veya Anonimleştir'i yalnızca sonradan geri çağırmanız gerekmeyecek veriler için seçin.
• Bellek tavanı: bir istekte üretilen benzersiz yer tutucu/sahte değer sayısı belirli bir tavanı (varsayılan 5000) aşarsa, tavanı aşan yeni değerler için sistem otomatik olarak "Tamamını değiştir" davranışına düşer — halihazırda üretilmiş eşlemeler etkilenmez.
• Araç/ajan çağrısı sonuçlarında da korunur: bir MCP aracı veya A2A ajanı çağrısının sonucu isteğe geri besleniyorsa, aynı istekteki maskeleme aynı yer tutucu/sahte değer eşlemesini kullanmaya devam eder — aynı orijinal değer, isteğin hiçbir noktasında iki farklı etiket almaz.

Geri Döndürülebilir Takma Adlandırma (Unmask)

Sıralı Yer Tutucu ve Sahte Değer modlarının her ikisi de isteğe bağlı olarak geri döndürülebilir hale getirilebilir; böylece yetkili bir operatör — bir modda ise AI proxy'nin yetkili bir çağıranı — orijinal değeri sonradan, her yanıtta kalıcı olarak açığa çıkarmadan geri çağırabilir. Bu özellik varsayılan olarak kapalıdır ve tek bir maskeleme kuralına değil, politikanın tamamına uygulanır — politika ekranındaki Yeniden Kimliklendirme (Unmask) bölümünden, ya da politika JSON'undaki unmaskMode alanından veya APIops REST API'sinden ayarlanır. Üç mod bulunur:

Mod	Davranış
None (varsayılan)	Bugünkü davranış, değişmedi — hiçbir şey saklanmaz, geri dönüş yoktur.
Otomatik (Response Inline)	Aşağıda anlatılan geri-döndürülebilir saklama devreye girer, ve yanıtta yeniden görünen her takma ad, yanıt çağırana ulaşmadan önce otomatik olarak orijinal değerine geri çevrilir — ama yalnızca rolü politikanın aşağıdaki Yetkili Çağıran Rolleri listesinde olan bir çağıran için, yalnızca akış (streaming) olmayan bir yanıtta ve sıfır-saklama profili dışında (aşağıdaki nota bakın).
Unmask API	Geri-döndürülebilir saklama devreye girer; yetkili bir Yönetim Konsolu operatörü, sonradan Management API üzerinden bir yer tutucuyu/sahte değeri orijinaline geri çözer.

Yetkili Çağıran Rolleri. Otomatik mod için burada en az bir giriş gerekir — orijinal değeri otomatik olarak geri alabilecek, ağ geçidi çağıranının rolleri (bir kimlik bilgisine tanınan aynı scope değerleri). Bu liste varsayılan olarak reddeder: Otomatik mod seçili olsa bile boş bırakılırsa kimse geri-yükleme almaz — yanıt yine yer tutucu/sahte değerle gönderilir ve politika ekranı boş liste için görünür biçimde uyarır.

Orijinal değer nerede saklanır. Orijinal değer hiçbir zaman bir günlüğe, izleme kaydına veya kalıcı bir veritabanına yazılmaz. Yalnızca dağıtık önbellekte, AES-GCM ile şifreli, isteğin izleme kimliğine (trace ID), kurala ve üretilen tam yer tutucu/sahte metne bağlı bir kayıt olarak var olur. Bu kayıt bir saat sonra sona erer — süresi dolduğunda orijinal değer, Apinizer destek ekibi dahil kimse tarafından geri getirilemez.

Otomatik geri-yükleme önce denetlenir, sonra uygulanır. Her otomatik geri-yükleme önce bir denetim kaydı yazar; yalnızca bu yazım başarılı olduğunda orijinal değer yanıta yerleştirilir. Denetim kaydının yazımı başarısız olursa geri-yükleme atlanır ve yanıt yer tutucu/sahte değerle olduğu gibi gönderilir — bir denetim kaydı olmadan hiçbir otomatik geri-yükleme gerçekleşmez.

Otomatik geri-yüklemenin çalışmadığı durumlar. Yetkisiz bir çağıran rolü dışında, otomatik geri-yükleme — Otomatik mod hiç seçilmemiş gibi, yanıt maskeli gönderilerek — şu durumlarda da atlanır: yanıt akış (streaming) halinde geliyorsa (bu sürümde desteklenmiyor) ve API proxy Standart dışında herhangi bir veri saklama profili altında çalışıyorsa — Gövde Yok ya da Kalıcı Kayıt Yok, ikisinden biri fark etmez. Her atlama, nedeniyle birlikte uygulama günlüğüne kaydedilir; bugün ekranda ayrı bir gösterge yoktur.

Bir değeri elle çözme. Yetkili bir operatör; proje kimliğini, isteğin izleme kimliğini (İzleme ve Tekrar Oynatma sayfasına bakın), kuralın kimliğini ve trafikte kaydedildiği haliyle tam yer tutucu/sahte metni vererek POST /api/ai-pii-unmask çağrısı yapar. Erişim, o proje üzerinde AI Development Manage izni gerektirir — varsayılan olarak reddedilir — ve her deneme (başarılı, reddedilmiş ya da kaydın süresi zaten dolmuş olsun) denetim kaydına yazılır. Geri çözülen değerin kendisi asla o denetim kaydına yazılmaz, yalnızca kimin, ne zaman sorduğu ve sonuç yazılır. Yukarıdaki otomatik yol ile bu elle-çözme yolu aynı denetim kaydına yazar.

Bu elle-çözme işlemi, doğrudan API çağrısı yapmak yerine Yönetim Konsolu'ndaki AI Yönetimi → PII Maskeleme Çözme ekranından, bölümlere ayrılmış ve alan açıklamalı bir arama formu üzerinden de yapılabilir; aynı yetki ve denetim kaydı kuralları geçerlidir.

Saklama profili ve geri-döndürülebilir saklama

Otomatik veya Unmask API modunu açmak, proxy'nin veri saklama profilinden bağımsız olarak geri-döndürülebilir önbellek kaydını devreye sokar — Gövde Yok ya da Kalıcı Kayıt Yok bir proxy, ters eşlemenin yazılmasını tek başına engellemez. Standart dışı bir profilin değiştirdiği şey, Otomatik modun kendi otomatik-yerleştirme adımıdır: yukarıda anlatıldığı gibi bu adım orada tamamen atlanır, dolayısıyla yanıt aksi halde yetkili olacak bir çağıran için bile maskeli gönderilir — eşleme, TTL süresi boyunca Unmask API üzerinden sonradan hâlâ geri çözülebilir durumda kalır. Kurulumunuz bilinçli olarak Gövde Yok ya da Kalıcı Kayıt Yok altında çalışıyorsa ve hiçbir türde geri-döndürülebilir saklama istemiyorsanız unmaskMode değerini None bırakın.

Maskeleme Dışındaki İşlemler ve Değeri Geri Okuma

Maskeleme dışında silme, hashleme, şifreleme ve tespit işlemleri de seçilebilir:

• Şifreleme — değer AES/GCM/NoPadding ile şifrelenir ve sonuç Base64 olarak yazılır. Anahtar Apinizer kurulumuna gömülüdür, kullanıcı tarafından verilmez; bu nedenle şifreli değer yalnız aynı Apinizer kurulumu içinde çözülebilir. Pratik yol, bir Groovy script politikasında UtilCommon.decryptWithDefaultAlgorithm(<base64değer>) çağırıp çıktıyı request_log() / response_log() ile yazdırmaktır. Dışarıdan bir araçla (openssl vb.) çözmek mümkün değildir — anahtar dışa verilmez.
• Hashleme — SHA-256 + kuruluma özel salt uygulanır ve geri döndürülemez. Aynı girdi her zaman aynı çıktıyı ürettiği için korelasyon amacıyla kullanılabilir, ama özgün değere ulaşılamaz.

Sonradan okunması gerekebilecek veriler için şifreleme, gerekmeyecekler için hashleme veya maskeleme seçin.

İstem Koruması (Jailbreak / Enjeksiyon)

İstek içeriğini bilinen jailbreak ve prompt injection kalıplarına karşı tarar. Hazır kural setine ek olarak kendi kalıplarınızı ekleyebilirsiniz; her kural kendi Engelle veya İşaretle aksiyonuyla çalışır.

Veri Sızıntısı Koruması (DLP)

İstek ve/veya yanıt gövdesini bilinen sır ve kimlik bilgisi kalıplarına karşı tarar.

Hazır Kalıplar

Kalıp	Örnek	Varsayılan Aksiyon
AWS erişim anahtarı	AKIAIOSFODNN7EXAMPLE	Engelle
OpenAI API anahtarı	sk-...	Engelle
GitHub kişisel erişim token'ı	ghp_... / gho_...	Engelle
Slack token'ı	xoxb-...	Engelle
Google API anahtarı	AIza...	Engelle
Özel anahtar / sertifika bloğu (PEM)	-----BEGIN PRIVATE KEY-----	Engelle
JWT (JSON Web Token)	eyJhbGci...	Maskele
Genel parola/sır atama kalıbı	password: ..., api_key=...	Maskele

bilgi

Kalıplar hazır şablon (preset) olarak gelir; kuruluşunuza özel ek kalıplar (regex) tanımlayabilirsiniz.

Yerleşik Kalıpların Sürümlenmesi

Yukarıdaki yerleşik kalıplar, ürün koduna sabit gömülü olmak yerine sürümlü, checksum'lı bir paket olarak gelir — aşağıda anlatılan İstem Koruması imza paketiyle aynı ilkeye dayanır, burada sır tespiti kalıplarına uygulanır. Paketin bütünlüğü, bir Apinizer sürüm yükseltmesinin parçası olarak otomatik doğrulanır: paketteki bir kalıp kayıtlı checksum'ıyla eşleşmiyorsa (paketin bozulduğu ya da üzerinde oynandığı anlamına gelir) paketin hiçbir kalıbı uygulanmaz ve bu durum sessizce geçilmek ya da yükseltmeyi durdurmak yerine uygulama günlüklerine bir uyarı olarak yazılır. Daha önce doğrulanmış bir paketten yürürlükte olan kalıplar olduğu gibi kalır.

Doğrulanmış bir paket yalnızca Apinizer'ın kendi getirdiği yerleşik kalıplara dokunur — kendi adınızla eklediğiniz özel bir kalıp, sonraki bir pakette ne değişirse değişsin asla ezilmez veya kaldırılmaz.

Yerleşik bir kalıbı düzenlemek, onu bir sonraki paket yenilemesinden korur. Yerleşik kalıplar artık salt-okunur değildir — bir admin, DLP kural ekranından (ya da APIops üzerinden) herhangi birini özel bir kalıp gibi düzenleyebilir veya silebilir. Bir kalıbı ilk düzenlediğinizde, satır arka planda "override edilmiş" olarak işaretlenir; bu andan itibaren paket doğrulaması o satırı kendi özel kalıbınız gibi değerlendirir ve daha sonraki bir Apinizer sürümü aynı kalıbı pakette değiştirse bile düzenlemenizin üzerine bir daha asla yazmaz. Yerleşik bir kalıbı silmek kalıcıdır — bir sonraki sürümde geri gelmez; yalnızca gelecekteki bir sürüm açıkça yeniden-seed changeset'i yazarsa geri döner.

Ekranda henüz sürüm göstergesi yok

İstem Koruması'nın imza paketi şeridinden (kurulu sürüm, checksum, "Güncel" rozeti) farklı olarak, Veri Sızıntısı Koruması'nın kalıp listesi bugün ekranda bir paket sürümü göstermez — doğrulama, yükseltme sırasında arka planda otomatik çalışır ve bir hata yalnızca uygulama günlüklerinde görünür.

Mevzuat Kapsaması: HIPAA ve PCI DSS

Yukarıda gösterilen az sayıdaki sır kalıbının ötesinde, yerleşik paket artık iki yaygın uyum mevzuatını hedefleyen özel kalıplar da içerir: HIPAA Safe Harbor kimlik-giderme standardının (45 CFR §164.514(b)(2)) listelediği tanımlayıcılar ve PCI DSS'in tanımladığı kart sahibi verisi ile kimlik doğrulama verisi kategorileri. Buradaki kapsama ham kalıp sayısıyla değil, mevzuat maddesiyle ölçülür — bir mevzuat maddesi birçok farklı veri biçiminin tespit edilmesini isteyebilir ve bunların bir kısmı bir düzenli ifadeyle güvenilir biçimde yakalanamaz.

HIPAA Safe Harbor — 18 tanımlayıcı

Tanımlayıcı	Kapsama
Telefon numaraları	Kalıpla yakalanır
Faks numaraları	Kalıpla yakalanır
E-posta adresleri	Kalıpla yakalanır
Sosyal güvenlik numaraları (ABD)	Kalıpla yakalanır
Tıbbi kayıt numaraları	Kalıpla yakalanır
Sağlık planı yararlanıcı numaraları	Kalıpla yakalanır
Hesap numaraları	Kalıpla yakalanır
Sertifika / lisans numaraları	Kalıpla yakalanır
Araç kimlik/seri numaraları (plaka dahil)	Kalıpla yakalanır
Cihaz kimlik/seri numaraları	Kalıpla yakalanır
Web URL'leri	Kalıpla yakalanır
IP adresleri	Kalıpla yakalanır
Ad soyad	İçerik güvenliği katmanını gerektirir — aşağıdaki nota bakın
Eyalet/il düzeyinden küçük coğrafi alt bölümler	İçerik güvenliği katmanını gerektirir
Kişiye bağlı tarihler (yıl hariç)	İçerik güvenliği katmanını gerektirir
Diğer her türlü benzersiz tanımlayıcı numara, özellik veya kod	İçerik güvenliği katmanını gerektirir (bu geniş kategorinin parola/API-anahtarı/sır biçimi, genel sır kalıbıyla zaten kapsanır)
Biyometrik tanımlayıcılar	Kapsam dışı — taranabilir metin değil
Tam yüz fotoğrafları	Kapsam dışı — taranabilir metin değil

PCI DSS — kart sahibi verisi ve hassas kimlik doğrulama verisi

Öge	Kapsama
Birincil Hesap Numarası (PAN)	Kalıpla yakalanır
Kart son kullanma tarihi	Kalıpla yakalanır
Tam manyetik şerit izi verisi (Track 1 / Track 2)	Kalıpla yakalanır
PIN / PIN bloğu	Kalıpla yakalanır
Kart doğrulama kodu (CVV / CVC / CAV2 / CID)	Kalıpla yakalanır
Kart sahibinin adı	İçerik güvenliği katmanını gerektirir
Manyetik şerit servis kodu	Kapsam dışı — herhangi bir 3 haneli sayıdan ayırt edilemez

Her şey bir regex problemi değildir

Yukarıdaki tanımlayıcıların bir kısmı — bir kişinin adı, ev adresi, doğum tarihi, kart sahibinin adı — sabit bir yapısı olmayan serbest metindir. Bir düzenli ifade "Ahmet Yılmaz"ı büyük harfle başlayan başka herhangi bir kelime çiftinden güvenilir biçimde ayıramaz; bu nedenle bu sınıftaki değerlerin tespiti kalıp-eşleştirme yerine anlamsal bir katmana aittir — bkz. aşağıdaki İçerik Güvenliği Kategorileri (AILuminate). Apinizer bu tanımlayıcıları, çoğu gerçek değeri kaçıracak ya da neredeyse her şeyi işaretleyecek bir kalıp eşleşmesi dayatmak yerine bilinçli olarak o katmana yönlendirir — bunların "regex ile kapsandığını" iddia etmek yanıltıcı olurdu.

İki Mevzuatın Ötesinde: Presidio Hizalı Ek Kapsam

Yerleşik paket, yukarıdaki iki mevzuatın dışında kalan ama genel amaçlı PII dedektörlerinin sık işaretlediği birkaç tanımlayıcı için de kalıp içerir — paketin bu kısmı Microsoft Presidio'nun tanımlayıcı kataloğuyla hizalanmıştır (MIT lisanslı; Apinizer'ın düzenli ifadeleri kendi yazımıdır, Presidio'dan birebir kopyalanmamış, atıfla uyarlanmıştır):

Tanımlayıcı	Kapsama
ABD sürücü belgesi numarası	Kalıpla yakalanır, bağlam anahtar kelimesi çapalı
ABD Bireysel Vergi Mükellefi Kimlik Numarası (ITIN)	Kalıpla yakalanır
IBAN, genel uluslararası biçim (herhangi bir ülke)	Kalıpla yakalanır
Kripto para cüzdan adresi (Bitcoin, Ethereum)	Kalıpla yakalanır

Presidio kataloğunun HIPAA ya da PCI DSS ile birlikte andığı tanımlayıcıların çoğu — sosyal güvenlik numarası, e-posta, telefon, URL, IP adresi, kart PAN'ı — zaten yukarıdaki tablolarda anlatılan aynı kurala düşer; bu tablo yalnızca Presidio'nun daha geniş kapsamına özgü tanımlayıcıları listeler.

Hâlihazırda özelleştirdiğiniz kurallar bu genişlemeden hiçbir şekilde etkilenmez. Yeni yerleşik kalıplar, yukarıda anlatılan kalıp sürümleme mekanizmasıyla, kendi tanımladığınız kalıpların yanına, yükseltme sırasında otomatik olarak eklenir.

Kalıp Sayısı Büyüdükçe Tarama Hızı Sabit Kalır

Veri Sızıntısı Koruması, kalıp listeniz büyüdükçe — ister yerleşik ister kendi eklediğiniz kalıplar olsun — tarama gecikmesi orantılı büyümesin diye tasarlanmıştır: daha pahalı kalıp kontrolleri çalışmadan önce, bir isteğe/yanıta karşı hangi kalıpların gerçekten değerlendirilmeye değer olduğunu daraltan ucuz bir dahili ön filtre çalışır. Bu tamamen dahili bir performans mekanizmasıdır — hangi kalıbın eşleştiğini, hangi aksiyonun uygulandığını ya da gördüğünüz sonucu asla değiştirmez; bugün bunun için yapılandırılacak bir ayar yoktur.

Dosya İmzası Tespiti

Yukarıdaki kalıplar metin eşleştirir. Bir istemin içine base64 ya da onaltılık (hex) olarak yapıştırılmış ikili bir dosya — bir PDF, bir Office belgesi, bir arşiv, bir çalıştırılabilir dosya — ise metin değildir: telde yalnızca anlamsız bir karakter dizisi görünür, dolayısıyla ne yerleşik bir kalıp ne de sizin yazdığınız bir kalıp onu yakalayabilir. Aranacak bir sır şekli yoktur, çünkü sızan şey dosyanın tamamıdır. "Kullanıcı sohbete bütün bir sözleşmeyi yapıştırdı" ve "model bir belgeyi geri yansıttı" durumlarının ikisi de bu yolla taşınır ve yukarıda anlatılan kalıpların hiçbiri bunu göremez.

Dosya İmzası Tespiti bu açığı, karakterlere değil baytlara bakarak kapatır. Gövdede bulduğu base64 ve hex adaylarını çözer ve her birinin baştaki baytlarını bilinen kapsayıcı biçimlerin tablosuyla — her ikili biçimin başladığı sihirli baytlarla (magic bytes) — karşılaştırır. Hiç kodlanmadan, ham olarak yapıştırılmış bir dosya da aynı şekilde tanınır.

Özellik varsayılan olarak kapalıdır ve Veri Sızıntısı Koruması politika ekranında kendi Dosya İmzası Tespiti bölümüne sahiptir. Kalıp listesinden bağımsız yapılandırılır: hiç veri sızıntısı kalıbı olmayan bir politika bile bu anahtar açıkken gerçek iş yapar; kalıp dolu bir politika ise anahtar kapalı kaldığı sürece hiçbir şekilde etkilenmez.

Tanınan biçimler

Dosya tipi	Kapsam	fileSignatureTypes değeri
PDF belgesi	.pdf	PDF
ZIP / Office	.docx, .xlsx, .pptx, .jar ve diğer ZIP kapsayıcıları	ZIP_OOXML
PNG görseli	.png	PNG
JPEG görseli	.jpg, .jpeg	JPEG
GIF görseli	.gif	GIF
GZIP arşivi	.gz	GZIP
RAR arşivi	.rar	RAR
7-Zip arşivi	.7z	SEVEN_ZIP
ELF çalıştırılabilir dosyası	Linux ikilileri ve paylaşılan kitaplıklar	ELF
PE çalıştırılabilir dosyası	Windows .exe / .dll	PE_EXE
OLE2 belgesi	Eski Office .doc, .xls, .ppt	OLE2
RTF belgesi	.rtf	RTF
Java class dosyası	Derlenmiş .class bayt kodu	JAVA_CLASS

Dosya Tipleri bir izin listesidir: on üç tipin tamamının taranması için boş bırakın. Bir biçim trafiğinizin meşru bir parçasıysa listeyi daraltın — örneğin ekran görüntüsü yapıştırılan bir asistanda PNG ve JPEG kapsam dışında bırakılabilir, belgeler, arşivler ve çalıştırılabilir dosyalar yakalanmaya devam eder.

Aksiyon: Engelle ya da İşaretle — Maskele seçeneği yoktur

Aksiyon biçim başına değil, tespitin tamamına uygulanır ve yalnız iki seçenek vardır: Engelle (varsayılan) isteği ya da yanıtı reddeder, İşaretle geçmesine izin verir ve olayı kaydeder. Maskele bilinçli olarak yoktur. Maskeleme, eşleşen bir aralığı [REDACTED] ile değiştirir; bu, bir API anahtarı gibi kısa bir sır için iyi tanımlı bir işlemdir. Bir sihirli-bayt eşleşmesinin ise böyle bir aralığı yoktur — "bu baytlar bir PDF'in başlangıcıdır" der, "400 ile 460 arasındaki karakterler sırdır" demez — dolayısıyla redakte edilecek anlamlı bir bölge yoktur ve kodlanmış bir bloğun bir parçasını yeniden yazmak yalnızca çağıranın gönderdiği yükü bozar. Bu, yukarıdaki Kodlanmış İçeriğin Çözülmesi bölümünde anlatılan, çözülmüş içerikte bir maskele kuralının engelleye yükseltilmesiyle aynı gerekçedir. APIops üzerinden fileSignatureAction alanına MASK verilmesi kayıt anında reddedilir; eski bir dışa aktarımdan gelen bir Maskele değeri ise gateway'de Engelle olarak ele alınır: bütün bir dosyanın kurumdan çıkması en az kısa bir sır kadar ciddi kabul edilir, bu yüzden varsayılan güvenli yöndür.

İmzanın nerede bulunduğu sinyalin bir parçasıdır

Bir adayın en başında bulunan imza, o adayın neredeyse kesinlikle o dosyanın kendisi olduğu anlamına gelir — bütün bir belge gönderilmiştir. Daha büyük bir bloğun içinde, ileri bir konumda bulunan imza ise daha zayıf bir sinyaldir: dosyanın baytları başka içeriğin içinde bir yerde, örneğin başka bir şeyin arkasına eklenmiş olarak geçmektedir. İkisi de raporlanır ve kaydedilen olay hangisi olduğunu belirtir; böylece raporu inceleyen kişi "bir belge yüklenmiş" ile "bir belge başka bir şeyin içine gömülmüş" durumlarını birbirinden ayırabilir.

İki yönde de çalışır

Veri Sızıntısı Koruması hem istek hem yanıt yönünü denetler; dosya imzası tespiti de onu izler: girişte istemler, dönüşte model çıktısı. Bilinçli olarak açılmaya değer olan yön yanıt yönüdür — bağlam penceresinden ya da bir araç (tool) sonucundan base64 bir belgeyi yeniden üreten bir model, tam olarak bu tespitin var oluş nedeni olan gömülü-belge sızıntısıdır ve yalnız istek tarafını tarayan bir filtrenin asla göremediği yön de budur.

Sihirli önek tek başına asla güvenilir sayılmaz

Kısa sihirli baytlar rastgele veriyle tesadüfen çakışır: Windows PE başlığı iki bayttır (MZ) ve rastgele her 65.536 bayt çiftinden yaklaşık birinde ortaya çıkar. Bu nedenle tablodaki her biçim, sihirli önekten sonraki baytlara bakan biçime özgü bir doğrulamayla eşleştirilmiştir — PE doğrulaması DOS başlığındaki göstericiyi izler ve gösterdiği baytların PE\0\0 olmasını şart koşar, PNG doğrulaması ilk parçanın gerçek bir PNG'nin bildirdiği uzunluğu bildirmesini ister, ZIP doğrulaması "gereken sürüm" ve "sıkıştırma yöntemi" alanlarının makul değerler olmasını arar. Doğrulamayı çalıştırmaya yetecek kadar uzun olmayan bir aday hiç eşleşmez. Bir istemin içindeki bir özetin (hash), bir token'ın ya da rastgele bir tanımlayıcının kaçak bir çalıştırılabilir dosya olarak raporlanmasını engelleyen şey budur.

Sınırlar ve "sessiz kesme yok" ilkesi

Tarama sınırlıdır — girdi uzunluğunda, incelenen base64/hex aday sayısında, toplam çözülen bayt miktarında ve iç içe geçme derinliğinde (base64 içine sarılmış base64 çözülür, ama zincir sonsuza kadar sürmez). Bir tavana ulaşıldığında tarama o ana kadar bulduğunu döndürür ve kesildiğini kaydeder; bu, kodlanmış içerik çözme sınırlarındaki "asla sessizce kesilmez" ilkesinin aynısıdır. Bayt taşıyıcısı olarak yalnız base64 ve hex ele alınır: yüzde kodlaması ve \uXXXX kaçışları ikili veriyi üç-altı katına şişirir ve bir dosyayı istem üzerinden kaçırmak için gerçekçi bir yol değildir. Bu kodlamalarla sarılmış bir base64 bloğuna ise yine ulaşılır, çünkü kodlanmış içerik çözmenin ürettiği metin de taranır.

Tespit için Kodlanmış İçeriği Çöz anahtarının açık olması gerekmez — base64 ve hex çözme, tespitin kendi parçasıdır. O anahtar da açıksa ikisi aynı gövde üzerinde çözme işini paylaşır, aynı metin iki kez çözülmez.

Bu ayar, akış yanıtlarında ilk-token süresini doğruluk uğruna feda eder

Dosya İmzası Tespiti açıkken bu politikanın akış (streaming) yanıtları parça parça değil, bütün olarak biriktirilip taranır — hangi aksiyonu seçmiş olursanız olun, İşaretle dahil. Kodlanmış bir dosya imzası herhangi bir parça sınırına yayılabilir: sihirli baytlar bir parçaya, onları doğrulayan baytlar bir sonrakine düşer; dolayısıyla parça-bazlı bir tarama neredeyse hiçbir şey bulamaz. Bu, Akış (Streaming) Yanıtlarda: Buffer-and-Scan bölümünde anlatılan aynı buffer-and-scan yaklaşımıdır ve pratik bedeli, bu politikanın akış yanıtlarında ilk-token süresinin (TTFT) artık korunmamasıdır. Belge sızıntısı riski taşımayan, gecikmeye duyarlı proxy'lerde anahtarı kapalı bırakın.

Eşleşme nerede görünür

Bir dosya imzası eşleşmesi, bir sır kalıbı eşleşmesinden ayrı olarak kaydedilir; böylece ikisi Güvenlik ve Guardrail'ler raporunda birbirine karışmaz: olay secret yerine file-signature olarak etiketlenir ve etiketi biçim ile konumu taşır — örneğin File signature (PDF, at_start). Birden fazla imza eşleştiyse etiket kalanların sayısını da belirtir. İzleme ve Tekrar Oynatma kaydında biçim, konum, baytların ham mı yoksa base64/hex kodlu mu geldiği ve kaç eşleşme olduğu tutulur — taranan içeriğin kendisi asla tutulmaz.

Üç alan APIops üzerinden veri sızıntısı koruması politika JSON'unda da ayarlanabilir: fileSignatureDetectionEnabled, fileSignatureAction (BLOCK ya da FLAG) ve fileSignatureTypes (yukarıdaki tablodaki değerlerden oluşan bir dizi; boş bırakılır ya da hiç verilmezse on üç tipin tamamı). Bkz. API Referansı: AI Gateway.

Aksiyonlar

• Engelle — istek/yanıt tamamen reddedilir
• İşaretle — işleme devam eder, olay günlüğe ve rapora işaretlenir
• Maskele — eşleşen değer [REDACTED] ile değiştirilir, işleme devam eder

uyarı

Akış (streaming) yanıtlarda: DLP koruması, yanıtı pencereler (chunk grupları) halinde tarar. Bir pencerede Engelle eşleşmesi bulunduğunda, akışın kalan tüm pencereleri de otomatik olarak maskelenir — bölünmüş bir sırrın pencereler arasında sızması bu şekilde önlenir.

Konu-Dışı Koruması

Gateway'in amaçlanan kullanım alanı dışındaki istekleri tespit eder — örneğin bir müşteri hizmetleri botunun genel sohbet veya alakasız konularda kullanılmasını önler.

Konu Tanımları Oluşturun

Yönetici, gateway'in kapsamındaki konuları (örn. "fatura sorguları", "ürün destek talepleri") tanımlar.

Benzerlik Karşılaştırması

Gelen her istek, tanımlı konularla anlamsal (embedding tabanlı) benzerlik açısından karşılaştırılır.

Eşik Kararı

Benzerlik eşiğin altındaysa istek konu-dışı sayılır ve yapılandırılan aksiyon uygulanır.

not

Konu-dışı koruması varsayılan olarak eşzamansız modda çalışır — istek akışını yavaşlatmadan arka planda değerlendirilir ve raporlanır; satır içi (garanti engellemeli) mod da yapılandırılabilir.

Yasaklı Konular

İzin verilen konu listesine ek olarak, bu proxy'nin asla yanıtlamaması gereken konuları da tanımlayabilirsiniz — örneğin "hukuki tavsiye" veya "rakip fiyatlandırması". Bu ikisi bağımsız çalışır: yalnız izin verilen konuları, yalnız yasaklı konuları veya ikisini birden yapılandırabilirsiniz.

Yasaklı yön her zaman önce değerlendirilir ve kazanır: gelen istek önce yasaklı konu tanımlarıyla karşılaştırılır; bir eşleşme bulunursa izin verilen konu kontrolü hiç yapılmadan doğrudan aksiyon uygulanır — istek, izin verilen bir konuya da yüksek benzerlik gösterse fark etmez. İzin verilen konu kontrolü yalnızca yasaklı yönde eşleşme olmadığında çalışır.

Yasaklı yön, izin verilen yönden bağımsız kendi eşiğini ve aksiyonunu alabilir; boş bırakılırsa izin verilen yön için ayarladığınız değerleri miras alır:

Ayar	Boş bırakılırsa
Yasaklı Benzerlik Eşiği	İzin verilen yönün Benzerlik Eşiği'ni izler
Yasaklı Konu Aksiyonu	İzin verilen yönün Aksiyonu'nu izler

Her iki liste de boşsa koruma karşılaştıracak hiçbir tanım bulamaz ve çalışma anında sessizce hiçbir şey yapmaz. Bu yüzden ekran, yerleşik (embedding tabanlı) motor açıkken en az bir konu tanımı ister: izin verilen ya da yasaklı listeden biri doluysa politikayı kaydedebilirsiniz, ikisi de boşken Kaydet düğmesi kapalı kalır. Yalnız-yasaklı kurulum meşru bir moddur ve engellenmez. Motor yalnız dış sağlayıcı olarak seçildiğinde yerleşik karşılaştırma hiç çalışmadığı için konu listesi aranmaz.

uyarı

Konu karşılaştırması için kullanılan embedding sağlayıcısına ulaşılamazsa varsayılan davranış fail-closed'dır — istek reddedilir, sağlayıcı toparlanana kadar geçirilmez. Bu davranış izin verilen ve yasaklı yön için aynıdır: doğrulanamayan bir istek, yasaklı bir konuya da uyuyor olabileceği için sessizce geçirilmez.

Akış (Streaming) Yanıtlarda: Buffer-and-Scan

Konu-Dışı Koruması bugüne kadar yalnızca gelen isteği (kullanıcının mesajını) tarıyordu. Artık akış (streaming) yanıtlarda, modelin ürettiği metin de aynı izin verilen/yasaklı konu tanımlarına karşı denetlenebilir — bir müşteri hizmetleri botunun akış modunda üretmeye başladığı bir yanıtın kendisi konu dışına kayarsa (örn. model jailbreak edilip alakasız bir konuda ayrıntılı yanıt üretmeye başlarsa) bu da tespit edilir.

Mekanizma tampon-ve-tarama (buffer-and-scan)'dır: akışın her parçası istemciye iletilmek yerine tutulur ve sessizce bir tampona eklenir; anlamsal (embedding) karşılaştırma akış bittiğinde tek seferde yapılır — parça başına embedding çağrısı yapılmaz (yüzlerce parçaya bir ağ çağrısı eklemek gecikmeyi ciddi biçimde bozardı). Yanıt tek bir karşılaştırma çalışana kadar tutulduğu için bu artık gerçek bir önleyici kontroldür: bir Engelle kararı tamponlanmış metni bütünüyle tutar ve istemci o akış için hiçbir şey almaz; eşleşme bulunmadığında ya da yalnızca bir İşaretle eşleşmesi olduğunda ise akış bittiğinde tamponlanmış metnin tamamı istemciye tek bir son parça olarak bırakılır.

Tampon yalnızca bir ENGELLE kuralı varsa açılır

Tampon yalnızca izin verilen ya da yasaklı yönlerden en az birinin aksiyonu Engelle olarak ayarlanmışsa açılır. Her iki yön de yalnızca İşaretle ise (ya da hiç konu tanımlanmamışsa), akış yanıtlarında hiçbir ek maliyet oluşmaz — hiçbir şey biriktirilmez, hiçbir tarama yapılmaz; bugünkü parça-parça streaming davranışı aynen korunur.

Bu akış hattına, Dış Sağlayıcı Guardrail bölümünde anlatılan llm-judge hakemi katılmaz — yalnızca yerleşik (embedding) karşılaştırma çalışır. Yalnız Dış Sağlayıcı motoruyla yapılandırılmış bir Konu-Dışı Koruması, akış yanıtlarında hiçbir şey taramaz (ne yerleşik ne dış) — Harici DLP Entegrasyonu bölümündeki "akışta dış servis hiç çağrılmaz" kısıtıyla aynı ilke.

Akış bitmeden önce biriken tampon 65.536 karakteri aşarsa (olağandışı uzun bir akış yanıtı), Konu-Dışı Koruması yanıtı bütün olarak taramaktan vazgeçer: o ana kadar tutulan her şey tek bir taranmamış patlama (burst) halinde istemciye bırakılır ve o noktadan sonraki her parça, yanıtın geri kalanı boyunca taranmadan canlı olarak akmaya devam eder — o akış için embedding karşılaştırması artık hiç çalışmaz ve bu durum izleme kaydına görünür biçimde işlenir. Bu kadar uzun bir yanıt zaten tek bir bütün-yanıt embedding çağrısının anlamlı biçimde sınıflandırabileceği sınırı aşmıştır; tutulan içeriği taramadan bırakmak, onu sessizce yok saymaktan daha iyi bulunmuştur. Tipik bir yanıt bu sınırın çok altında tamamlanır ve eksiksiz biriktirilip taranır.

Tampon etkinken kademeli akış yoktur — ve bir DLP tampon taramasıyla birlikte hiç çalışmaz

Engelle kurallı bir Konu-Dışı Koruması bir yanıtı tamponlarken istemci, akış bitene kadar hiçbir şey görmez: ilk-token süresi (TTFT) yoktur, yalnızca akışın sonunda tek bir parça gelir — bu parça ya yanıtın tamamını (eşleşme yok / İşaretle) ya da hiçbir şeyi (Engelle) taşır. Karar her iki durumda da izleme kaydına ve Güvenlik ve Guardrail'ler raporuna işlenir. Akış dışı (unary) yanıtlar bu bedelden etkilenmez — oradaki değerlendirme yanıt istemciye ulaşmadan önce zaten tamamlanmıştır.

Bu tampon ayrıca, aynı yanıt üzerinde Veri Sızıntısı Koruması'nın kendi tampon-ve-tarama mekanizması etkinken (orada bir Engelle ya da Maskele kuralı, ya da Dosya İmzası Tespiti etkinse) hiç açılmaz: DLP zaten parça-parça tutmayı kendi üstlenmiştir ve akışın ortasında taranmış kısmi bir öneki bırakabilir; Konu-Dışı Koruması'nın tek-seferlik bütün-yanıt sınıflandırması ise DLP'nin zaten bıraktığı içeriği geri çekemez. Aynı proxy'de ikisi birden yapılandırıldığında DLP'nin tamponu öncelik kazanır ve Konu-Dışı Koruması'nın akış taraması o yanıt için hiç çalışmaz — istek tarafındaki taraması ve akış-dışı yanıtlardaki taraması bundan etkilenmez.

İçerik Güvenliği Kategorileri (AILuminate)

Konu-Dışı Koruması'nın İzin Verilen ve Yasaklı Konuları serbest metindir — kendi konu tanımlarınızı siz yazarsınız. Özellikle içerik-güvenliği riskleri için bir başlangıç noktası olarak Apinizer, MLCommons AILuminate v1.1 taksonomisinden alınmış, 14 tehlike kategorisi içeren bir katalog sunar; kategoriler standardın kendi gruplamasıyla aynı şekilde gruplanır:

Grup	Kategoriler
Fiziksel (5)	Şiddet İçeren Suçlar, Cinsel Suçlar, Çocukların Cinsel İstismarı, İntihar ve Kendine Zarar Verme, Ayrım Gözetmeyen Silahlar (CBRNE)
Fiziksel Olmayan (5)	Fikri Mülkiyet İhlalleri, Karalama, Şiddet İçermeyen Suçlar, Nefret Söylemi, Gizlilik
Bağlamsal (4)	Uzmanlık Gerektiren Tavsiye — Seçimler, Uzmanlık Gerektiren Tavsiye — Finans, Uzmanlık Gerektiren Tavsiye — Sağlık, Cinsel İçerik — Pornografik

Katalog, Güvenlik Kuralları merkezinin İçerik Güvenliği (AILuminate) sekmesinde bulunur. Her satır kategori adını, grubunu, kısa bir tanımını ve — varsa — karşılık geldiği Llama Guard 3 güvenlik kodunu gösterir. Bu, dış hakeminiz Llama Guard ya da aynı taksonomiyle eğitilmiş bir model olduğunda işe yarar: hakemin verdiği karar bir S kodu olarak döner, bu katalog da o kodu karşılık geldiği AILuminate kategorisine geri izlemenizi sağlar. S6 ("Uzmanlık Gerektiren Tavsiye") burada hem Finans hem Sağlık kategorisini kapsar; diğer tüm kodlar birebir eşlenir.

Bu katalogdan alınan bir Yasaklı Konu eşleşmesi, Güvenlik ve Guardrail'ler raporunda AILuminate kategorisine göre kırılır — kategori başına isabet sayısı, zaman serisi ve proje/proxy dağılımı — ve her izleme kaydı eşleşen kategoriyi, benzerlik skorunu ve kararı hangi motorun verdiğini (yerleşik embedding karşılaştırması mı, llm-judge mı) taşır.

Katalog-Bağlı Bir Şablon Değildir

Bu sayfada anlatılan kişisel-veri, istem-koruması ve veri-sızıntısı koruması hazır şablonlarının aksine, bu katalogda "Şablondan Ekle" düğmesi ve katalog-bağlı kural durumu yoktur — burada bir politikanın bağlanabileceği ya da senkron dışı kalabileceği bir şey bulunmaz. Her satırın Kopyala (EN) ve — Türkçe metni tanımlıysa — Kopyala (TR) aksiyonu vardır: tıklayın, o kategorinin tanım metni panoya kopyalanır, ardından Konu-Dışı Koruması'nın Yasaklı Konular listesine kendiniz yapıştırırsınız. Politika yalnızca bir kopya tuttuğu için, buradaki bir kategoriyi düzenlemeniz onu hâlihazırda kullanan bir politikayı değiştirmez; değişen tanımı almak için yeniden kopyalayıp Yasaklı Konular'daki eski metnin yerine koyun.

Kendi Kategorinizi Ekleme

Katalog düzenlenebilir. Kategori Ekle ile kendi satırınızı oluşturursunuz; Apinizer ile birlikte gelen on dört kategori de düzenlenebilir ya da silinebilir — kurumunuza özgü bir tehlike için Apinizer sürümü beklemeniz gerekmez. Düzenleme, AI Geliştirme Yönetim yetkisi ister; admin seviyesinde tanımlı bir satır yalnızca oradan değiştirilebilir, proje içinden değil.

Kurulumla gelen bir satırı düzenlemeden önce bilmeniz gereken üç şey var:

• Hazır bir kategoriyi silmek kalıcıdır. On dört AILuminate satırı bir kez seed edilir; Mongock changeset'i id ile tekilleştirir ve hiçbir seed changeset'i runAlways=true değildir, yani bir kez koşmuş seed tekrar koşmaz. Silinen kategori sürüm yükseltmelerinde silinmiş kalır — ancak yeni bir sürümde açıkça bir yeniden-seed changeset'i yazılırsa geri gelir. Bir kategoriyi kaybetmeden kullanımdan kaldırmak istiyorsanız silmek yerine pasifleştirin.
• Hazır bir kategoriyi yeniden kelimelemek standartla bağını koparır. Tanımlar AILuminate v1.1'den alıntıdır; metni değiştirdiğinizde satır artık atıf verdiği standardın söylediğini söylemez. Kendi trafiğiniz için bunu yapmak meşrudur — yalnızca o satırı artık standardın kategorisi saymayın.
• Eklediğiniz kategorinin Llama Guard kodu olmaz. AILuminate ↔ Llama Guard eşlemesi ürünün bir parçasıdır, bu yüzden kendi kategorileriniz için alan boş kalır. Öyle bırakın: uydurulmuş bir S kodu, yukarıdaki dış hakem izini yanlış kategoriye götürür. Alan yalnızca gerçekten geçerli bir eşleme olduğunda kaydedebilmeniz için vardır.

Her satırın görünen adı, tanımı ve açıklaması için isteğe bağlı Türkçe ikizleri de vardır. Türkçe trafiğe hizmet veriyorsanız bunları doldurun — ancak Yasaklı Konular'da Türkçe tanımı İngilizcenin yerine kullanın, yanına değil. Politika isteği listedeki en yakın satıra göre puanladığı için aynı kategorinin iki ayrı kelimelenişini birlikte taşımak, meşru isteklerin yanlışlıkla engellenme oranını artırır.

GDPR Madde 9 İşareti

On dört kategoriden dördü — Nefret Söylemi, Seçimler ve Sağlık'la ilgili Uzmanlık Gerektiren Tavsiye kategorileri ve Cinsel İçerik — bir GDPR Madde 9 özel nitelikli kişisel veri kategorisine (sağlık verisi, siyasi görüş vb.) dokunduğu için işaretlenmiştir. Bu işaretin nedeni, bu kategorilerin açık uçlu, bağlamsal kavramlar olmasıdır: "bu metin birinin sağlık durumunu ifşa ediyor mu" sorusunu sabit bir düzenli ifadenin güvenilir biçimde karara bağlaması mümkün değildir; bu nedenle bu kapsam, yukarıdaki kalıp-tabanlı Kişisel Veri Maskeleme ya da Veri Sızıntısı Koruması katmanlarına değil, bu anlamsal (embedding-benzerliği) katmana aittir — o katmanlar yalnızca sabit yapısal ya da harfiyen bir kalıba uyar.

Atıf

Türkçe kategori metinleri ve dil seçimi

Her kategori, İngilizce tanımının yanında isteğe bağlı bir Türkçe karşılık taşır. Arayüz Türkçe olduğunda kategori adı ve açıklaması Türkçe gösterilir; Türkçe karşılık tanımlı değilse İngilizce metin görünmeye devam eder. İngilizce alanlar kanonik olarak korunur — AILuminate taksonomisinin kendi ifadeleri onlardır; Türkçe metinler Apinizer'ın çevirisidir ve standardın parçası değildir.

Türkçe metnin asıl değeri yalnızca okunabilirlik değildir. Konu tanımları anlamsal benzerlikle karşılaştırıldığı için, tanımın dili sonucu etkiler. Türkçe trafik gören bir kurulumda Türkçe tanımı İngilizcenin yerine kullanın, ikisini birlikte eklemeyin. Konu-Dışı Koruması listedeki tüm tanımlara bakıp en yüksek benzerliği aldığı için, aynı kategorinin iki dildeki tanımını birlikte eklemek meşru isteklerin yanlışlıkla engellenme oranını gözle görülür biçimde artırır.

Yasaklı ve İzin Verilen Konular aynı dil kapsamına sahip olmalı

Konu-Dışı Koruması, Yasaklı Konuları İzin Verilen Konulardan önce değerlendirir. Yasaklı Konular listesine Türkçe tanımlar ekleyip İzin Verilen Konuları yalnızca İngilizce bırakırsanız, izin-listesi kipinde çalışan bir yapılandırmada meşru Türkçe istekler engellenir. Hangi dil kapsamını seçerseniz seçin, iki listeye de aynı kapsamı uygulayın.

Eşik değeri kullandığınız embedding modeline bağlıdır

Konu eşleşmesinin benzerlik eşiği, seçtiğiniz embedding modeline göre anlamlıdır: farklı modeller aynı anlamsal yakınlık için farklı benzerlik ölçekleri üretir. Embedding modelini değiştirdiğinizde eşik değerini yeniden değerlendirin — aksi halde koruma hiç tetiklenmeyebilir ya da beklenenden çok daha fazla isteği yakalayabilir.

Eşik değeri kullandığınız modele göre ulaşılamaz kalırsa Apinizer bunu sessiz bırakmaz: konu tanımları ilk kez vektöre çevrildiğinde, tanımların birbirine olan en yüksek benzerliği eşiğin altındaysa gateway log'una bir uyarı yazılır. Konu tanımları, bu politikanın karşılaştıracağı metinler arasında birbirine en çok benzeyen metinlerdir; onlar bile eşiği geçemiyorsa gerçek bir istem de geçemez. Uyarı yalnızca bilgilendiricidir — eşiği kendiliğinden düşürmez, çünkü etkin eşiği sessizce değiştirmek mevcut tüm kurulumların engelleme davranışını değiştirirdi.

Bu katalog, MLCommons AILuminate v1.1 tehlike taksonomisinin kategori adlarını ve tanımlarını yeniden üretir; CC BY 4.0 lisansı altındadır. Kaynak standart için bkz. mlcommons.org/ailuminate. :::

Yayınlanmış doğruluk sayısı yok

Apinizer bu katalog için yanlış-pozitif/yanlış-negatif oranı yayınlamaz. Bunu güvenilir biçimde ölçmek, kendi trafiğinize özgü, etiketlenmiş, çok dilli bir korpus gerektirir — başkasının verisiyle kalibre edilmiş bir sayı sizin yanlış-pozitif oranınızı tarif etmez.

Dış Sağlayıcı Guardrail

İstem Koruması ve Konu-Dışı Koruması, yerleşik (regex/embedding tabanlı) değerlendirmenin yanında dış bir LLM'i hakem olarak da (llm-judge adaptörü) kullanabilir. Kişisel Veri Maskeleme ve Veri Sızıntısı Koruması da aynı llm-judge adaptörünü kullanabilir, ayrıca kurumun kendi vendor-bağımsız HTTP DLP servisine bağlanan ek bir adaptör türünü (http-dlp) sunar; bu ikisinin dış sağlayıcı davranışı bazı noktalarda farklı kurallar taşır ve aşağıda Harici DLP Entegrasyonu bölümünde ayrıca anlatılır. Tekrar-Fırtınası, Aşırı Boyut ve Bağlam Bütünlüğü Korumaları'nda dış sağlayıcı motoru yoktur. Dayanaklılık Koruması bu ikisinden farklı bir uçtadır: yerleşik bir motor seçeneği hiç yoktur, llm-judge hakemi politikanın kendisi kadar zorunludur — bkz. Dayanaklılık (Groundedness) Koruması.

Ayarı Ekranda Bulma

Ayar, guardrail politikasının kendi düzenleme ekranındadır — ayrı bir katalog sayfası yoktur. API Proxy → Politikalar → <politika> → Tanım sekmesinde, kural listesinin altında, kalkan ikonlu Dış Sağlayıcı başlıklı bölümdür.

İki nokta aramayı kolaylaştırır:

• Politikada zaten bir dış sağlayıcı yapılandırılmışsa, Tanım sekmesinin en üstünde bunu söyleyen bir bilgi şeridi çıkar; üzerine tıklayınca sayfa doğrudan bölüme kayar.
• Motor Yerleşik (varsayılan) iken bölümün altındaki alanların tamamı gizlidir; yalnızca motor seçimini ve kısa bir yönlendirme görürsünüz. Sağlayıcı seçimi ve ilgili alanlar, motoru değiştirdiğiniz anda görünür.

Ön koşul. LLM Sağlayıcı listesi, o projede tanımlı LLM bağlantılarını listeler (sağlayıcı tanımlarını değil). Projede hiç bağlantı yoksa liste boş gelir; önce LLM Sağlayıcıları ekranından bir bağlantı oluşturun.

Motor Seçimi

Her iki politikada da bir dış sağlayıcı motoru seçilebilir:

Motor	Davranış
Yerleşik — varsayılan	Bugünkü davranış; yalnızca regex/embedding tabanlı değerlendirme çalışır, dış çağrı yapılmaz
Yerleşik + Dış Sağlayıcı	İkisi de çalışır; yerleşik veya dış sağlayıcıdan herhangi biri güvensiz/uygunsuz sonucu verirse aksiyon uygulanır. Yerleşik değerlendirme engellerse dış çağrı hiç yapılmaz (kısa devre) — Yalnız-Gözlem modu bu kuralın dışındadır, bkz. aşağı
Yalnız Dış Sağlayıcı	Yalnızca dış sağlayıcı değerlendirilir; regex/embedding tanımları dolu olsa bile yok sayılır

Dış çağrı hata verir veya zaman aşımına uğrarsa ne olacağı ayrı bir ayarla belirlenir — varsayılan Kapalı-Güvenli: istek engellenir. Bu bilinçli bir tercihtir — yanlış yapılandırılmış bir dış sağlayıcının korumayı sessizce devre dışı bırakmasındansa (fail-open sessizliği), yanlış konfigürasyonun gürültülü biçimde bloklaması tercih edilmiştir. Açık-Güvenli seçilirse istek devam eder, ama bu her zaman görünür bir uyarı ve işaretlemeyle birlikte olur — sessiz açık-geçiş yoktur.

bilgi

Dış çağrı hiç yapılamayacak bir konfigürasyon tutarsızlığı (dış sağlayıcı seçili ama adaptör tanımsız veya LLM sağlayıcı referansı çözülemiyor) yukarıdaki hata/zaman-aşımı davranışından ayrıdır: bu bir çalışma-zamanı hatası değil bir kayıt/dağıtım hatasıdır — motor otomatik olarak Yerleşik'e düşer ve durum görünür biçimde işaretlenir/loglanır (sessiz geçiş yasak).

Değerlendirme aşağıdaki Çalışma Modlarından biriyle yapılır:

• Satır İçi — dış çağrı istek yoluna eklenir; sonuç beklenir. Bu, isteğin p95 gecikmesini doğrudan artırır — dış hakem modelinin kendi yanıt süresi kadar. Düşük gecikme kritikse Eşzamansız modu tercih edin.
• Eşzamansız — yapılandırılabilir bir üst bekleme süresi içinde sonuç beklenir; süre aşılırsa yukarıdaki hata/zaman-aşımı kararı uygulanır.
• Yalnız-Gözlem — dış sağlayıcı çağrılır ama sonuç karara asla katılmaz; yalnızca loglanır ve bir Prometheus uyum (agreement) metriğine yazılır. Yeni bir dış sağlayıcıyı üretime almadan önce yerleşik değerlendirmeyle ne kadar örtüştüğünü ölçmek (kalibrasyon) ve kademeli geçiş için kullanılır.

llm-judge Adaptörü

Bugün desteklenen tek dış değerlendirici tipi llm-judge'dır — mevcut bir LLM Provider tanımına referans verir. Yeni bir bağlantı tipi açılmaz; hâlihazırda tanımlı herhangi bir LLM sağlayıcısı hakem olarak kullanılabilir. Provider tipi aşağıdaki OpenAI-uyumlu liste ile sınırlıdır:

OpenAI, Azure OpenAI, vLLM, Ollama, Custom OpenAI-Compatible, DeepSeek, Groq, Moonshot, Mistral, Zhipu, Qwen (DashScope)

Bu listenin dışındaki bir provider tipi (örn. Anthropic, Cohere, Bedrock, Vertex — farklı bir kablo protokolü konuşur) hakem olarak seçilemez.

Adaptörün kendi ayarları:

Ayar	Açıklama	Varsayılan
Hakem model adı	Değerlendirmeyi yapacak model kimliği (örn. llama-guard3:1b, gpt-4o-mini)	— (zorunlu)
Yanıt bekleme süresi	Hakem çağrısının HTTP zaman aşımı	2000 ms
En fazla girdi karakteri	Hakeme gönderilecek metin bu uzunluğa kırpılır	8000 karakter
En fazla çıktı token'ı	Hakemin yanıtı için ayrılan token bütçesi	64
JSON modu	Etkinse hakemden yapılandırılmış (safe/flagged alanlı) bir yanıt istenir; kapalıysa düz metin safe/unsafe satırı beklenir	Kapalı

İki Değerlendirme Modu

Hakem prompt'unun nasıl oluşturulacağı tek bir alanla belirlenir — değerlendirme şablonu boş mu, dolu mu:

Değerlendirme şablonu	Mod	Kullanım senaryosu
Boş	NATIVE (doğrudan) geçiş	Güvenlik için özel eğitilmiş bir model (örn. Llama Guard 3, ShieldGemma). Bu modeller taksonomi talimatını kendi sohbet şablonlarının içinde zaten taşır — üstüne ayrıca bir taksonomi metni eklemek modelin taksonomiyi değerlendirilecek içerik sanmasına ve sessizce yanlış bir karara (false-negative dahil) yol açabilir. Bu yüzden değerlendirme şablonu bilinçli olarak boş bırakılır.
Dolu	Şablon modu	Genel amaçlı bir instruct model (örn. gpt-4o-mini) hakem olarak kullanılıyorsa, modele ne arayacağını anlatan bir taksonomi talimatı gerekir. Yapılandırma ekranındaki hazır şablon butonu S1-S13 güvenlik taksonomisini (şiddet, nefret söylemi, cinsel içerik, vb.) tek tıkla doldurur; kullanıcı metninin yerleştirileceği yer <<<PROMPT>>> yer tutucusuyla işaretlenir.

not

NATIVE geçiş modunda hakeme gönderilen metin olduğu gibi iletilir; ekstra bir talimat sarmalanmaz. Guard-tuned olmayan bir modelle NATIVE modu kullanırsanız model taksonomiyi bilmez ve genel bir sohbet yanıtı üretir — NATIVE mod yalnız bu amaçla eğitilmiş modeller içindir.

Kendi Sunucunuzda Barındırma Örneği: Ollama ile Llama Guard 3

Modeli indirin

Ollama çalıştıran sunucuda: ollama pull llama-guard3

LLM Provider tanımlayın

LLM Sağlayıcıları ekranında provider tipi Ollama, adres http://<host>:11434/v1, kimlik doğrulama Yok olacak şekilde yeni bir bağlantı ekleyin.

Politikayı yapılandırın

İstem Koruması veya Konu-Dışı Koruması politikasında motoru Yerleşik + Dış Sağlayıcı veya Yalnız Dış Sağlayıcı seçin, dış değerlendirici olarak llm-judge adaptörünü ekleyin, yukarıda tanımladığınız provider'a referans verin ve değerlendirme şablonunu boş bırakın (bu model için doğru mod NATIVE geçiştir).

Ollama'nın OpenAI-uyumlu /v1/chat/completions uç noktası, bu şekilde guard-tuned bir modelin kendi sohbet şablonunu otomatik uygular — bu davranış canlı bir testte doğrulanmıştır (llama-guard3:1b modeliyle, beklenen safe/unsafe biçiminde yanıt alınmıştır).

vLLM üzerinde aynı yaklaşım (guard-tuned modeli vLLM'in OpenAI-uyumlu sunucusuyla servis edip elde edilen /v1/chat/completions uç noktasını LLM Provider olarak tanımlamak) vLLM'in kendi dokümantasyonundaki chat-template otomatik uygulama davranışına dayanır; bu adımı kendi vLLM kurulumunuzda ayrıca doğrulamanız önerilir.

Reasoning (Akıl Yürütme) Modelleri Hakem Olarak Kullanılırken

uyarı

qwen3 gibi "reasoning" modelleri hakem olarak seçildiğinde, modelin ürettiği akıl yürütme adımları da en fazla çıktı token'ı bütçesinden düşer. Bu bütçe düşük tutulursa (varsayılan 64), model asıl safe/unsafe yanıtına hiç ulaşamadan token bütçesi tükenir ve yanıt boş/eksik kalır — bu durumda değerlendirme başarısız sayılır ve yukarıdaki hata/zaman-aşımı kararı devreye girer.

Bir reasoning modeli hakem olarak kullanmanız gerekiyorsa en fazla çıktı token'ını en az 1024'e çıkarın veya modelin akıl yürütme modunu kapatın. Asıl önerilen yol: mümkünse güvenlik için özel eğitilmiş (guard-tuned) bir model ile NATIVE geçiş modunu tercih etmektir — bu modeller kısa ve deterministik yanıt üretir, reasoning bütçesi sorunu hiç oluşmaz.

Güvenlik Notu

Hakeme gönderilen metin maskelenmemiş, ham istem/yanıt içeriğidir. Zincirde PII Maskeleme politikası varsa, bu politikanın İstem Koruması / Konu-Dışı Koruması'ndan önce mi sonra mı çalıştığına dikkat edin — PII Maskeleme sonradan çalışıyorsa hakem hâlâ maskelenmemiş kişisel veriyi görür ve bu veri kullandığınız sağlayıcıya gönderilmiş olur.

Hassas/gizli veri içeren trafikte, hakemi kendi sunucunuzda veya kendi VPC'nizde barındırmanız (self-hosted Ollama/vLLM) önerilir — dış bir buluta ham istem gönderilmesini tamamen ortadan kaldırır.

Konu-Dışı Koruması'ndaki Fark

İstem Koruması'nda boş bir değerlendirme şablonu meşru ve desteklenen bir yapılandırmadır (NATIVE geçiş). Konu-Dışı Koruması'nda ise dış sağlayıcı kullanılırken değerlendirme şablonu boş bırakılamaz — bir güvenlik hakeminin ("bu içerik güvenli mi") verdiği yanıt, bir konu-uygunluk sorusunun ("bu istek izin verilen konu kapsamında mı") yanıtı değildir; boş şablonla genel bir güvenlik hakemi devreye girer ve yanıltıcı "konu-dışı" kararları üretebilir. Bu nedenle Konu-Dışı Koruması, dış sağlayıcı seçiliyken boş şablonu kayıt sırasında reddeder. Bu, iki koruma arasında bilinçli bir asimetridir.

Gözlemlenebilirlik

Dış sağlayıcı çağrılarının sonucu (güvenli / güvensiz / zaman aşımı / hata) ve hangi sağlayıcının kaç kez tetiklendiği Güvenlik ve Guardrail'ler raporunda izlenebilir. Yalnız-Gözlem modundaki uyum oranı ise yalnız bir Prometheus metriğidir — bu oran için ayrı bir UI raporu yoktur; kalibrasyon/kademeli geçiş kararı sırasında Prometheus/Grafana üzerinden izlenmelidir.

APIops

Dış sağlayıcı yapılandırması, politika JSON'unda externalGuardrail bloğu ile taşınır:

• externalGuardrail bloğu gönderiliyorsa "type": "llm-judge" alanı zorunludur — eksik veya tanınmayan bir type ile gönderilen istek (boş bir {} blok dahil) engine değeri ne olursa olsun (Yerleşik dahil) reddedilir.
• engine alanı BUILTIN ise externalGuardrail bloğunu hiç göndermeyin (alanı boş/null bırakın).
• LLM sağlayıcı referansı ada göre (llmProviderName) taşınır — iç kimlik (ObjectId) APIops yüzeyine hiç çıkmaz, projeye özgü sağlayıcı adı yeterlidir.
• GET /api/ai-catalog/guardrail-defaults uç noktası, hazır taksonomi şablonunun ve <<<PROMPT>>> yer tutucusunun güncel varsayılan değerlerini döner — UI'daki hazır şablon butonuyla aynı kaynağı kullanır.

Harici DLP Entegrasyonu

Kişisel Veri Maskeleme ve Veri Sızıntısı Koruması, yerleşik (regex tabanlı) kural listesinin yanında dış bir sağlayıcıya da karar sorabilir — İstem Koruması ve Konu-Dışı Koruması'nda kullanılan yukarıdaki Dış Sağlayıcı Guardrail bölümündeki llm-judge hakemiyle ya da kurumunuzun kendi harici DLP / içerik koruma servisine bağlanan ek bir adaptör türüyle (http-dlp) — genel amaçlı bir LLM gerekmeden, sizin yazdığınız veya kurumunuzun zaten işlettiği vendor-bağımsız bir HTTP servisiyle.

Motor Seçimi

Aynı üç motor seçeneği burada da geçerlidir:

Motor	Davranış
Yerleşik — varsayılan	Yalnızca kural listesi çalışır, dış çağrı yapılmaz
Yerleşik + Dış Sağlayıcı	İkisi de çalışır; yerleşik bir Engelle eşleşmesi dış çağrıyı kısa devre yapar (dış servis hiç çağrılmaz); yerleşik eşleşme yoksa dış servis çağrılır
Yalnız Dış Sağlayıcı	Yalnızca dış servis değerlendirilir; kural listesi dolu olsa bile yok sayılır

Kişisel Veri Maskeleme'de "Yalnız Dış Sağlayıcı" = maskeleme YOK

Kişisel Veri Maskeleme politikasının normal işi maskelemektir. Yalnız Dış Sağlayıcı motoru seçildiğinde kural listesi tamamen devre dışı kalır — politika artık hiçbir şeyi maskelemez, yalnızca dış servisin kararına göre isteği engeller ya da geçirir. Maskeleme davranışını korumak istiyorsanız Yerleşik + Dış Sağlayıcı'yı kullanın.

Dış servisin güvensiz kararı verdiği her durumda istek engellenir — Veri Sızıntısı Koruması'nda bile bu bir maskeleme değil bloklamadır; dış hakem "maskele" diyemez, yalnızca güvenli/güvensiz bildirir.

Adaptör Tipi: LLM Hakem mi, HTTP DLP Servisi mi

Motor Yerleşik dışında bir değere ayarlandığında, hangi adaptörün çağrılacağı ayrıca seçilir:

Adaptör	Ne yapar
LLM Hakem (llm-judge)	Yukarıdaki Dış Sağlayıcı Guardrail bölümünde İstem Koruması ve Konu-Dışı Koruması için anlatılan aynı adaptör — LLM sağlayıcı referansı, hakem model adı, prompt şablonu (NATIVE geçiş / Şablon modu), JSON modu ve en fazla çıktı token'ı aynı şekilde yapılandırılır. O bölümdeki anlatım (reasoning model uyarısı dahil) burada da geçerlidir.
HTTP DLP Servisi (http-dlp)	Kurumun kendi vendor-bağımsız HTTP servisine bağlanır; aşağıdaki Bağlantı ve İstek/Yanıt Sözleşmesi bölümündeki sabit sözleşmeye göre çalışır.

Adaptör seçimi yalnız sonucu kimin ürettiğini değiştirir. Motor seçenekleri (Yalnızca Yerleşik / Yerleşik + Dış Sağlayıcı / Yalnızca Dış Sağlayıcı), Dış Sağlayıcı Hata Modu (Kapalı-Güvenli/Açık-Güvenli) ve az aşağıda anlatılan üç davranış farkı her iki adaptör için de aynıdır.

İstem Koruması / Konu-Dışı Koruması'ndan Üç Fark

Bu entegrasyon aynı alt yapıyı (Dış Sağlayıcı Guardrail) paylaşsa da üç noktada farklı davranır:

1. Çalışma modu her zaman Satır İçi'dir. İstem Koruması/Konu-Dışı Koruması'ndaki Satır İçi / Eşzamansız / Yalnız-Gözlem seçimi burada yoktur — dış çağrı her zaman isteği işleyen thread üzerinde senkron olarak yapılır; tek sınır adaptörün kendi bağlantı zaman aşımıdır.
2. Akış (streaming) yanıtlarda dış servis hiç çağrılmaz. Chunk bazlı tarama, motor ayarı ne olursa olsun, her zaman yalnızca yerleşik kural listesiyle çalışır. Pratik sonucu: Yalnız Dış Sağlayıcı motoruyla yapılandırılmış bir politika, akış yanıtlarda hiçbir şey taramaz (ne yerleşik kural ne dış servis) — akış dışı (tekil) istek/yanıtlarda dış servis normal şekilde çalışmaya devam eder.
3. Yapılandırma tutarsızlığı, çalışma-zamanı hatasından ayrı ele alınır. Motor dış sağlayıcı istiyor ama adaptör tanımsız veya bağlantı referansı çözülemiyorsa, bu bir kayıt/dağıtım hatasıdır — motor otomatik olarak Yerleşik'e düşer ve aşağıdaki başarısızlık davranışı uygulanmaz. Başarısızlık davranışı yalnızca dış çağrı gerçekten yapılıp da hata verdiğinde veya zaman aşımına uğradığında devreye girer.

Başarısızlık Davranışı

Dış çağrı hata verirse veya zaman aşımına uğrarsa:

Ayar	Davranış
Kapalı-Güvenli (varsayılan)	İstek engellenir
Açık-Güvenli	İstek devam eder; bu durum her zaman görünür bir uyarı ile birlikte kaydedilir — sessiz açık-geçiş yoktur

Bağlantı ve İstek/Yanıt Sözleşmesi

Bu sözleşme yalnızca HTTP DLP Servisi adaptörü içindir — LLM Hakem seçildiğinde yukarıdaki Dış Sağlayıcı Guardrail bölümündeki alanlar geçerlidir.

Dış servis bağlantısı, mevcut bir Webhook konnektörü referansıyla kurulur — bunun için ayrı bir bağlantı türü açılmaz; adres, HTTP metodu, header'lar (kimlik doğrulama dahil), zaman aşımı ve TLS ayarlarının hepsi o bağlantı üzerinden gelir.

Kendi servisinizi yazarken uymanız gereken sabit sözleşme şudur:

İstek (Apinizer'ın gönderdiği, application/json):

{
  "text": "<taranacak metin, en fazla girdi karakterine kırpılmış>",
  "direction": "REQUEST" | "RESPONSE",
  "apiType": "AI" | "MCP" | "A2A" | null,
  "apiProxyName": "<proxy adı>" | null,
  "apiProxyId": "<proxy id>" | null,
  "correlationId": "<istek korelasyon kimliği>" | null
}

Yanıt (servisinizin dönmesi gereken, HTTP 2xx + bu gövde):

{
  "safe": true,
  "categories": ["secret-key"],
  "score": 0.87
}

• safe (boolean) veya onun tersi flagged (boolean) alanlarından tam olarak biri bulunmalıdır — ikisi birden ya da hiçbiri gönderilirse çağrı hatalı sayılır.
• categories opsiyoneldir, string dizisi olarak alınır.
• score opsiyoneldir; yalnızca 0 ile 1 arasında bir sayıysa alınır, aksi halde yok sayılır.
• HTTP 2xx dışı bir durum kodu, geçersiz/eksik JSON gövde veya safe/flagged alanı eksik/boolean-olmayan her durum çağrıyı başarısız sayar ve yukarıdaki Başarısızlık Davranışı ayarını devreye sokar. Sessiz güvenli/güvensiz varsayımı yoktur.

Varsayılan zaman aşımı 2000 ms, varsayılan en fazla girdi karakteri 8000'dir; ikisi de politika ekranında ayarlanabilir.

Ekrandan Açma

Kişisel Veri Maskeleme ve Veri Sızıntısı Koruması politika ekranlarında, yukarıda Dış Sağlayıcı Guardrail bölümünde anlatılanla aynı yerleşimde bir Dış Sağlayıcı paneli bulunur:

Alan	Karşılığı
Değerlendirme Motoru	Yukarıdaki Motor Seçimi tablosundaki üç seçenek
Dış Sağlayıcı Hata Modu	Motor Yerleşik dışı seçildiğinde görünür; Başarısızlık Davranışındaki Kapalı-Güvenli/Açık-Güvenli seçimi
Adaptör Tipi	Yukarıdaki Adaptör Tipi tablosundaki LLM Hakem/HTTP DLP Servisi seçimi; seçime göre LLM sağlayıcı referansı veya Webhook bağlantısı, zaman aşımı ve en fazla girdi karakteri alanları görünür

Paneli doldurup politikayı kaydetmeniz ve Dağıt'a tıklamanız yeterlidir. Aynı ayarlara APIops REST API (API Referansı: AI Gateway) ile ya da politika JSON'unda engine, failMode ve externalGuardrail alanları ayarlanarak da ulaşabilirsiniz.

Tekrar-Fırtınası (Loop) Koruması

Aynı isteğin kısa bir zaman penceresinde tekrar tekrar gönderilmesini tespit eder (örn. istemci tarafı hatalı bir yeniden deneme döngüsü veya kendi kendine tekrar üreten bir ajan zinciri):

• İstek içeriğinin bir özeti çıkarılır
• Yapılandırılabilir bir zaman penceresinde (N saniyede M istek) aynı özetin tekrar sayısı izlenir
• Eşik aşılırsa istek işaretlenir veya engellenir

Sayaç; model, API proxy ve çağıranın kimliği ile birlikte anahtarlanır. Böylece bir çağıranın tekrarı başka bir çağıranın hakkını tüketmez.

ipucu

Bu koruma, özellikle otonom ajan zincirlerinde beklenmeyen maliyet artışını erken tespit etmek için değerlidir.

Kimliği Olmayan (Anonim) İstekler

Kimlik doğrulaması olmayan bir API proxy'de istek, sayacın anahtarlanacağı bir kimlik taşımaz. Bu durumda ne yapılacağı politikada seçilir:

Seçenek	Davranış
Politikayı uygulama (varsayılan)	İstek geçer, tekrar sayacı işletilmez
Ortak havuzdan tüket	Tüm anonim trafik tek bir sayaçta toplanır
İsteği reddet	Anonim istek HTTP 401 ile geri çevrilir

Varsayılan seçenek, bu ayar eklenmeden önceki davranışla birebir aynıdır: anonim istekte koruma sessizce devre dışı kalır. "Ortak havuzdan tüket" seçildiğinde kiracı izolasyonu beklenmez — bir çağıranın tüketimi diğerlerinin hakkını da harcar; anonim erişime bilinçli olarak izin verilmiş, ama yine de bir tavan konmak istenen kurulumlar içindir.

bilgi

Bu seçim, API proxy düzeyindeki anonim istekleri engelle ayarından farklıdır. O ayar isteği bu politikaya hiç ulaştırmadan reddeder; buradaki seçim ise anonim erişime izin verilmiş bir proxy'de bu politikanın ne yapacağını belirler.

Semantik önbellek de aynı gerekçeyle aynı üç seçeneği sunar — bkz. Semantik Önbellek.

Aşırı Boyut Koruması

İstek boyutunu iki boyutta sınırlar:

• İstek başına maksimum token — istemin tahmini token sayısı bu değeri aşarsa istek reddedilir
• İstem başına maksimum karakter — ham istem metni karakter sınırını aşarsa istek reddedilir

Sınır aşıldığında varsayılan davranış isteği engellemektir; dilerseniz engellemek yerine en eski konuşma turlarının otomatik kesilmesini seçebilirsiniz — bkz. Tek İstek Sınırı: Bağlam Penceresi Taşması.

Bu koruma, aşırı büyük isteklerin hem maliyet hem de kaynak tüketimi açısından kontrolsüz büyümesini engeller.

Bağlam Bütünlüğü Koruması (Yapısal Enjeksiyon)

Sohbet geçmişine (mesaj listesine) sahte sistem/asistan rolü enjekte edilmeye çalışılıp çalışılmadığını tespit eder. İstem Koruması içeriği anlam bazında tararken, bu koruma sohbetin yapısını korur:

• Sahte rol imi tespiti — bir kullanıcı mesajının içeriğine gömülü, modeli önceki bir sistem/asistan turu gibi kandırmaya çalışan kalıplar (örn. sohbet şablonu kontrol imleri veya ###Talimat benzeri sahte talimat imleri)
• Rol sırası doğrulama (isteğe bağlı) — istemcinin izin verilenden fazla sistem mesajı eklemesi ya da izin verilmeyen bir rol kullanması engellenir

Eşleşmede üç aksiyondan biri uygulanır: Engelle, İşaretle, veya Maskele (yalnızca sahte rol imi eşleşmeleri maskelenebilir; bir rol-sırası ihlali maskeleme yerine işaretlemeye döner — yapısal bir uyuşmazlık maskelenemez).

Dayanaklılık (Groundedness) Koruması

LLM'in yanıtının, aynı istekte RAG politikasının enjekte ettiği bağlama gerçekten dayanıp dayanmadığını denetler — bir hakem LLM, üretilen yanıtı alınan bağlamla karşılaştırır ve dayanaklı (grounded) ya da dayanaksız/halüsinasyon (ungrounded) kararı verir. Yanıt hattında (response-lane) çalışır ve yalnızca Apinizer'ın kendi AI Gateway'lerinde eklenebilir — MCP ve A2A Gateway'lerinde kullanılamaz.

Kapsam: yalnızca kendi enjekte ettiğiniz RAG bağlamı, genel doğruluk kontrolü değil

Bu koruma yalnızca bu proxy'nin aynı istekte enjekte ettiği RAG bağlamına karşı dayanaklılığı kontrol eder. Genel dünya bilgisine karşı bir doğruluk (factuality) kontrolü DEĞİLDİR — harici bir kaynakla doğrulama yapmaz. Sonuç olarak:

• Bağlamda olmayan ama gerçekte doğru bir iddia, bu koruma açısından yine de dayanaksız sayılır (RAG bağlamınca desteklenmiyor).
• Bağlamdaki bilginin kendisi yanlışsa (kaynak veriniz hatalıysa), yanıt o hatalı bilgiyi aynen tekrar ettiğinde dayanaklı sayılır — koruma kaynağın doğruluğunu sorgulamaz.

RAG Bağlamı Nasıl Tespit Edilir — En Önemli Kısıt

Bu koruma, hangi metnin "RAG'in enjekte ettiği bağlam" olduğunu RAG politikasının ayrı bir kanaldan yayınladığı bir işaretten değil, backend'e giden istek gövdesindeki <CONTEXT>...</CONTEXT> işaretleyici çiftini arayarak anlar — RAG politikasının varsayılan Enjeksiyon Şablonu'nun kendisi bu işaretleyicileri zaten içerir (bkz. RAG Yapılandırması).

Yalnızca RAG'in Enjeksiyon Modu "Şablon ile Enjekte Et" iken çalışır

RAG'in Enjeksiyon Modu alanı varsayılan olarak Kullanıcı Mesajına Ekle (Başa)'dır — bu modda bağlam hiçbir işaretleyici olmadan kullanıcının isteğinin önüne düz metin olarak eklenir. Bu varsayılan modda (ya da Sistem Mesajına Ekle/Sistem Mesajından Sonra Ekle modlarında) Dayanaklılık Koruması istekte hiçbir tespit edilebilir bağlam bulamaz ve sessizce hiçbir şey yapmaz — ne engeller ne işaretler, çünkü değerlendirecek bir bağlamı yoktur. Bu koruma yalnızca RAG'in Enjeksiyon Modu Şablon ile Enjekte Et olarak ayarlandığında ve kullanılan şablon (varsayılan ya da özel) <CONTEXT>/</CONTEXT> çiftini içerdiğinde çalışır. RAG'i varsayılan modunda bırakıp bu korumayı eklemek görünürde etkinmiş gibi görünen ama gerçekte hiçbir isteği değerlendirmeyen bir yapılandırma üretir — RAG'inizi Dayanaklılık Koruması ile birlikte kullanacaksanız Enjeksiyon Modu'nu Şablon ile Enjekte Et olarak ayarlayın.

Bir istekte tespit edilebilir bağlam bulunamadığı (RAG hiç çalışmadı ya da tespit edilemeyen bir modda çalıştı) ile bağlamın kasıtlı olarak boş bırakıldığı durumlar ayırt edilemez — ikisi de aynı sessiz no-op'a düşer. Bu, kapsamı genişletmeden korunabilecek tek davranışsal tercihtir.

Yalnızca Akış Dışı (Unary) Yanıtlar

Bu koruma akış (streaming) yanıtlarda çalışmaz — bir akış yanıtı geldiğinde değerlendirme hiç tetiklenmez, ne engelleme ne işaretleme olur. Bunun nedeni de tasarımsal: dayanaklılık kararı yanıtın tamamına ihtiyaç duyar, ve bir akış yanıtının tamamı ancak akış bittiğinde bilinir; Konu-Dışı Koruması'nın akış desteğinde kullanılan tampon-ve-tarama (buffer-and-scan) altyapısı bu koruma için henüz uygulanmamıştır.

Hakem Zorunludur

Diğer bazı AI korumalarının aksine (İstem Koruması, Konu-Dışı Koruması), Dayanaklılık Koruması'nın yerleşik/algoritmik bir kontrolü yoktur — "bu metin şu metince destekleniyor mu" sorusunun ucuz, deterministik bir çözümü olmadığı için değerlendirme her zaman bir llm-judge hakemine (bkz. Dış Sağlayıcı Guardrail) dayanır. Buna bağlı iki zorunluluk kayıt anında uygulanır:

• Bir hakem (externalGuardrail) tanımlamadan politika kaydedilemez.
• Hakem prompt şablonu boş bırakılamaz — İstem Koruması'ndaki boş şablonun NATIVE (doğrudan) geçişe düşmesinin aksine, burada boş bir şablon dayanaklılık sorusu sormayan genel bir güvenlik hakemine düşerdi ve bu anlamsız bir karar üretirdi. Yeni bir politika için dayanaklılığa özgü bir başlangıç şablonu önceden doldurulur; ihtiyacınıza göre uyarlayabilirsiniz ama şablon her zaman bir dayanaklılık sorusu sormalıdır.

Hakemin kendi ayarları (model adı, zaman aşımı, JSON modu, en fazla girdi/çıktı token'ı) Dış Sağlayıcı Guardrail bölümündeki llm-judge adaptörüyle birebir aynıdır — reasoning modeli hakem olarak kullanırken en fazla çıktı token'ını yükseltme uyarısı da dahil.

Aksiyon, Değerlendirme Modu ve Hata Yönetimi

Ayar	Varsayılan	Not
Aksiyon	FLAG	BLOCK seçilirse dayanaksız yanıt reddedilir
Değerlendirme Modu	INLINE	Konu-Dışı Koruması'nın varsayılanı ASYNC'tir; burada varsayılan INLINE'dır çünkü bu bir yanıtı BLOCK edebilen bir güvenlik kapısıdır — doğruluk, gecikmeye tercih edilir. ASYNC ve SHADOW da seçilebilir.
Hakem Hata Modu	FAIL_CLOSED	Hakem çağrısı hata verir/zaman aşımına uğrarsa yanıt bloklanır. FAIL_OPEN seçilirse yanıt görünür bir uyarıyla birlikte doğrulanmamış olarak devam eder.
Maks. Bağlam Karakteri	6000	Hakeme gönderilmeden önce alınan bağlamın kırpma sınırı
Maks. Yanıt Karakteri	4000	Hakeme gönderilmeden önce yanıt metninin kırpma sınırı

Sıra: PII/DLP'den Sonra

Bu koruma yanıt hattında çalışır ve hakem çağrısının kendisi yanıt içeriğinin dış bir LLM sağlayıcısına gönderilmesi anlamına gelir — bu nedenle her zaman Kişisel Veri Maskeleme ve Veri Sızıntısı Koruması'ndan SONRA çalışacak şekilde sıralanmalıdır, sayfanın en başındaki Politika sırası uyarısının aynı gerekçesiyle. Politika listesini bu kurala aykırı bir sırayla kaydederseniz Apinizer sırayı kayıt anında otomatik düzeltir.

Çalışma Modları

Her koruma için üç değerlendirme modundan biri seçilebilir:

Mod	Davranış
Satır İçi	İstek eşzamanlı olarak beklenir; sonuç anında engelleme/işaretleme kararına yansır
Eşzamansız	Değerlendirme arka planda paralel çalışır, kısa bir üst süre içinde sonuç beklenir; süre aşılırsa güvenli varsayılan uygulanır
Yalnız-Gözlem	Değerlendirme sonucu asla engellemez veya işaretlemez; yalnızca ölçüm ve raporlama amacıyla çalışır

not

Çoğu koruma için varsayılan mod satır içidir; Konu-Dışı Koruması varsayılan olarak eşzamansız çalışır. Her koruma için mod ayrı ayrı değiştirilebilir.

Dış Sağlayıcı Guardrail kullanan İstem Koruması ve Konu-Dışı Koruması'nda Yalnız-Gözlem modu özellikle bir dış sağlayıcıyı üretime almadan önce kalibrasyon ve kademeli geçiş amacıyla kullanılır. Bu mod, dış çağrının hata verme/zaman aşımı davranışını belirleyen ayrı bir ayardan (Kapalı-Güvenli / Açık-Güvenli) bağımsızdır — çalışma modu ne zaman değerlendirileceğini, hata davranışı ise dış çağrı başarısız olduğunda ne olacağını belirler.

Hazır Şablonlar ve Politikalar: Bağlı mı, Yerelleştirilmiş mi

Kişisel veri, İstem Koruması ve Veri Sızıntısı Koruması politikaları kurallarını istek anında katalogdan okumaz — her kural, siz seçtiğinizde alınmış bir kopyadır. Bu kopyanın kataloğu izlemeye devam edip etmediğini, kural satırındaki Kaynak kolonunda görünen durumu belirler.

Durum	Anlamı
Katalog bağlı	İçeriği hazır şablon sahiplenir. Şablonu düzenleyip kaydettiğinizde, onu kullanan tüm politikalardaki bu kural yeniden yazılır ve etkilenen dağıtımlar "yeniden dağıtım gerekli" olarak işaretlenir. Kuralın katalog sahipli alanları politika ekranında salt-okunurdur.
Yerel	Kopmuş, bağımsız bir kopya. Katalog düzenlemeleri ona ulaşmaz; politika ekranında serbestçe düzenleyebilirsiniz.

Katalogdan eklenen kural katalog bağlı doğar. Kural satırı iki durum arasında geçiş yapar:

• Yerelleştir — bağı koparır. Mevcut içerik korunur, ama kural katalog güncellemelerini almayı bırakır ve düzenlenebilir hale gelir. Yalnızca tek bir politikada özelleştirme yapmak istediğinizde kullanın.

Katalogun hangi alanları sahiplendiği korumaya göre biraz değişir; kalan her şey politikaya özel kalır:

Koruma	Şablondan tazelenen	Her zaman politikaya özel kalan
İstem Koruması / Veri Sızıntısı Koruması	Desen, aksiyon, kategori, açıklama	Ad ve aktif/pasif durumu
Kişisel veri maskeleme	Alan adı, işlem, desen tipi, regex, maskeleme ayarları	Aktif/pasif durumu

Kişisel veri maskelemede politikaya özel ayrı bir etiket alanı yoktur: alan adı fonksiyoneldir (alan adı modunda gerçekten eşleştirilen alandır), bu yüzden onu da şablon sahiplenir.

Paylaşımlı Şablonu Düzenlemek Tüm Kurulumu Etkiler

Her proje paylaşımlı bir hazır şablonu (sistem yöneticisinin kaydını) seçebildiği için, böyle bir şablonu düzenlemek ona bağlı kuralları kurulumdaki tüm projelerde tazeler ve etkilenen dağıtımları "yeniden dağıtım gerekli" olarak işaretler. Böyle bir şablonu yalnızca sistem yöneticisi düzenleyebilir ve kaydetmeden önce gördüğü kullanım listesi kurulumun tamamını kapsar. Aynı şablonu proje ekranından görüntüleyen bir kullanıcı yalnızca kendi projesinin kullanımlarını görür. Projeye ait şablonlarda hem güncelleme hem liste o projenin içinde kalır.

Eski Kurallar ve İçe Aktarma

Bu davranıştan önce oluşturulmuş kurallar şablon referansı taşımaz, dolayısıyla yerel sayılır ve kendiliğinden senkron olmaz.

Yerelleştirme tek yönlüdür: yerelleştirilmiş bir kuralı sonradan şablona geri bağlama diye bir işlem yoktur. Ada bakarak otomatik eşleştirme güvenilir değildir (ad düzenlenebilir olduğu için isim benzerliği yanlış şablona bağlama riski taşır) ve bağlanan kural, şablon her düzenlendiğinde desenini/aksiyonunu oradan yeniden alır — yani yanlış bağ sessiz bir güvenlik davranışı değişikliğine dönüşebilir. Bir kuralın şablonla senkron olmasını istiyorsanız onu silin ve katalogdan yeniden ekleyin.

Bir yapılandırmayı başka bir ortama içe aktardığınızda da kurallar yerelleştirilmiş iner, çünkü hedef ortamın şablon kayıtları farklıdır. Orada da senkron istiyorsanız aynı yolu izleyin: sil ve katalogdan yeniden ekle.

Hazır Şablonu Silmek

Silme hiçbir zaman engellenmez. Şablon bir yere bağlıysa, silme gerçekleşmeden önce nerelerde kullanıldığını listeleyen bir uyarı çıkar. Onayladığınızda şablon silinir ve ona bağlı kurallar yerelleştirilir — içerikleri korunur, dağıtılmış hiçbir politika bozulmaz ve yeniden dağıtım istenmez (yalnızca bağ değişti, etkin içerik değil).

Şablonu yeniden adlandırmak bağlı kuralları etkilemez: kurallar şablonu adıyla değil, kimliğiyle izler.

OWASP LLM Top 10 ve MITRE ATLAS İmza Paketi (İstem Koruması)

İstem Koruması'nın yerleşik hazır kuralları, sürümlü ve bütünlük denetimli bir imza paketi olarak gelir: her yerleşik kural bir OWASP GenAI LLM Top 10 kimliğiyle ve bir MITRE ATLAS (Adversarial Threat Landscape for AI Systems) teknik kimliğiyle etiketlenir. Bu iki kimlik, kural listesinde her satırın yanında rozet olarak görünür — ATLAS tekniği rozetin üzerine gelindiğinde tooltip'te gösterilir.

Kapsam: bugün LLM01 ve LLM08

Yerleşik paket bugün OWASP taksonomisinin tamamını değil, iki kategorisini kapsar: jailbreak / rol-geçersiz-kılma / güvenlik-atlatma / enjeksiyon kalıpları LLM01 (Prompt Injection)'e, sistem-prompt sızıntısı kalıpları LLM08 (Hidden Context Exposure)'a eşlenir. Karşılık gelen ATLAS teknikleri: AML.T0054 (LLM Jailbreak), AML.T0051.000 (LLM Prompt Injection: Direct) ve AML.T0056 (Extract LLM System Prompt).

Bu kimlikler yalnızca görüntüleme/raporlama amaçlıdır — İstem Koruması'nın çalışma zamanındaki eşleştirme mantığını etkilemez, yalnız hangi kuralın hangi tehdit sınıfını temsil ettiğini bir denetim/uyum (compliance) bakışıyla görünür kılar. Kendi özel (custom) kurallarınıza da kendi OWASP/ATLAS kimliklerinizi girebilirsiniz — bu iki alan salt-okunur değildir.

Sürüm ve bütünlük: paket, ürünle birlikte gelen dahili bir sürüm sayacı taşır — ağ üzerinden otomatik güncelleme yoktur (hava boşluklu/air-gapped kurulumlar için bilinçli tasarım); yeni bir paket sürümü yalnızca bir Apinizer sürüm yükseltmesiyle gelir. Kural listesi ekranının üstünde bir durum şeridi şunları gösterir:

Alan	Anlamı
İmza paketi vN kurulu	Kurulumdaki yerleşik satırların en eski damgalandığı sürüm — bir satır hiç damgalanmamışsa kurulu sürüm bilinmiyor sayılır ve şerit uyarı rengiyle gösterilir
bu sürüm vN ile geliyor	Çalışan Apinizer build'inin taşıdığı (kod içine gömülü) paket sürümü
checksum ...	Tüm yerleşik satırların (ad+kural+aksiyon+kategori+OWASP kimliği+ATLAS tekniği üzerinden, sırasız) SHA-256 özeti — etkin/pasif durumu ve açıklama özete dahil değildir
N sürüm geride	Kurulu sürüm, bu build'in taşıdığı sürümden gerideyse gösterilen uyarı rozeti; ikisi eşitse yerini Güncel rozeti alır

Kullanıcı preset'leri asla ezilmez

Bir paket yükseltmesi yalnızca builtIn=true (yerleşik) satırları hedefler — kendi oluşturduğunuz, hatta yerleşik bir kuralla aynı adı taşıyan özel bir kural bu güncellemeden hiçbir zaman etkilenmez.

Merkezi Yönetim

Bu korumaları ilgili API Proxy özelinde tanımlayabilir ya da Global Politikalar ekranından tüm API Proxy'lerde ortak olarak yönetebilirsiniz — bir global koruma politikasını güncellediğinizde onu kullanan tüm proxy'ler etkilenir. Merkezi tanım, içe/dışa aktarma ve toplu dağıtım için bkz. Global Politikalar.

Kişisel veri, İstem Koruması ve Veri Sızıntısı Koruması hazır şablonları APIops REST API ile de yönetilebilir; bkz. API Referansı: AI Privacy Presets, AI Prompt-Guard Presets, AI DLP Presets.

Yapılandırma

Politikayı Ekleyin

İlgili API proxy veya global politika grubuna istediğiniz koruma politikasını (PII / İstem / DLP / Konu-Dışı / Döngü / Aşırı Boyut / Bağlam Bütünlüğü / Dayanaklılık) ekleyin.

Kalıpları / Eşikleri Seçin

Hazır kalıp setlerini seçin veya kendi kalıbınızı tanımlayın; eşik ve zaman penceresi gerektiren korumalar için bu değerleri girin.

Aksiyonu ve Çalışma Modunu Belirleyin

Engelle / İşaretle / Maskele aksiyonlarından hangisinin uygulanacağını ve satır içi / eşzamansız / yalnız-gözlem modlarından hangisinin kullanılacağını seçin.

Dağıtın (Deploy)

Politikayı kaydettikten sonra Dağıt'a tıklayın — kayıt ile dağıtım ayrık adımlardır, otomatik dağıtım yapılmaz.

Semantik Önbellek ile İlişki

Yanıt maskeleme veya DLP koruması etkinken, maskeden önceki ham içerik semantik önbelleğe yazılmaz — böylece sonraki bir önbellek eşleşmesi maskeleme adımını atlayarak hassas veriyi sızdıramaz. Detaylar için bkz. Semantik Önbellek.

Sonraki Adımlar

Global Politikalar

Korumaları tüm API Proxy'lerde merkezi olarak yönetin

A2A Gateway

Ajanlar arası iletişimde de aynı egress koruma prensipleri geçerlidir

Çok-Modaliteli Uç Noktalar

Ses ve görsel uç noktalarını yapılandırın

Raporlar ve Analitik

Koruma tetiklenme oranlarını izleyin

RAG

Dayanaklılık Koruması'nın bağlamı denetlediği RAG politikasını yapılandırın