Character-Level Evasion

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.

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.

Related resources from NHI Mgmt Group

• What is the difference between character-level OCR and word-level OCR in document processing?
• Kernel-level defense evasion
• Protocol-Level Evasion
• Character-Level NLP Model