Invisible Unicode that slips past spam filters also fools AI code review

What Microsoft flagged

According to a post on dev.to by Cole Halton, Microsoft has flagged that ASCII smuggling — a technique originally aimed at attacking AI systems — is being repurposed by spammers to move invisible text past email filters. The mechanism relies on Unicode tag characters such as U+E0041, which a renderer displays as an ordinary “A” while an invisible payload travels underneath. The human eye and the text filter each effectively see a different document, and neither checks whether the two views match.

The same gap sits inside AI code review

The post argues that an identical weakness exists in how AI-generated code gets reviewed. A coding agent produces a patch. An AI reviewer fetches that patch and analyzes it as text. If a line in the patch contains an invisible Unicode character, the reviewer interprets it as the plain ASCII equivalent and moves on. Halton's core point is that nothing in this pipeline inspects the raw bytes, so nothing ever notices the discrepancy.

Human reviewers are no better positioned: they read the diff as rendered, and the rendering is precisely where the disguise lives.

It also distorts evaluation

Halton frames this as an eval-design problem too. If two copies of a string differ only in invisible codepoints, a benchmark will score them identically, and the copy carrying the hidden payload sails through. What ends up being measured is the reviewer's interpretation of a clean-looking diff rather than the bytes that actually exist in the repository — which means metrics for AI reviewers can overstate how much scrutiny the code actually received.

The fix runs before the model sees the diff

The remedy the post proposes is unglamorous but effective: normalize every diff at intake. Strip or flag anything outside a strict allowlist of printable ASCII, plus whatever specific non-ASCII the language legitimately requires — accented characters inside string literals, for example. The ordering matters: run this check before handing the diff to the model, not as an after-the-fact audit. That single step forces the reviewer to see what is literally in the file instead of a tidied-up version of it, and it turns a whole category of hidden-payload tricks — including prompt payloads tucked into identifiers or comments — into plain sight.

Why it matters

The story is less about email spam than about a structural seam shared by every text-processing system that trusts its renderer. Email filters, code review tools, and AI reviewers all operate on a representation that can diverge from the underlying bytes, and an attacker only needs that divergence to exist once. Halton's closing argument is blunt: a reviewer that never looks at the bytes it was handed is effectively reviewing its own impression of the code rather than the code itself. For teams building pipelines around AI-generated code, byte-level normalization at intake is cheap to implement, cheap to verify, and quietly eliminates a failure mode that neither humans nor models will catch on their own.

One caveat worth noting: the Microsoft report is cited secondhand through the dev.to post, and the link to AI code review is the author's analysis rather than a documented attack observed in the wild.