InboxWall
An open-source, local-first MCP server that sanitizes email HTML before an LLM reads it, stripping prompt injection carriers such as hidden CSS text, invisible Unicode characters and HTML comments. It exposes only a single sanitization tool interface.
Timeline (last 90 days)
InboxWall is an open-source MCP server that runs in a local-first manner, sanitizes email HTML into safe plain text, and does not connect to any email provider.
InboxWall exposes only one MCP tool interface externally, which accepts raw email HTML and returns sanitized plain text.
InboxWall's sanitization pipeline strips all CSS, JavaScript and event handlers, invisible Unicode characters, HTML comments, and suspicious attributes (data URIs, srcdoc, formaction).
InboxWall's sanitization process consists of six stages: HTML parsing, tag allowlisting, attribute allowlisting, CSS removal, Unicode normalization, and text extraction.
InboxWall chooses to sanitize before the LLM sees the data (pre-LLM sanitization), treating the LLM as untrusted.
InboxWall is stateless: it does not cache sanitized emails, does not log processed messages, and does not store user preferences.
The InboxWall project itself does not include built-in observability; logs, metrics, and traces must be added by the user.
InboxWall's Unicode cleaning uses a character blacklist (including zero-width characters, directional control characters, and variation selectors), a lightweight approach that requires ongoing maintenance and cannot fully defend against homoglyph attacks.
A typical flow for an agent using InboxWall is: retrieve the raw email via IMAP or an email API, parse the MIME to extract the HTML part, call the sanitize_email tool, and place the returned plain text into the LLM prompt.
InboxWall's local-first execution model keeps email data from leaving the device and requires no third-party sanitization service or API key, with latency in milliseconds, at the cost of needing to independently manage the lifecycle of the MCP server process.
1 more timeline events
All Facts (11)
InboxWall is an open-source MCP server that runs in a local-first manner, sanitizes email HTML into safe plain text, and does not connect to any email provider.
50%UnverifiedInboxWall exposes only one MCP tool interface externally, which accepts raw email HTML and returns sanitized plain text.
50%UnverifiedInboxWall's sanitization pipeline strips all CSS, JavaScript and event handlers, invisible Unicode characters, HTML comments, and suspicious attributes (data URIs, srcdoc, formaction).
50%UnverifiedInboxWall's sanitization process consists of six stages: HTML parsing, tag allowlisting, attribute allowlisting, CSS removal, Unicode normalization, and text extraction.
50%UnverifiedInboxWall chooses to sanitize before the LLM sees the data (pre-LLM sanitization), treating the LLM as untrusted.
50%UnverifiedInboxWall is stateless: it does not cache sanitized emails, does not log processed messages, and does not store user preferences.
50%UnverifiedThe InboxWall project itself does not include built-in observability; logs, metrics, and traces must be added by the user.
50%UnverifiedInboxWall's Unicode cleaning uses a character blacklist (including zero-width characters, directional control characters, and variation selectors), a lightweight approach that requires ongoing maintenance and cannot fully defend against homoglyph attacks.
50%UnverifiedA typical flow for an agent using InboxWall is: retrieve the raw email via IMAP or an email API, parse the MIME to extract the HTML part, call the sanitize_email tool, and place the returned plain text into the LLM prompt.
50%UnverifiedInboxWall's local-first execution model keeps email data from leaving the device and requires no third-party sanitization service or API key, with latency in milliseconds, at the cost of needing to independently manage the lifecycle of the MCP server process.
50%UnverifiedInboxWall may cause parser exceptions due to extremely malformed HTML, overly aggressive filtering may mistakenly delete legitimate content (such as stripping all <a> tags and losing links), new injection techniques may bypass the allowlist, and a crash of the MCP server process would leave the agent without sanitization capability.
50%