Kendi LLM Güvenlik Proxy'sini Dört Turda Red Team Testine Soktum

Bir mühendis, kendi geliştirdiği LLM trafiği için şeffaf güvenlik proxy'sini (sızıntı, PII, jailbreak ve prompt injection tespiti yapan deterministik regex tabanlı bir katman) dört ayrı oturumda kendi saldırılarıyla test etti. İlk turlarda Unicode etiket karakterleriyle gizlenen komutlar, 'exfiltration' kelimesinin bağlamsız yakalanması yüzünden meşru güvenlik sorularının engellenmesi ve base64 kod çözme varyasyonları gibi açıklar bulundu; her düzeltme hem saldırı hem de zararsız trafik testiyle doğrulandı.

Asıl kritik bulgu yanıt tarafında çıktı: istek tarafında 70'in üzerinde sır (secret) kuralı varken yanıt tarafında sadece birkaç tanesi vardı ve 20 kötü amaçlı çıktıdan yalnızca 5'i yakalanabildi. Daha da vahimi, yakalanan sızıntılar bile istemciye olduğu gibi iletiliyordu — araç sızıntıyı tespit edip loglasa da engellemiyordu. İstek tarafı kurallarının çıkışa (egress) uygulanmasıyla oran 20/20'ye çıkarıldı ve isteğe bağlı RESPONSE_BLOCK özelliğiyle gerçek engelleme (403 yanıtı, sızan içerik olmadan) eklendi.

Bu yaklaşım, deterministik regex tabanlı savunmaların bir 'çözüm' değil maliyet artırıcı bir katman olduğunu kabul ederek, LLM güvenlik araçlarında yanlış pozitif/yanlış negatif dengesinin nasıl sistematik olarak test edilmesi gerektiğine dair somut bir metodoloji sunuyor. Ancak dördüncü turda ortaya çıkan bir sorun — streaming yanıtlarda engelleme mekanizmasının çalışmaması — mühendislere production LLM uygulamalarının çoğunun stream kullandığını ve bu boşluğun henüz kapatılmadığını hatırlatıyor.