5 keystrokes that defeat a privacy filter

Every email security control that reads text makes a quiet assumption: that the characters a machine sees are the same ones a human reads. This article breaks that assumption in about thirty seconds. With five keystrokes, swapping a handful of ordinary letters for visually identical Unicode "confusables," an attacker can render a sentence that looks perfectly normal to any reader while becoming invisible to the PII detectors, DLP filters, and threat classifiers meant to catch it. For security professionals, this isn't a clever party trick.

Homoglyph substitution is a well-documented technique in phishing and brand impersonation, but its effectiveness against modern classifiers exposes an architectural weakness shared by nearly every classifier that operates on raw, un-normalized text. Understanding how the attack works, and why defending against it means normalizing text before it's ever classified, is essential for anyone responsible for keeping malicious content out and sensitive data in.

The demo

There's a demo you can run yourself in about 30 seconds. Open a modern PII-redaction filter designed to detect and redact sensitive email addresses and phone numbers (such as OpenAI's privacy filter, which can be demoed here), and feed it this:

Email me at alice@example.com or call 415-555-0101.

It performs as expected: the email address and phone number are flagged as sensitive PII ready to be masked.

Now feed it this variation:

Email mе at аlice＠example.com or сaⅼⅼ 415‑555-0101.

The output sails straight through. No email detected, no phone number detected, and nothing redacted.

To human eyes, the two lines appear identical. To the filter, the second input contains no PII at all. That divergence between human visual perception and machine tokenization is a central vulnerability in NLP pipelines, particularly for detection and security systems.

What actually happened

The second string isn't oddly spaced plain text. It uses homoglyph substitution: standard ASCII characters replaced with visually identical Unicode confusables:

• The e in "me" is Cyrillic е (U+0435), not Latin e (U+0065).
• The a in "alice" is Cyrillic а (U+0430).
• The @ is a fullwidth commercial at (U+FF20), not ASCII.
• The c in "call" is Cyrillic с (U+0441), and the two ls are small roman numeral fifty (U+217C), which renders as a lowercase L.
• The first hyphen in the phone number is non-breaking (U+2011); the second is standard ASCII.

These glyphs ship with standard font sets and paste cleanly from any text input. Sans-serif fonts, which nearly every email client uses, widen the overlap: a lowercase l, an uppercase I, and a Roman numeral all reduce to the same vertical stroke. 

Detectors built on naive ASCII regular expressions or subword tokenizers (BPE, WordPiece) break down here. Cross-script homoglyphs split words into unexpected tokens and disrupt pattern boundaries, so the model never sees a sequence it recognizes as sensitive data. The redaction logic never fires.

Real-world impact in email security

While this demonstration uses a synthetic PII filter, homoglyph attacks have a long, documented history of real-world exploitation in email security and threat detection.

Lookalike domains built using Cyrillic and Greek characters have been used to impersonate brands and organizations for years. What this privacy filter demo illustrates is a broader architectural issue: any classifier operating on raw, un-normalized text inherits Unicode's entire character complexity as an attack surface.

For example, as shown in Figure 1, in phishing campaigns, using a subject line like Fw: lNV-O-991-09 (substituting a lowercase l for an uppercase I) circumvents simple keyword and pattern matching on INV. Because desktop, web, and mobile email clients almost universally render subject lines and message headers in sans-serif fonts, the lowercase l and uppercase I are visually indistinguishable to the recipient.

Figure 1: Email using glyph for evasion

Consider how this impacts core email security capabilities:

• DLP and PII detection: Exfiltrating sensitive data past content filters by re-encoding characters with homoglyphs, relying on downstream mail clients or renderers to display them legibly to the end user.
• BEC and impersonation detection: Display names or payment instructions that render as "Accounts Payable" to a reader, but tokenize as out-of-vocabulary noise to the classification model.
• Brand and domain spoofing: Sender strings or URLs engineered to be visually indistinguishable from legitimate targets while bypassing string-matching controls.

The core takeaway: adversaries rarely need to attack a model's underlying neural architecture. They only need to violate the implicit assumption that the byte or token sequence received by the model matches the visual representation perceived by a human.

Building adversarial robustness into text classifiers

Most text classification models are evaluated on clean, canonical benchmark datasets. However, real-world inputs in threat detection routinely depart from clean distributions. Building resilient detection pipelines requires treating adversarial inputs as a standard design constraint. Key engineering controls include:

Implement multi-stage normalization

Standard Unicode NFKC normalization collapses compatibility characters (such as fullwidth characters like ＠ (U+FF20), Roman numerals like ⅼ (U+217C), and non-breaking hyphens) back to canonical ASCII form. However, NFKC does not convert cross-script homoglyphs like Cyrillic а (U+0430) to Latin a (U+0061). To resolve cross-script confusables, pipelines must explicitly apply Unicode Technical Standard #39 (UTS #39) confusable mapping or skeleton algorithms prior to tokenization.

Apply defense in depth

While character normalization resolves direct confusable swaps, it does not eliminate zero-width joiners, bidirectional overrides, or novel character-level manipulations. Text classification should serve as one signal among multiple detection layers rather than a single point of failure.

Incorporate automated adversarial evaluation

Models should be continuously benchmarked against character- and token-level perturbation suites. Automated search methods that identify minimal character edits capable of flipping model predictions surface brittle decision boundaries and reveal gaps in preprocessing pipelines.

Retrain models on perturbed inputs

Adversarial examples generated during red-teaming provide valuable training data. Incorporating adversarial and perturbed variants into training pipelines improves model stability against distribution shifts and evasion techniques.

The bottom line

Evading un-normalized text classifiers requires minimal technical overhead, often requiring nothing more than a character substitution lookup table. Consequently, defenders cannot rely solely on larger model parameters or clean-data benchmark performance.

Long-term resilience against text-based evasion requires pipeline design that accounts for Unicode ambiguity from the first stage of preprocessing. In threat detection and security engineering, raw text must always be treated as untrusted input.