Character-level evasion is a prompt attack that tries to bypass a model’s safety or parsing rules by changing individual letters, symbols, spacing, or encoding. It works by making harmful instructions look different to filters while still readable to a human or the model, especially when text normalisation is weak.
How character-level evasion works
Character-level evasion is a prompt attack that exploits weak text normalisation. By altering letters, symbols, spacing, or encoding, an attacker can make a harmful instruction look different to a filter while keeping it understandable to a person or model.
The technique is effective because many safety layers and parsers rely on exact token shapes, substring matching, or brittle preprocessing. If the same intent can be preserved while the surface form changes, defensive rules may fail to recognise what the text is doing.
Why it is effective against safety and parsing controls
This attack does not need to defeat the model’s reasoning directly. It often succeeds by targeting the surrounding pipeline, such as moderation filters, input sanitizers, classifiers, or downstream parsers that assume text will arrive in a clean canonical form.
That makes normalisation a security boundary. When preprocessing is inconsistent across components, one layer may see harmless-looking text while another reconstructs the intended instruction. Systems that accept mixed encodings, decorative punctuation, homoglyphs, or unusual whitespace are especially exposed.
Character-level evasion is closely related to input ambiguity, but the security concern is broader than simple obfuscation. It can also be used to bypass policy enforcement, hide malicious intent in logs, or trigger parsing differentials between the user-facing and machine-facing paths.
Where organisations are exposed
Exposure is highest where a model ingests untrusted user text and the surrounding stack applies policy checks before generation, routing, or tool use. Chat interfaces, agent runtimes, content moderation services, and text-to-action pipelines can all be affected if they process the same input differently.
It becomes more dangerous when the text is later transformed into commands, search queries, code, tickets, or tool invocations. In those cases, a small character change can move an instruction past a guardrail and into an operational workflow that was never intended to receive it.
Defenders should also treat logging and review systems as part of the exposure surface. If the application stores the obfuscated form but enforcement happens on a different normalised form, investigators may miss the true intent unless both representations are preserved and compared.
What resilient handling looks like
Resilient systems canonicalise text early and consistently, then apply safety, policy, and parsing decisions to the same normalised representation. They also avoid relying on exact string matches alone, because exact-match logic is fragile against spacing tricks, Unicode variants, and encoding games.
Review pipelines should compare raw and normalised inputs, preserve evidence of the original form, and reject or flag inputs that depend on unusual character composition to be understood. When text drives downstream automation, the safest pattern is to separate untrusted natural language from structured execution fields.
Detection should focus on normalization anomalies, unexpected character classes, and repeated near-duplicate attempts that differ only at the glyph level. In practice, the goal is not to ban every unusual character, but to make the same meaning visible to every control that depends on it.
Risk and Threat Considerations
Character-level evasion matters because it creates a mismatch between what a human sees and what a security control parses. That mismatch can let harmful instructions cross a moderation boundary, reach a tool, or evade review long enough to influence downstream action.
Failure mechanism: The attacker preserves the semantic intent of the prompt while changing its surface form enough to bypass pattern-based filters, weak normalisation, or inconsistent preprocessing across the stack.
Impact: Policy bypass, unsafe tool invocation, hidden malicious content in logs, and unreliable moderation or incident review can follow when the system treats altered text as harmless.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI06 — Memory & Context Poisoning | Character-level evasion can distort prompt context and bypass agent safety checks. |
| Recommendation — Normalize input consistently and validate prompts before they can influence agent memory or context. | ||
| MITRE ATT&CK | T1036 — Masquerading | Altering characters to appear benign is a form of disguising malicious content. |
| Recommendation — Detect disguised content by comparing raw and canonicalized text before enforcement. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The term concerns hostile input shaping and the need to validate text before processing. |
| Recommendation — Apply input validation to reject or normalize adversarially altered text before downstream use. | ||
| OWASP ASVS | V1 — Encoding and Sanitization | The attack exploits weak sanitization and encoding handling in text processing paths. |
| Recommendation — Sanitize and canonicalize untrusted text before any safety or parsing decision. | ||
| NIST CSF 2.0 | PR.DS-1 — Data-at-rest is protected | Protecting the integrity of stored and processed text supports trustworthy handling of altered inputs. |
| Recommendation — Preserve canonical and original input forms so analysis and review remain reliable. | ||
Practitioner Guidance
What to watch for: Treat mixed encodings, homoglyphs, invisible separators, and repeated near-duplicate prompts as signals of adversarial intent when they affect how policy is enforced.
Governance implication: Normalisation rules should be owned as a security control, not as a cosmetic text-processing detail, because they directly affect what the model and its filters can safely interpret.