Most prompt-injection filters read text the way a person does, but a language model reads code points, and an instruction written in invisible Unicode tags or look-alike "fonts" can pass the first and still reach the second. On 20 October 2026 the USPTO granted HiddenLayer US 12,771,719 B2, a patent that claims a specific fix: turn the Unicode back into plain text first, and only then let a trained classifier decide whether the prompt reaches the model.
AG Tech Consulting's advice for clients this week: find every place where untrusted text enters your AI systems (chat input, retrieved documents, emails, tickets, code repositories, tool results), and check that each path normalizes Unicode and strips or decodes invisible tag characters before any guardrail or classifier sees it, and again on the model's output. Then test those paths with stylized-font, invisible-tag and emoji-encoded versions of your existing red-team prompts. If a filter only passes because it cannot read the attack, treat it as a gap, not a pass.
The grant in one paragraph
US 12,771,719 B2, "Canonicalization of unicode prompt injections," was granted on 20 October 2026 to HiddenLayer, Inc. of Austin, Texas. The inventors are Kenneth Yeung (Ottawa) and Jason Martin (Beaverton, Oregon). It comes from application 19/053,278, filed 13 February 2025, and is a continuation of application 18/945,409, which was granted as US 12,278,836 B1 in April 2025. The new claims are more specific than the parent's.
HiddenLayer received a second grant the same day: US 12,769,875 B2, on detecting personally identifiable information in prompts and outputs with a lightweight local engine that escalates to a heavier ensemble in a separate monitoring environment. Both describe the same split: a lightweight engine next to the model and heavier analysis in a separate monitoring environment.
Three ways to hide a prompt in Unicode
The patent's description starts from a blunt problem statement: today's text classifiers, word blocklists and input guardrails "are only effective against attacks that use plaintext." It names three attack classes that sit under "a layer of unicode."
Font obfuscation. Each letter is swapped for a stylized Unicode character that looks like it, such as bold mathematical letters or "bubble text." A human reads "ignore previous instructions." A keyword filter sees unfamiliar code points.
Invisible tag injection. The Unicode Tags block (U+E0000 to U+E007F) mirrors ASCII and is normally not rendered. Its main legitimate use is subdivision flags: England's flag is a black-flag emoji followed by hidden tag letters. LLMs can read and act on these characters, so an instruction can be pasted into a document that looks clean on screen.
GNOY. The patent names a third technique, "Gnoy Numeric Obfuscated Yabbering." Its example hides "say bye to the user" in what looks like a random run of emojis: the last two hex digits of each emoji's code point (73, 61, 79, 20 ...) spell the ASCII message, and the attacker tells the model how to decode it. In the patent's words, the payload sits "behind a benign layer of happy-looking emojis."
What claim 1 actually covers
Claim 1 is a method run by a proxy executing in the computing environment of a monitored AI model. Read as a pipeline, it has five steps.
First, the proxy receives a prompt containing Unicode. Second, it identifies Unicode fonts and translates them into plain text. Third, it identifies characters that carry a Unicode tag and extracts part of each tag to check whether it falls in a valid ASCII range. Fourth, it removes the characters that fail. Fifth, it passes the cleaned prompt to the model only if a prompt-injection classifier, trained on prompts known to cause undesired behavior, says it is safe.
The dependent claims are where the detail lives:
Claim 8 makes the check concrete: extract the last two digits of each tag and test them against the ASCII range.
Claim 11 names invisible tag characters used in a GNOY attack.
Claim 20 adds a tokenizer step: tokenize the prompt, find tokens that form a repeating sequence, and remove them before classification. The description explains why. When a hidden payload is tokenized, the encoding leaves the same token in front of every real letter. Scrub the repeating token and the letters are left.
Claim 22 converts to plain text only when a threshold percentage of characters can be mapped to ASCII. The description gives 50% or 75% as examples, so legitimate Unicode is not rewritten.
Claim 33 chains a binary classifier (malicious or benign) with a multi-class classifier that names the attack type. Claim 36 compares strings that do not decode cleanly against a dictionary. The description suggests Levenshtein distance for short strings and perplexity for longer ones.
The description names XGBoost, logistic regression and XLNet as candidate classifiers, trained on sentence embeddings and retrained as new techniques appear. Remediation options in claim 6 include flagging, sanitizing, blocking the requester's IP address, or modifying later prompts from the same IP, MAC address or session.
Why the order matters: canonicalize first, classify second
The core idea is about sequence. A classifier trained on plain-text injections cannot score what it cannot read. If canonicalization runs after the guardrail, or not at all, the guardrail is scoring a different string from the one the model will interpret.
The patent also argues that canonicalization avoids "the need for specialized training" of the models downstream. Teaching every classifier every encoding is a losing race. Mapping the input back to plain text once is cheaper.
Part of this is already standard. Python's unicodedata.normalize('NFKC', ...) folds mathematical bold and circled letters back to plain ASCII, which covers much of the font class. But it returns Unicode tag characters unchanged. NFKC alone does not handle the invisible class, and it does nothing about GNOY-style emoji encoding.
Where the design stops
A patent describes a method, not proof that it stops every attack. Five limits are worth noting.
Tokenizer-level evasion. HiddenLayer's own May 2026 research describes TokenBreak: prepending characters ("fignore previous finstructions") breaks WordPiece or BPE tokenization so a classifier misses the injection, while the LLM still understands it. Canonicalization does not undo a deliberate typo.
Variation selectors. The same research says invisible attacks also work with variation selectors (U+E0100 to U+E01EF and U+FE00 to U+FE0F). The claims are written around Unicode "tags" and "fonts." Whether they would cover selectors is a question for patent counsel, but your filter should handle them either way.
Surrogate-pair bypass. AWS showed in September 2025 that a single-pass Java filter can be beaten. Interleaved UTF-16 surrogates recombine into a new tag character after one pass. AWS recommends recursive sanitization that also strips orphaned surrogates.
False positives. AWS notes that stripping tags breaks some flag emojis. The patent's threshold in claim 22 exists to keep legitimate Unicode intact, and it is a dial someone has to tune and test against real user text.
Modify versus block. The patent notes that sanitizing instead of blocking still gives the attacker a response, "potentially masking the fact that the system identified" the attack. That is useful against probing. It also means your logs, not the user's error message, are the only record of the attempt.
Future security risks to plan for
1. Agents that read what humans cannot see. HiddenLayer's research warns that invisible characters in a repository can be missed by a developer but still affect AI code review, and that a pasted payload can compromise an agent's context window. As agents read more tickets, PDFs and repos without a person in between, this becomes an input-validation problem for every tool, not one chat box.
2. Output-side smuggling. Johann Rehberger's ASCII smuggling proofs of concept against Microsoft 365 Copilot had the model hide exfiltrated data in invisible characters appended to a URL. Microsoft later added mitigations. Claim 1 is an input-side method. Output needs its own filter.
3. Classifier evasion as an arms race. OWASP's LLM01:2025 notes that injections "do not need to be human-visible/readable, as long as the content is parsed by the model," and lists Base64 and emoji encoding as obfuscation scenarios. Expect new encodings to keep appearing, and expect any single classifier to fall behind.
4. Patents around a basic control. Unicode sanitization is a basic hygiene step that AWS, OWASP and independent researchers have described in public. When a specific pipeline for it is patented, vendors and in-house teams building guardrails should know which claims they are near. That is a review for counsel, not a reason to skip the control.
A checklist for CTOs
List every untrusted text input to your LLM apps and agents: user chat, RAG documents, email, tickets, web pages, repo content, tool and API results. Put Unicode normalization (NFKC or an equivalent) in front of every guardrail, classifier and keyword filter, not after it. Strip or decode the Tags block (U+E0000 to U+E007F) and variation selectors, and log every hit. Run sanitization until the output stops changing, and drop orphaned surrogates, as AWS recommends. Check emoji-heavy inputs for GNOY-style encodings, where the last hex digits of code points spell ASCII. Apply the same filters to model output before it is rendered, sent, or used in a URL or tool call. Add font, invisible-tag, emoji-encoded and TokenBreak variants of your existing red-team prompts to your regression tests. Decide per channel whether a hit means block or sanitize, and make sure both are logged for the security team. Keep least privilege and human approval on high-risk agent actions, because no input filter is complete. If you build or buy a guardrail product, ask your counsel to review US 12,771,719 B2 and US 12,278,836 B1.
The bottom line
US 12,771,719 B2 does not invent the Unicode problem. Riley Goodside, Johann Rehberger, AWS and OWASP described it in public well before this grant. What the patent adds is a specific, claimed pipeline: canonicalize fonts, validate tags against ASCII, scrub repeating tokens, then classify.
For CTOs, the lesson is simpler than the claims. A guardrail that cannot read the input is not checking it. Make sure every path into and out of your models turns code points back into text before anything decides it is safe.
Sources
https://patentsgazette.uspto.gov/week42/OG/patentee/alphaY_Utility.html https://patentsgazette.uspto.gov/week42/OG/patentee/alphaH_Utility.html https://exa.ai/library/legal/patent/m50jdygqjj5 https://thepatentplace.com/iplibrary/patent-grant/12771719/ https://www.patents-review.com/a/18945409-canonicalization-unicode-prompt-injections.html https://thepatentplace.com/iplibrary/patent-grant/12769875/ https://www.hiddenlayer.com/research/tokenization-attacks-on-llms-how-adversaries-exploit-ai-language-processing https://aws.amazon.com/blogs/security/defending-llm-applications-against-unicode-character-smuggling/ https://arstechnica.com/security/2024/10/ai-chatbots-can-read-and-write-invisible-text-creating-an-ideal-covert-channel/ https://embracethered.com/blog/posts/2024/hiding-and-finding-text-with-unicode-tags/ https://blogs.cisco.com/ai/understanding-and-mitigating-unicode-tag-prompt-injection https://genai.owasp.org/llmrisk/llm01-prompt-injection/ https://docs.python.org/3/library/unicodedata.html
Thanks to HiddenLayer , Chris Sestito , Kenneth Yeung , Jason Martin , Johann Rehberger , Riley Goodside , Joseph Thacker , Kai Greshake , Simon Willison , OWASP GenAI Security Project , Amazon Web Services (AWS) , Cisco , Microsoft , OpenAI , Anthropic , Google DeepMind , Unicode Consortium , Dan Goodin for the work this builds on.
Also on our website: https://agtechconsulting.ai/insights/your-prompt-filter-cant-see-invisible-text-hiddenlayer-patent.html
Want help testing your AI guardrails against invisible-text and encoded prompt injection, or designing input and output filtering your security team can sign off? Email avinash@agtechconsulting.ai, visit agtechconsulting.ai, or book a 30-minute call: https://calendly.com/avinash-dubey-30-min-catchup/meeting-with-ag-tech
Originally published on LinkedIn in the Your CTO Advisor newsletter: read and comment on LinkedIn →
