My LLM Security Gateway Red-Teaming Results

I built a security gateway for LLM traffic that acts as a transparent, OpenAI-compatible proxy via the OPENAI_BASE_URL environment variable. It scans requests and responses for PII, secrets, jailbreaks, and prompt injection using deterministic pattern detection on the hot path—no database, no telemetry, and no model in the loop.

I want to be clear: deterministic pattern detection isn't a silver bullet. As Simon Willison has argued, you can't simply filter your way out of prompt injection; the real fix is architectural. A regex layer just raises the cost of an attack. To test this, I ran four red-teaming sessions against my own gateway, attempting to slip secrets and jailbreaks past it while ensuring my fixes didn't trigger false positives on legitimate traffic.

The Testing Methodology

I used two distinct corpora against a live instance:

Attack corpus: Payloads designed to be blocked.

Benign corpus: Realistic prompts that must pass through.

A detection gap is a false negative (attack succeeds), but a false positive (benign prompt blocked) is arguably more damaging because it drives users to disable the tool. Every fix I implemented required passing both an attack test and a benign-guard test. The goal wasn't just "does it catch the attack," but "does it catch the attack without catching the question about the attack?"

The engine uses Rust's regex crate, which utilizes a linear-time DFA. This means no backtracking, no lookaround, and no backreferences. This constraint is vital because it dictates what is actually solvable via regex.

Pass 1: Request-side Warm-up

Initial test: 27 attacks, 20 benign. I found a few issues that were solvable with clean fixes.

ASCII Smuggling: Attackers were hiding instructions within Unicode tag characters (U+E00xx). These are invisible to humans and naive regex but perfectly readable to a trained model. I solved this via normalization—folding tag characters back to ASCII before the matching phase so the smuggled text becomes visible to the rules.

The "Exfiltration" False Positive: My initial rule for data exfiltration triggered on the word exfiltration alone. This meant a user asking "How do I prevent data exfiltration?" was blocked. I refined the rule to look for intent: exfiltrate + a target (to/via/into) + data, rather than the noun in isolation.

Base64 Logic: My "decode-and-execute" rule was too narrow. Attackers were using "decode and follow" or "decode and obey." I broadened the verb set but anchored it to an actual Base64 blob to ensure a developer asking "how do I decode base64 in Python" wouldn't be blocked.

Pass 2: Advanced Request-side Tradecraft

Test: 33 attacks, 28 benign. This round was harder, and 15 payloads initially got through. Ten were fixable bugs, while the others were absorbed once I implemented better intent-anchored gates.

One notable discovery was ChatML / control-token injection. Users were attempting to forge system turns by injecting model-specific role delimiters like system or Llama's [INST]. I had to implement a new rule that checks for these tokens within user messages, but I had to gate it carefully so that a technical document simply mentioning the tokens wouldn't be flagged as an attack.

The core lesson for anyone building AI workflows or LLM agents is that security at the proxy level is about managing the tension between strictness and utility. If you're building a production-grade deployment, you need to treat your security rules with the same rigor as your application code.