Demo 06
~3 min
Invisible Unicode Guardrails
Your code review looks clean. Every character is visible. But 128 hidden codepoints are encoding a message you cannot see. Can your tooling tell the difference?
Hidden content passes code review
→
Render-safe analysis blocks it
The Problem
In March 2026, the Glassworm campaign targeted GitHub, npm, and VS Code extension marketplaces with packages containing invisible Unicode. The code looked normal in every editor and review tool. But the bytes told a different story: variation selectors — characters designed to be invisible — encoded hidden instructions that a runtime decoder would reconstruct and execute.
The packages were signed. The hashes were valid. The code reviews passed. The attack succeeded because nobody’s tooling checked whether the rendered view and the byte view told the same story.
What You Will See
Safe Sample — No Hidden Content
============================================================
✅ safe-visible.js [PASS]
============================================================
SHA-256: d7dd00740f0860f7...40fcd46f
Codepoints: 708 total, 0 invisible
No invisible or non-rendering Unicode characters detected.
All codepoints are standard visible characters.
Artifacts written:
analysis.safe.json
attestation.safe.json
dbom.safe.json
Flagged Sample — 128 Hidden Variation Selectors
============================================================
❌ flagged-invisible.js [FAIL]
============================================================
SHA-256: 0dba71c75cdeefbb...5c27d85c
Codepoints: 896 total, 128 invisible
Families: variation_selectors, variation_selectors_supplement
Ranges: U+E0100-U+E01EF, U+FE00-U+FE0F
Pattern: variation-selector-encoding (severity: high)
Policy failed because the artifact contains non-rendering
Unicode characters that materially affect byte content while
being difficult to inspect in ordinary rendered views.
Found 128 invisible codepoints across 2 Unicode families.
Artifacts written:
analysis.flagged.json
attestation.flagged.json
dbom.flagged.json
Policy Summary
============================================================
Policy Summary
============================================================
safe-visible.js: PASS
flagged-invisible.js: FAIL
Trusted bytes are not the same thing as trusted appearance.
Makoto render-safe verification catches what signatures
and hashes alone cannot.
Run It
$ git clone https://github.com/makoto-project/makoto
$ cd makoto/demos/06-invisible-unicode-guardrails
$ uv run run.py
Key Insight: Provenance tells you where an artifact came from. Signatures tell you who vouched for it. Render-safe analysis tells you what is actually present in the bytes — even when a reviewer might not see it. All three are needed.
What Else This Handles
- Zero-width characters hiding content in configuration files and prompts
- Bidi control abuse making code flow appear different from actual execution order
- Tag character sequences embedding metadata invisible to standard rendering
- Any Unicode family where the rendered view diverges from the byte-level content
See also: Invisible Unicode example for a visual walkthrough, and D9: Display-Layer Obfuscation in the threat model.