Bir kurum harici bir LLM sağlayıcısına istek gönderdiğinde yalnız prompt değil; RAG ile getirilen belge parçaları, kullanıcı girdileri, araç sonuçları ve sistem talimatları da veri çıkışının parçası olabilir. TLS aktarımı korur, fakat gönderilmemesi gereken bir bilginin sağlayıcıya ulaşmasını tek başına engellemez.
LLM Secure Gateway (LSG), bu sınırda çalışan politika uygulama katmanıdır. Onaylı harici model çağrısından önce hassas alanları tespit eder, kurum politikasına göre maskeler ve yalnız gerekli olan içeriğin çıkmasına yardımcı olur.
Gateway kullanmak “hiçbir veri kurum dışına çıkmaz” anlamına gelmez. Maskelenmemiş ve politikaca izin verilmiş içerik harici sağlayıcıya gönderilir. Güvenli mimari; veri sınıflandırması, doğru politika, test ve kayıt hijyeniyle birlikte kurulur.
Hangi riski çözer?
Tipik bir model isteğinde aşağıdaki hassas bilgiler bulunabilir:
- ad, e-posta, telefon ve müşteri numarası,
- kimlik, pasaport, vergi veya hesap bilgileri,
- IBAN ve ödeme verileri,
- sözleşme, bordro veya destek kaydı içindeki kişisel bilgiler,
- RAG bağlamında yanlışlıkla getirilen gizli belge bölümleri,
- bir tool veya connector yanıtının taşıdığı operasyonel veriler.
LSG'nin görevi, harici model egress'inden önce bu içeriğe veri minimizasyonu uygulamaktır. Gateway; tek başına yetkilendirme sistemi, model router'ı, secret vault veya tüm içerik güvenliği katmanı değildir.
Mimaride doğru konum
Kullanıcı / Agent / Workflow
→ Kimlik ve yetki kontrolü
→ RAG veya tool sonucu
→ Veri sınıflandırma ve egress kararı
→ LLM Secure Gateway: tespit + maskeleme
→ Onaylı model route'u / sağlayıcı
→ Çıktı guardrail'i
→ İzinliyse kontrollü geri yükleme
→ Kullanıcı
Gateway routing kararından önce çalışmalıdır. Aksi halde hassas payload, politika uygulanmadan bir dış servise yönlendirilmiş olabilir. Log, trace ve hata yakalama sistemleri de bu sınırın dışında düşünülmemelidir; ham prompt'u gateway'den önce kaydeden bir telemetry katmanı aynı veri sızıntısını farklı bir kanaldan yaratır.
İşlem zinciri
1. Tespit
Gateway, yapılandırılmış alanlar ve serbest metin içinde koruma gerektiren değerleri belirler. Bu aşama regex, doğrulayıcı, sözlük ve bağlama duyarlı sınıflandırma tekniklerini birlikte kullanabilir. Tek yöntem her veri türünde aynı başarıyı vermez.
Örnek, tamamen sentetik bir istek:
Ayşe Yılmaz'ın TR00 0000 0000 0000 0000 0000 00 numaralı hesabına
ait son destek kaydını özetle.
2. Politika değerlendirmesi
Bulunan her değer aynı biçimde işlenmek zorunda değildir. Politika şu kararlardan birini verebilir:
- isteği tamamen engelle,
- alanı geri döndürülemez biçimde maskele,
- alanı geçici token ile değiştir,
- yerel modele yönlendirilmek üzere işaretle,
- sınıflandırılmış verinin onaylı dış sağlayıcıya gitmesine izin ver.
3. Maskeleme
Harici modele gönderilen metin örneğin şöyle olur:
<KISI_1>'in <IBAN_1> numaralı hesabına ait son destek kaydını özetle.
Model iş görevini yerine getirecek bağlamı korurken gerçek değerleri görmez. İyi token tasarımı veri türünü anlatır, ancak gerçek değerin uzunluğu veya parçaları gibi gereksiz ipuçlarını sızdırmaz.
4. Kontrollü geri yükleme
Reversible modda gateway, istek ömrü boyunca token ile gerçek değer arasındaki eşlemeyi koruyabilir. Model yanıtındaki izinli token'lar yalnız yetkili kullanıcıya dönerken geri yüklenir. Eşleme:
- sağlayıcıya gönderilmemeli,
- kısa yaşam süreli olmalı,
- organizasyon ve istek sınırında izole edilmeli,
- loglara ham değer olarak yazılmamalı,
- hata veya zaman aşımında güvenli biçimde temizlenmelidir.
Reversible ve irreversible mod
| Mod | Ne yapar? | Uygun örnek |
|---|---|---|
| Irreversible | Değeri kalıcı bir yer tutucuya dönüştürür | Trend analizi, genel özet, sınıflandırma |
| Reversible | İzinli yanıtta değeri kontrollü olarak geri koyar | Yetkili müşteri temsilcisi için taslak yanıt |
Bir görev gerçek değeri gerektirmiyorsa irreversible yaklaşım daha küçük risk yüzeyi sunar. Reversible modu “varsayılan kolaylık” olarak değil, açık iş gereksinimi ve kısa süreli eşleme yönetimiyle kullanın.
Politika hiyerarşisi
Kurumsal kullanımda yalnız tek bir global ayar yeterli olmaz. Knowentra'da organizasyon politikası tabanı belirler; departman politikası bu korumayı güçlendirebilir. Etkili kural, çakışmada daha sıkı olan davranışı seçmelidir.
Organizasyon: IBAN dış sağlayıcıya maskeli gönderilebilir
Departman: IBAN içeren istek dış sağlayıcıya gönderilemez
Etkili karar: İstek engellenir veya onaylı yerel modele alınır
Departmanın merkezi korumayı sessizce zayıflatmasına izin vermemek, yönetim modelinin temel parçasıdır. Politika bulunamadığında davranış da açıkça tanımlanmalıdır; korumayı atlayarak devam etmek yerine güvenli varsayılan uygulanmalıdır.
Gateway diğer güvenlik katmanlarından nasıl ayrılır?
| Katman | Temel sorusu | LSG'nin yerine geçer mi? |
|---|---|---|
| Kimlik ve yetki | Bu kullanıcı bu kaynağa erişebilir mi? | Hayır |
| LLM Secure Gateway | Bu payload'daki hangi veri dışarı çıkabilir? | — |
| Model router | Hangi model/provider kullanılmalı? | Hayır |
| Guardrail | Girdi veya çıktı içerik politikasını ihlal ediyor mu? | Hayır |
| Secret vault | API anahtarları nasıl saklanmalı ve döndürülmeli? | Hayır |
| DLP/SIEM | Kurum genelinde olay nasıl tespit ve incelenir? | Tamamlayıcıdır |
LSG ile guardrail özellikle karıştırılır. LSG'nin odağı hassas veri ve egress minimizasyonudur. Guardrail ise prompt injection, zararlı içerik, konu sınırı veya çıktı kuralları gibi içerik politikalarını uygular. Sağlam bir sistem ikisini farklı kontrol noktaları olarak işletir.
Egress karar matrisi
| Veri sınıfı | İş gereksinimi | Önerilen karar |
|---|---|---|
| Kamuya açık | Harici model uygun | Onaylı route üzerinden gönder |
| Kurum içi | Değer modele gerekli değil | Maskele veya minimize et |
| Kişisel/hassas | Yetkili iş akışı, değer gerekli değil | Irreversible maskele |
| Kişisel/hassas | Değer yanıtta gerekli | Reversible mod + kısa TTL + audit |
| Çok gizli/yasaklı | Harici egress yasak | Engelle veya yerel modele yönlendir |
| Sınıf belirsiz | Politika eşleşmedi | Fail closed / manuel inceleme |
Bu tablo bir hukuk veya uyum kararı değildir. Veri sahipleri, güvenlik ve hukuk ekipleri gerçek sınıfları ve sağlayıcı koşullarını birlikte tanımlamalıdır. Gateway bu kararları teknik olarak uygulamaya yardım eder; tek başına mevzuat uyumluluğu sağlamaz.
Yerel model kullanıldığında
Tamamen kurum içinde çalışan bir modelde harici sağlayıcı egress'i olmayabilir. Yine de maskeleme bazı senaryolarda değerlidir:
- model servisinin farklı güven bölgesinde çalışması,
- paylaşımlı inference altyapısı,
- prompt ve cevapların operasyonel loglara girmesi,
- geliştirme/test ortamlarında üretim verisi kullanılması,
- daha az yetkili bir agent veya workflow'un veriye erişmesi.
Kontrolün gerekip gerekmediğini yalnız “model yerel mi?” sorusuyla değil, verinin geçtiği bütün güven sınırlarıyla değerlendirin.
Bilinen sınırlamalar
Hiçbir tespit katmanı kusursuz değildir:
- False negative: Hassas değer tanınmaz ve maskelenmeden geçer.
- False positive: Zararsız bir değer maskelenir, görev kalitesi düşer.
- Bağlam kaybı: Aşırı maskeleme, modelin ilişki ve sıralamayı anlamasını zorlaştırır.
- Dosya ve görsel: Metin dışında OCR, tablo, metadata ve ekler ayrı kontroller ister.
- Yapılandırılmış veri: JSON alanları şema bazlı ele alınmazsa payload bozulabilir.
- Tool çağrıları: Agent'ın ürettiği argüman ve tool dönüşü ayrıca denetlenmelidir.
- Streaming: Token geri yükleme ve çıktı kontrolü akış halinde daha dikkatli tasarlanır.
- Ön-gateway logları: Koruma çalışmadan önce kaydedilen payload kapsam dışı kalır.
Bu nedenle yalnız birkaç örnekle “çalışıyor” demek yerine gerçek veri biçimlerini temsil eden regresyon paketi gerekir.
Üretim güvenlik kontrolleri
Fail-closed davranışı
Politika servisi, tespit motoru veya token deposu erişilemezse sistemin hangi çağrıları engelleyeceği önceden belirlenmelidir. Hassas route'ta gateway'i atlayarak devam etmek güvenli fallback değildir.
Kayıt hijyeni
Audit kaydı ham değeri değil kararı taşımalıdır:
{
"requestId": "req_demo_42",
"organizationId": "org_demo",
"departmentId": "support",
"providerRoute": "approved-external",
"detectedTypes": ["PERSON", "IBAN"],
"action": "reversible_mask",
"policyVersion": "egress-2026-06",
"result": "allowed"
}
Prompt, eşleme tablosu veya model cevabının tamamını audit'e koymak çoğu durumda gereksiz risk yaratır. Debug loglarının üretimde nasıl kapatıldığı ve saklama süreleri de test edilmelidir.
Taşıma ve servis kimliği
Gateway, router ve model adapter arasındaki trafik şifrelenmeli; servisler birbirini doğrulamalıdır. API anahtarları gateway kodunda veya politika dosyasında tutulmamalı, ayrı bir secret yönetim katmanından alınmalıdır.
Tenant izolasyonu
Token eşlemeleri, cache anahtarları ve politika sorguları organizasyon bağlamıyla isimlendirilmelidir. Bir tenant'ın token'ının başka tenant isteğinde çözülmesi kritik bir izolasyon ihlalidir.
Nasıl test edilir?
En az şu test sınıflarını otomatikleştirin:
| Test | Beklenti |
|---|---|
| Desteklenen her hassas veri türü | Doğru sınıf ve doğru eylem |
| Noktalama/boşluk/format varyasyonu | Tutarlı tespit |
| Aynı değerin tekrarı | Kararlı token eşlemesi |
| Birden fazla kişi veya hesap | Token'lar birbirine karışmaz |
| TR/EN ve kurum sözlüğü | Dil ve alan terimleri korunur |
| JSON, Markdown, tablo | Yapı bozulmaz |
| Büyük payload | Limit ve zaman aşımı güvenli çalışır |
| Politika servisi kesintisi | Tanımlı fail-closed davranışı |
| Yetkisiz geri yükleme | Gerçek değer açılmaz |
| Tenant'lar arası deneme | İzolasyon korunur |
| Streaming yanıt | Parçalı token güvenli çözülür |
| Log ve trace incelemesi | Ham hassas veri bulunmaz |
Test verisi sentetik olmalıdır. Üretimden kopyalanmış gerçek kişisel veriyi güvenlik test paketine taşımak, çözülmek istenen problemin kendisini yeniden üretir.
İzlenebilirlik ve metrikler
Gateway'in değerini yalnız toplam istek sayısıyla ölçmeyin. Aşağıdaki metrikler daha anlamlıdır:
- veri türü ve politika bazında tespit/maskeleme sayısı,
- engellenen egress oranı,
- politika eşleşmeyen istek sayısı,
- reversible eşleme süresi ve başarısız geri yükleme,
- provider/route bazında gecikme,
- tespit motoru hata ve timeout oranı,
- false-positive ve false-negative örneklerinden türetilen kalite ölçümleri,
- politika sürümüne göre davranış değişimi.
Metrik etiketlerinde gerçek hassas değer kullanılmamalıdır. Yüksek cardinality oluşturan request veya kullanıcı tanımlayıcıları da kontrollü ele alınmalıdır.
Olay senaryoları
Hassas değer harici sağlayıcıya ulaştı
İlgili route'u durdurun, request ve politika sürümünü belirleyin, ham veriyi daha fazla sisteme kopyalamadan log zincirini inceleyin. Tespit kuralını düzeltmek kadar gateway öncesi log ve tool yollarını da kontrol edin.
Maskeleme iş sonucunu bozuyor
Önce gerçek değerin model görevi için gerekli olup olmadığını sorgulayın. Gerekliyse veri türünü koruyan daha anlamlı token, yapılandırılmış alan işleme veya onaylı yerel route kullanın. Koruma seviyesini global olarak düşürmek son seçenek bile olmamalıdır.
Geri yükleme başarısız
Ham değeri kullanıcıya veya loga yazdıran bir fallback uygulamayın. Yanıtı güvenli biçimde işaretleyin, eşleme yaşam süresi ve tenant/request bağlamını inceleyin, gerekirse işlemi yeniden başlatın.
Knowentra ile uygulama yaklaşımı
Knowentra'da LLM Secure Gateway, kurumsal politika ile model egress'i arasındaki uygulama noktasıdır. Organizasyon tabanı ve departman kuralları birlikte değerlendirilir; daha sıkı kural etkili olur. Gateway, harici sağlayıcıya giden prompt'taki yapılandırılmış hassas değerleri maskelemeye ve izin verilen akışlarda kontrollü geri yüklemeye odaklanır.
Ürün sürümüne ve etkin modüllere göre desteklenen veri türleri ile çalışma modları değişebilir. Bu nedenle üretime çıkmadan önce yönetim arayüzünüzdeki güncel yetenekleri doğrulayın ve kendi veri sözlüğünüzle test edin.
Üretime geçiş kontrol listesi
- Harici model egress noktaları envantere alındı.
- Veri sınıfları ve sahipleri tanımlandı.
- Organizasyon ve departman politika hiyerarşisi test edildi.
- Engelleme, irreversible ve reversible kullanım koşulları belirlendi.
- Politika yokluğu ve servis kesintisi için fail-closed davranışı doğrulandı.
- Token eşlemeleri kısa süreli ve tenant bazında izole edildi.
- Prompt, cevap ve mapping değerleri log/trace sistemlerinden çıkarıldı.
- Tool çağrıları, dosyalar ve streaming yolları kapsama alındı.
- Sentetik regresyon veri seti CI sürecine eklendi.
- Yanlış pozitif/negatif inceleme süreci ve sahipleri tanımlandı.
- Olay müdahale runbook'u hazırlandı.
- Sağlayıcı sözleşmeleri ve veri işleme koşulları ilgili ekiplerce doğrulandı.
Sonuç
LLM Secure Gateway'in değeri “AI çağrılarını tek bir yerden geçirmekten” değil, kurumsal veri çıkış kararını her çağrıda tutarlı ve denetlenebilir biçimde uygulamaktan gelir. Doğru konuma yerleştirildiğinde hassas veriyi minimize eder; fakat yetki, guardrail, secret yönetimi, izleme ve olay müdahalesinin yerini almaz.
İyi tasarlanmış bir gateway, iş ekiplerinin onaylı model seçeneklerinden yararlanırken güvenlik ekibinin “hangi veri, hangi politikayla, hangi route'a gitti?” sorusuna kanıtla cevap vermesini sağlar.