InboxWall sanitizes email HTML to block prompt injection before it reaches an LLM

What InboxWall does

An open-source project called InboxWall takes aim at a quiet but real risk in AI agent deployments: when an agent is given mailbox access, every message it reads is HTML that may carry instructions the human never sees. According to a post on dev.to, InboxWall is a Model Context Protocol (MCP) server that converts raw email HTML into sanitized plain text before an agent hands it to a model, removing the structures attackers use to smuggle instructions into a prompt.

The server does not fetch mail itself. The calling agent retrieves messages over IMAP, Exchange Web Services, or a mail API, extracts the HTML part from the MIME structure, and passes it to InboxWall's single sanitize tool. The cleaned text is what enters the LLM's context.

Where the attacks hide

Email clients render HTML, CSS and Unicode to display formatted messages, and attackers exploit the gap between what renders on screen and what exists in the source. The dev.to write-up lists three main vectors. Hidden CSS text — white-on-white text, zero-opacity spans, content positioned off-screen — is invisible to a human reader but fully present in the raw payload a model ingests. Unicode manipulation, such as right-to-left override characters, zero-width joiners and homoglyphs, changes semantic meaning without any visual clue. And nested instructions can sit inside HTML comments or style blocks, holding directives that only surface once the markup reaches the model.

If an agent pulls a message and drops the full HTML into the prompt, the sender effectively controls part of that prompt.

How the sanitization pipeline works

InboxWall is deliberately strict about what survives. According to the post, the pipeline runs in stages: the body is parsed into a DOM tree with a lenient parser that tolerates malformed markup; a tag whitelist keeps only a small set — paragraphs, links, line breaks, emphasis, lists and blockquotes — and drops everything else; and on anchor tags, only the href attribute survives, with every other attribute stripped.

All CSS is removed, including inline styles, style tags and external stylesheet links. JavaScript and event handlers go too, along with attributes the project flags as suspicious, such as data URIs, srcdoc and formaction. The remaining text is normalized to NFC form and cleaned of zero-width characters, directional overrides and variation selectors, after which the DOM is flattened to plain text with basic structure and line breaks preserved.

A local, stateless design

InboxWall does not send anything to a cloud sanitization service. It runs as a separate process on the same machine as the agent, connected over stdio or HTTP depending on the MCP transport configuration, so email content never leaves the device. Latency is measured in milliseconds, the post claims, and no API keys are needed for the sanitization step itself.

The trade-off is operational overhead. Deployers must manage the server's lifecycle and ensure it is running before the agent calls it. The server is also stateless — no caching, no record of which messages were processed, no stored preferences — so the agent itself has to handle deduplication, error handling and rate limiting.

Known failure modes

The project is candid about its weaknesses. Extremely malformed HTML can crash the parser. Aggressive filtering can over-sanitize, stripping links an agent may legitimately need. New injection techniques — novel Unicode characters or CSS features — could bypass the filter until the whitelist is updated. And if the server process dies, the agent loses sanitization entirely and must detect the failure and recover or degrade gracefully. There is no built-in observability; logging, metrics and tracing must be added by whoever deploys it.

Why it matters

InboxWall embodies a position in an ongoing architectural debate: where security boundaries belong in agent tool chains. The dev.to post contrasts pre-LLM sanitization with alternatives such as post-generation output filtering and prompt engineering, arguing that a model instructed to ignore hidden text still cannot be trusted to block every attack — so cleaning has to happen outside the model's control, before the context window is ever populated.

As agents gain access to inherently hostile data sources like inboxes, that pattern is likely to shift from optional hardening to baseline requirement. InboxWall is a concrete, inspectable implementation of it, with documented limitations rather than hidden ones, and its local-first design means the fix does not require shipping yet more sensitive email content to a third-party service.