How much of the text your bot just processed do you actually think you can see?
That question stopped being academic for me a few months ago, and it should stop being academic for you too. ASCII smuggling — the trick of embedding Unicode characters that render as nothing to human eyes but still land in the string your parser receives — has made a career change. It started as a prompt injection technique aimed at language models. According to Microsoft, spammers picked it up, with a sharp increase in use starting February 2026, now aiming it at email filters instead.
As someone who spends most of my week wiring bots to inboxes, ticket queues, and chat platforms, this crossover is the part that interests me. It’s not a new attack. It’s the same attack pointed at a different reader.
Same payload, different victim
The mechanics are simple enough that you can build a demo in an afternoon. Certain Unicode ranges produce characters that don’t display in most rendering contexts. Drop them between the letters of a word and a human sees one thing while a byte-level matcher sees something entirely different. A filter looking for a suspicious brand name or a known phishing phrase scans for a contiguous string. The string isn’t contiguous anymore. Nothing matches. The message goes through.
Against a language model, the goal was the reverse: hide instructions that a human reviewer would never spot but the model would happily obey. Against an email filter, the goal is hiding a signature the filter would flag but the human recipient reads normally. One technique, two opposite objectives, and both of them work because we built two different readers for the same bytes.
Microsoft’s finding reportedly came out of prompt injection protection research for Defender for Office 365, which is a detail I keep turning over. The defense built for AI-specific abuse is what surfaced the traditional phishing version. That’s a useful signal about where detection work is heading.
Why this hits bot builders harder than most
If you’re building anything that ingests text and acts on it, you own a version of this problem. Think about the pipelines we assemble without much ceremony:
- An email-to-ticket bot that classifies incoming messages by keyword before a human ever looks
- A support agent that reads a customer message and decides whether to escalate
- A moderation bot matching against a blocklist
- Any retrieval step that pulls a document into a prompt without sanitizing it first
- Webhook handlers that route based on subject-line patterns
Every one of those has a gap between what a person would see and what the code receives. That gap is the whole attack surface. And most of us never wrote a normalization step because we never had a reason to think about it. The text looked fine in the logs. Of course it did.
What I’d actually change in the code
My default now is to treat all incoming text as untrusted bytes rather than readable content, and to normalize before anything else touches it. A few habits worth adopting:
- Strip or flag zero-width and invisible characters at ingestion. Not at classification time, not at display time. At the edge, before your first branch.
- Apply Unicode normalization consistently. One canonical form across your whole pipeline. Mismatched normalization between the filter and the consumer is how these gaps open in the first place.
- Log the raw and normalized versions separately. If they diverge, that’s a signal on its own. Invisible characters in a customer support email are not a typo.
- Stop trusting keyword matching as a security control. It was never solid against a motivated sender, and now the bypass is trivial to script.
- Treat retrieved documents as hostile input. If your bot pulls text from an email, a PDF, or a scraped page into a prompt, sanitize that text with the same suspicion you’d apply to a form field.
None of this is difficult work. It’s a handful of lines in most stacks. The reason it doesn’t exist in your codebase is that the threat lived in a different neighborhood until recently.
The pattern worth watching
What I take from Microsoft’s telemetry isn’t really about email. It’s about direction of travel. A technique developed to manipulate AI systems got repurposed for a decades-old attack category, and it worked well enough that adoption climbed fast. There’s no reason to expect that to be a one-off. The tricks people are inventing to fool models are, at bottom, tricks about the difference between rendering and parsing. That difference exists everywhere.
So the practical takeaway for anyone building bots: your input layer is a security boundary whether you designed it that way or not. Invisible characters are one instance of a broader class of problem, which is that your code and your users are reading different documents. Close that gap deliberately, and you’ll be ahead of whatever the next version of this looks like.
Go check what your parser actually sees. I’d bet it’s not what you assumed.
🕒 Published: