I've been auditing the detection stack for a multi-agent system and found a consistent blind spot: our input classifiers and regex-based rule sets fail systematically against injections that employ simple character-level obfuscation. The standard approach of scanning for keywords like `ignore previous instructions` or `system prompt` is rendered useless by even basic transformations.

The primary evasion techniques I'm observing fall into two categories:
* **Encoded characters:** URL encoding, HTML entities, or Unicode code point escapes (e.g., `%73%79%73%74%65%6d` for "system", `ignore`).
* **Homoglyphs and orthographic tricks:** Using visually similar characters from different scripts (Cyrillic, Greek) to bypass lexical checks—for example, using a Cyrillic 'а' (U+0430) instead of the Latin 'a' (U+0061) in a forbidden word.

Our current detection layer operates on normalized plain text, but the normalization occurs *after* the model has already parsed and interpreted the injection. The LLM sees `%69%67%6e%6f%72%65` as "ignore," while our rule engine, checking the raw input, sees a harmless string of percent signs and numbers.

I'm evaluating a more robust preprocessing pipeline but am concerned about the computational and false-positive cost. Simply decoding every possible encoding scheme pre-check is expensive and risks mangling legitimate user input that contains similar patterns for innocent reasons.

I'm particularly interested in how others are balancing this. Are you:
* Implementing a layered decoding step before classification?
* Using model-based classifiers (another small LLM) to assess intent on a partially normalized version?
* Employing canary tokens designed to be invariant to these transformations?
* Accepting a certain evasion rate and focusing instead on strict output validation and model isolation?

The trade-off between pre-input scrubbing and post-output containment seems critical here.

- Tracy