Unicode Shield

A message can look completely ordinary in the chat bubble and still carry instructions you'll never see. The human reads one sentence. The model reads another. That gap is the whole bug.

I ran into this building agents at Photon, where the interface is iMessage. A text comes in and you do the obvious thing — take message.text and hand it to the model. It took me longer than I'd like to admit to internalize that message.text is not what the user sees. It's the raw Unicode string, invisible characters and all. The bubble renders one thing; the agent ingests another.

The split

Messaging stacks were built for humans, on the assumption that the meaningful part of a message is the part a person can see. That holds right up until an LLM becomes the actual consumer of the string.

The sender sees a normal sentence. Your dashboard shows a normal sentence. Your logs store a normal sentence. But the model doesn't read rendered bubbles — it reads the raw string, zero-width characters and tag blocks included. Every place a human or a log might catch the problem, the message looks fine. By the time the invisible part reaches the prompt, the failure has already happened.

A demo you can try

Here are two lines that look identical to the first sentence of this post.

Example A — zero-width characters embedded in a normal message:

What's the weather today?​⁠

Example B — invisible tag characters appended to a normal message:

What's the weather today?󠀤󠁤󠁥󠁭󠁯

Paste either into a character viewer like this one and the hidden bytes show up. Example A carries U+200B, U+2060, U+FEFF. Example B encodes the (harmless) payload demo in Unicode tag characters. Neither is malicious — they just prove the channel exists.

Why it's worse for an agent

For human-to-human chat, invisible Unicode is a curiosity. For an agent it's an input-integrity hole. LLMs don't separate visible text from invisible text — they tokenize the raw string. If the hidden span carries instructions, the model treats them as legitimate user input.

And it compounds. Store that raw text in conversation memory, replay it next turn, and a one-off injection becomes session poisoning that persists. The same single iMessage can smuggle in an instruction the recipient never sees:

Prompt injection is only the first thing that goes wrong. The same hidden channel enables covert exfiltration — stolen data tucked invisibly into innocent-looking outbound messages — machine-readable side channels riding alongside human chat, and invisible fingerprinting. Same root cause every time: raw Unicode moving through the stack without inspection.

What I built

So I built unicode-shield: a zero-dependency TypeScript normalization layer that sits between the wire and the model. One function, no config:

import { normalize } from "@photon-ai/unicode-shield";
 
const clean = normalize(userInput);

That single call handles the whole zoo:

• Invisible characters — zero-width spaces, BOM, fillers, invisible math operators, and the Unicode tag block (U+E0000–U+E007F) that's the favorite vehicle for hidden instructions.
• Bidi attacks — right-to-left overrides like U+202E that make moc.evil render as live.com. normalize("Click: \u202Emoc.xyz") returns "Click: moc.xyz", exposing the real URL.
• Homoglyphs — Cyrillic, Greek, Armenian, and Cherokee lookalikes folded to Latin. normalize("p\u0430ypal") returns "paypal" — that а was Cyrillic U+0430, and it's why a naive keyword filter sails right past it.
• NFKC bypasses — fullwidth and math-styled Latin collapsed to ASCII, so ＨＡＣＫ becomes HACK.
• Zalgo — stacked combining marks capped (default 3 per base character) so one character can't explode into a token bomb.

Plus control characters, variation selectors, and exotic whitespace — 400+ dangerous codepoints in all, covering the 51 iMessage attack vectors I could find.

When you need visibility instead of silent cleanup, analyze() returns the same clean text plus a finding for every character it touched:

import { analyze } from "@photon-ai/unicode-shield";
 
const result = analyze("p\u0430ypal\u200B\u202E");
// result.text     → "paypal"
// result.dirty    → true
// result.findings → [
//   { type: "confusable", codepoint: 0x430,  name: "CYRILLIC_SMALL_A",       action: "normalized" },
//   { type: "invisible",  codepoint: 0x200B, name: "ZERO_WIDTH_SPACE",       action: "stripped"   },
//   { type: "bidi",       codepoint: 0x202E, name: "RIGHT_TO_LEFT_OVERRIDE", action: "stripped"   },
// ]

That's the part that matters in production: the sanitized text goes to the model, the raw original is preserved for audit, and every suspicious character is logged with its codepoint and name so you can block, warn, or just watch. And because policy isn't one-size-fits-all — strict for an agent pipeline, permissive for a multilingual chat display where people genuinely write in Cyrillic — createShield(options) binds a config once and hands back normalize and analyze bound to it.

Why a library, not a replace()

I shipped this as a package instead of a one-off regex because "sanitize your inputs" doesn't survive contact with a real codebase. Some developers won't know this class of attack exists. Others will scrub before inference but not before logging, memory, or the next automation downstream. The complexity has to live in one place, close to the wire, so nobody has to rediscover it one production incident at a time.

Messaging is becoming a real interface for AI, which means the attack surface of messaging is becoming the attack surface of models. The old assumption — if a message looks safe to a human, it's safe enough — doesn't hold once the model, not the human, is the one reading. Treat the raw string as hostile. Sanitize before inference, inspect before memory, keep the original for audit.