I Red-Teamed My Own LLM Security Gateway: Every Gap, Four Passes

An engineer spent four sessions attacking his own transparent security proxy for LLM traffic — a deterministic, regex-based gateway that scans requests and responses for leaked secrets, PII, jailbreaks, and exfiltration attempts. Early passes surfaced real gaps: Unicode tag-character smuggling that hid instructions from both humans and naive regex, a false positive that blocked a legitimate question about preventing exfiltration, narrow base64 decode-and-execute matching, missing ChatML/control-token injection detection, and blind spots around real-world exfil domains (webhook.site, ngrok, Burp Collaborator) and cloud metadata SSRF endpoints like AWS IMDS and GCP's metadata service.

The most consequential finding was on the response side. While the request path carried 70-plus secret-detection rules, the response path had only a handful — catching just 5 of 20 malicious outputs, missing OpenAI/Anthropic/Stripe keys, private-key blocks, and system-prompt disclosures entirely. Worse, even flagged leaks were still delivered to the client unchanged; detection was logged, not enforced. The fix reused request-side format rules on egress traffic, bringing detection to 20/20, plus a new opt-in RESPONSE_BLOCK mode that returns a 403 with the leak stripped instead of passing it through.

Every fix shipped paired with a benign-traffic test to avoid the false positives that make security tools get ripped out — a discipline the piece treats as more important than the catch rate itself. But a fourth pass exposed an unresolved gap: response blocking worked for standard replies but not for streaming output, which is how most production LLM applications actually respond — a reminder that deterministic pattern matching raises attacker cost without closing the architectural gap entirely.