Calling this an AI security story is the wrong frame, and I think that framing is going to cost people money.
The headline making rounds is that ASCII smuggling, a technique once popular for attacking AI, is now being embraced by spammers. Microsoft has seen a sharp increase in its use in phishing campaigns. The finding came out of Microsoft Defender for Office 365 prompt injection protection research, which is how it got filed under the AI beat in the first place.
But the technique itself has nothing to do with AI. It’s a block of Unicode characters that humans can’t see. That’s it. Invisible characters that render as nothing to your eyes but exist as real data to any system parsing the text. Prompt injection was just the first place it got popular, because chatbots made for a good demo. The underlying trick predates the demo and outlives it.
Why this matters for the tools you’re already paying for
I review AI toolkits for a living, which means I spend a lot of time reading vendor security pages. And there’s a pattern I’ve gotten tired of. Vendors bucket threats by which product category they embarrass. Prompt injection goes in the “AI safety” section. Phishing evasion goes in the “email security” section. Different teams, different roadmaps, different quarterly priorities.
ASCII smuggling doesn’t respect that org chart. The same invisible characters that trick a model into ignoring its instructions can hide a malicious payload from a keyword-matching spam filter. One technique, two product categories, and probably two separate teams who each assume the other one is handling it.
That gap is the actual story. Microsoft found this crossover because their prompt injection research and their email security sat close enough together to notice. Not every vendor has that setup.
The questions I’m now asking every tool I test
This changed my evaluation checklist. If you’re assessing anything that ingests text, and in 2026 that’s essentially everything, these are worth asking:
- Does the tool normalize Unicode before processing, or does it pass raw input straight through to the model or the filter?
- If invisible characters are stripped, are they stripped at input, at display, or both? Display-only sanitization looks clean and does nothing.
- Does the security documentation treat prompt injection and content filtering as related problems, or as unrelated checkboxes?
- When you paste text containing invisible Unicode into the tool, can you tell? Can the tool tell you?
That last one is the cheapest test you can run and almost nobody runs it. You don’t need a lab. You need a text sample and five minutes.
The AI framing is doing real damage
Here’s my honest concern. When a technique gets labeled an AI attack, teams that don’t work on AI stop paying attention. Your email admin reads “AI prompt injection tactic” and reasonably concludes it’s someone else’s problem. Then the phishing lands.
The reverse also happens. AI teams see “email spam evasion” and file it under legacy security. Neither group owns it. The technique sits in the seam.
Spammers, meanwhile, are pragmatic. They don’t care about taxonomy. They found something that gets past filters and they’re using it more. That’s not clever, it’s just what happens when a technique gets published and works. The interesting question isn’t why spammers adopted it. It’s why anyone assumed they wouldn’t.
What I’d actually do about it
Not much that’s exotic. Unicode normalization on input is a solved engineering problem, and any tool handling untrusted text should already be doing it. The reason it often isn’t done is that invisible characters are invisible, so nobody notices they’re missing from the sanitization pipeline until someone writes a blog post.
If you’re building on top of AI tooling, treat any text that arrives from outside your system as hostile data, not as content. That includes text a model generated from other text it read. The chain matters more than the endpoint.
If you’re buying tooling, ask vendors the Unicode question directly and pay attention to whether they understand it or reach for a prepared answer about their AI safety commitments. The difference tells you a lot.
The takeaway
Microsoft’s finding is useful precisely because it’s unglamorous. No new exploit, no novel research, just an existing trick crossing from one victim category into another because nobody built a wall between them.
My read is that this is the first of several such crossovers. Techniques developed to poke at language models are going to keep finding second lives against conventional systems, because both categories parse text and text is where the ambiguity lives. Treating AI security as a separate discipline from ordinary application security was always a temporary convenience. This is a reasonable moment to stop.
🕒 Published: