ASCII Smuggling Hides Instructions in Visible Text

ASCII smuggling hides text with Unicode tag characters that many interfaces leave invisible. A person sees an ordinary paragraph. Software processing the raw string receives additional code points that mirror printable ASCII characters. When an LLM interprets those hidden characters as instructions, copied text or retrieved content can carry a prompt injection past the human reviewing the screen.

TL;DR

• ASCII smuggling uses characters in the Unicode Tags block, commonly U+E0000 through U+E007F, to carry hidden text.
• Visual review fails because typical interfaces may leave the tag characters unrendered while software still processes them.
• Inspect raw code points before model submission, then normalize or reject unexpected tags under route policy.
• DeepInspect can enforce routed HTTP AI traffic; source-document cleanup and endpoint behavior still need separate owners, as does tool authorization.

ASCII smuggling exploits a rendering gap

Johann Rehberger's January 2024 ASCII Smuggler research explains the mechanism. The Unicode Tags block mirrors ASCII characters. Many user interfaces omit those tag characters from the rendered view, while LLM tokenizers can still process the underlying text. A document can therefore display one message to a person and deliver extra content to a model.

The official Unicode Tags chart assigns the block from U+E0000 to U+E007F and lists tag versions of spaces and punctuation as well as digits and letters. It also marks the language-tag character as deprecated and strongly discourages using tag characters to convey language tags.

The concrete test is uncomfortable: place a cursor at the end of a clean-looking sentence, select all, and inspect the code points in a Unicode-aware viewer. The highlighted region can extend across characters that the page never drew.

The hidden instruction enters through ordinary content

An attacker can place tag characters in a web page, email, PDF, database field, or document. A person copies the visible text into an assistant, or a retrieval pipeline ingests the source automatically. The application sends the raw content inside an HTTP model request. If the model interprets the hidden sequence as instruction, the attack has crossed the content-to-instruction boundary.

ASCII smuggling is an obfuscation technique. The surrounding application still determines authority and decides how to trust the output. A summarizer with no tools may produce a manipulated summary. An agent connected to email or records can create a larger consequence if its permissions allow action.

The indirect prompt injection guide covers that trust boundary. For ASCII smuggling, determine if the retrieval and prompt-construction path preserves non-rendering Unicode tags.

Detection belongs before rendering destroys context

Inspect the raw string before it reaches the model. A deterministic check can identify code points in the Tags range. Policy can reject the request, remove the characters, or route the content for review according to the application's legitimate needs. Preserve the original value under restricted access when an investigation requires it, along with the transformed value or transformation record.

Normalization needs care. Removing unexpected tag characters may reveal the visible word sequence, while generic Unicode normalization can leave other unsafe control or formatting characters behind. Security tests should use the exact parsing and normalization code deployed on the route. They should also cover content assembled by retrieval pipelines because hidden text can arrive inside retrieved chunks as well as the user's typed prompt.

Microsoft's September 2026 ASCII smuggling research describes the Tags block and notes that software can process text that typical fonts and interfaces leave unseen. Microsoft also observed the same character family used to split phishing lure words, showing that the parsing gap extends beyond LLM prompts.

Policy needs identity and route context

A blanket rejection rule may fit a finance assistant whose approved inputs contain ordinary business text. A language-research workflow may have a legitimate reason to examine unusual Unicode. Identity-aware route policy lets the organization handle those cases differently without granting every user an exception.

At the AI request boundary, record the authenticated identity supplied by the application, role, destination model, source type, normalization action, matched code-point range, policy version, and final decision. Response inspection may also be needed because a model can emit hidden tag characters into text copied elsewhere.

The prompt injection protection architecture should combine deterministic code-point checks with model-aware classification and authorization. Detection identifies suspicious content. Authorization limits what the caller or agent can reach if an obfuscated instruction survives.

Human approval needs a raw-content view

A confirmation screen that renders the same sanitized view as the original document can repeat the failure. The reviewer sees an ordinary instruction and approves an action whose underlying payload contains hidden text. Human approval helps only when the interface exposes the material facts required for the decision.

For high-impact actions, show a warning when hidden or control characters were present. Display a safe escaped representation and identify the source. Then show the exact operation the agent proposes, including destination and affected record. Approval should attach to that operation. A friendly paragraph produced by the same model offers weak evidence.

I think a security review should treat invisible text as active content. A team would never approve invisible JavaScript because the page looked clean. Hidden Unicode entering a model deserves the same suspicion, even though the payload is text.

The HTTP boundary covers only part of the path

An HTTP enforcement point can inspect raw prompt content when the application routes the request through it. It can apply a configured deny, redact, or review policy and retain decision evidence. That covers the transition into the LLM and, where configured, the response returning through the same route.

Source sanitation may happen earlier in a crawler or document pipeline. Browser rendering and clipboard behavior live on the endpoint. Local models and STDIO tools can bypass an HTTP proxy. Tool authorization happens at the tool boundary. The prompt injection techniques overview places obfuscation beside these other controls and keeps a character filter in its proper, narrow role.

Test the full path with a harmless hidden marker. Confirm how the source stores it, what retrieval returns, what the prompt builder sends, what the enforcement point records, and what the model receives. One screenshot proves very little.

DeepInspect

DeepInspect sits between authenticated users or agents and HTTP-based LLM endpoints for traffic deliberately routed through its stateless proxy. It can apply identity-aware policy to request and response content and preserve a per-decision audit record outside the calling application.

DeepInspect covers the AI request boundary. Document ingestion, endpoint rendering, local execution, and tool authorization remain with their respective systems. An accurate architecture shows those handoffs instead of claiming that one Unicode check secures the full workflow.

Book a demo today.