InboxWall：本地MCP服务器如何阻断邮件提示注入

当AI智能体接入邮箱时，它读取的并不只是人类看到的邮件正文。HTML邮件里可能藏着白底白字的隐藏文本、零宽Unicode字符、甚至写在HTML注释里专供模型阅读的指令。这类攻击被称为提示注入，而InboxWall给出的解法是：在LLM看到邮件之前，先把危险内容清干净。

InboxWall是一个开源MCP（Model Context Protocol）服务器，以本地优先的方式运行，把邮件HTML净化成安全纯文本。它不连接任何邮件服务商，只暴露一个工具接口，让调用方把原始HTML交给它处理。这个设计背后有一个值得展开的架构问题：在智能体工具链中，安全边界究竟应该放在哪里。

邮件HTML为什么是提示注入的温床

邮件客户端为了渲染排版，需要解析HTML、CSS和Unicode。攻击者恰恰利用这一点，把指令藏在人类看不见、模型却会读到的位置。原文列出了三类典型手法。

第一类是隐藏CSS文本，例如白色文字配白色背景、透明度为零的span、或者用绝对定位挪到屏幕外的内容。人眼看不到，但HTML源码里一字不差。

第二类是Unicode技巧，包括从右到左覆盖字符、零宽连接符以及形近字（homoglyph）。这些字符能改变语义却不留视觉痕迹。

第三类是嵌套指令，比如HTML注释或<style>块中写着“忽略之前的指令”，这类内容只存在于原始源码中。

智能体通过IMAP或邮件API读取邮件时，拿到的往往是完整HTML。如果这段HTML直接进入LLM上下文，攻击者就等于控制了提示词的一部分。

提示注入（Prompt Injection） 是LLM应用安全中的一类核心威胁：攻击者将精心构造的指令混入模型会读取的数据（邮件、网页、文档）中，使模型把数据内容误当作系统指令执行。与传统SQL注入类比，其本质是“数据与指令的边界被打破”。OWASP已将其列为LLM应用的首要风险。防御思路通常分为输入侧（在数据进入上下文前净化）与输出侧（过滤模型生成内容），InboxWall走的是前者。

MCP服务器的架构设计

InboxWall以MCP服务器形态运行，对外只暴露一个工具：接收原始邮件HTML，返回净化后的纯文本。

它的净化管道会剥离所有CSS（内联样式、<style>标签、外部样式表）、JavaScript与事件处理器、不可见Unicode字符（零宽空格、方向覆盖符、变体选择符）、HTML注释，以及可疑属性（data URI、srcdoc、formaction）。

关键点在于职责划分：服务器本身不连接邮件提供商。它期望调用方自行通过IMAP、Exchange Web Services或邮件API取回邮件，再把HTML正文交给它清洗。这种解耦让净化逻辑保持单一职责。

本地优先的执行模型

InboxWall与智能体运行在同一台机器上，邮件数据不离开设备。原文指出，这改变了威胁模型：不需要把邮件内容发给第三方净化服务，不需要为净化配置API密钥，净化在进程内或localhost上同步完成，延迟以毫秒计。

代价是运维负担。你需要把MCP服务器作为独立进程运行，管理其生命周期，并确保它在智能体调用之前已经启动。

MCP（Model Context Protocol） 是Anthropic于2024年底提出的开放协议，用于标准化LLM应用与外部工具、数据源之间的连接。它借鉴LSP（语言服务器协议）的思路：客户端（智能体宿主）与服务器（能力提供方）通过JSON-RPC通信，服务器可暴露三类原语——tools（可调用函数）、resources（可读取数据）、prompts（预设模板）。传输层支持stdio（本地进程）与HTTP/SSE（远程）。InboxWall把净化能力封装为单个tool，正是MCP工具服务器的典型用法：能力边界清晰、可被任意兼容的客户端复用。

净化管道的内部流程

InboxWall的净化逻辑是一个多阶段过滤器，原文给出了六个步骤。

1. HTML解析：用宽容型解析器把邮件正文解析成DOM树，能处理格式错误的标记。
2. 标签白名单：只保留安全标签，如<p>、<a>、<br>、<strong>、<em>、<ul>、<li>、<blockquote>，其余全部丢弃。
3. 属性白名单：对允许的标签，仅保留<a>上的href，其他属性一律剥离。
4. CSS清除：删除所有style属性、<style>标签和<link rel="stylesheet">元素。
5. Unicode规范化：先做NFC规范化，再移除零宽字符、方向覆盖符和变体选择符。
6. 文本提取：把净化后的DOM展平为纯文本，保留换行和基本结构。

输出是一段移除了所有注入向量的纯文本邮件表示。

Unicode清洗的代码示例

原文提供了一段简化的Python代码，展示Unicode清洗步骤。核心思路是维护一个零宽与方向控制字符列表，包括\u200B零宽空格、\u200C零宽非连接符、\u200D零宽连接符、\u200E从左到右标记、\u200F从右到左标记、\u202A至\u202E一组方向嵌入与控制符，以及\uFEFF零宽不换行空格。

函数先做NFC规范化，再逐个替换掉这些字符，最后用正则[\uFE00-\uFE0F]清除变体选择符。这段逻辑在HTML净化之后、文本提取之前执行，专门捕捉那些能扛过HTML解析的Unicode混淆。

Unicode规范化与形近字攻击：NFC是Unicode四种规范化形式之一（C代表Composition），把基字符与组合附加符合并为单一码点，使等价字符串有唯一表示。但规范化并不能消除形近字（homoglyph）问题——例如拉丁字母a与西里尔字母а外观几乎一致却码点不同，攻击者可借此绕过关键词匹配。方向控制符（\u202A–\u202E）原本用于双向文本排版，却被用来让源码顺序与显示顺序倒置。变体选择符（\uFE00–\uFE0F）则可为同一字符附加不可见样式变体。彻底防御需要在规范化后做字符集白名单或同形字归一，InboxWall的字符黑名单是一种轻量但需持续维护的方案。

安全边界应该放在哪

InboxWall的设计揭示了一个模式：安全预处理应该发生在LLM看到数据之前，而不是之后。这与输出过滤的思路正好相反。原文用一张对比表列出了四种方案。

方案	边界位置	优点	缺点
LLM前净化	上下文窗口之前	从源头阻断注入，模型根本看不到攻击向量	需要独立预处理步骤，增加延迟
LLM后过滤	生成之后	管道更简单，无预处理开销	模型可能已被污染，难以发现隐蔽操纵
提示词工程	LLM提示词内部	无外部依赖	不可靠，攻击者可构造覆盖指令的提示
检索时过滤	数据获取阶段	集中控制，覆盖所有下游智能体	数据源与安全逻辑紧耦合

InboxWall选择LLM前净化，原因很直接：它把LLM视为不可信。即便在提示词里叮嘱模型忽略隐藏文本，也不能指望提示工程挡住所有攻击。净化必须发生在模型控制范围之外。

智能体如何接入

使用InboxWall的智能体遵循一条清晰的流程：通过IMAP或邮件API取回原始邮件，解析MIME结构取出HTML部分，调用sanitize_email工具，拿到不含CSS、JavaScript和Unicode花招的纯文本，再把它放进LLM提示词做摘要、分类或回复生成。

MCP服务器作为独立进程运行，智能体通过stdio或HTTP连接，取决于MCP传输配置。服务器在调用之间不保留状态，每次净化请求相互独立。

状态管理的取舍

InboxWall是无状态的：不缓存已净化的邮件，不记录哪些消息处理过，也不存储用户偏好。这简化了部署，但把三件事留给了智能体：去重（重复拉取会重复净化）、错误处理（净化失败时是跳过还是重试）、限流（每秒送多少封邮件给InboxWall）。

失败模式与可观测性

原文坦率列出了InboxWall的几类失败可能。解析器可能因极端畸形的HTML抛出异常；过滤过于激进可能误删合法内容，比如剥离所有<a>标签会丢掉智能体可能需要的链接；新的注入手法（新颖的Unicode字符、CSS特性）可能绕过白名单，直到规则更新；MCP服务器进程崩溃则会让智能体失去净化能力，需要检测并重启或优雅降级。

项目本身不内置可观测性，日志、指标和追踪都得自己加。原文建议跟踪四类信号：净化延迟（从收到HTML到返回纯文本的耗时）、拒绝率（因解析错误失败的邮件占比）、移除字节数（输入HTML与输出文本的体积差，反映剥离了多少内容）、错误类型分类（解析崩溃、超时、非法输入），以便识别规律。

部署形态与适用场景

典型的部署方式是：安装Python运行时、HTML解析库（如BeautifulSoup或lxml）和MCP服务器框架；把InboxWall作为后台进程启动，监听stdio或本地端口；在智能体的MCP客户端里指向该服务器；用systemd或supervisord之类的进程守护工具在崩溃时重启。因为是本地优先，不需要配置网络防火墙、TLS证书或API认证，攻击面收敛在本地机器。

原文也明确了适用边界。适合使用的场景包括：智能体读取来自不可信发件人的邮件（客服、公共收件箱、邮件列表）；希望安全边界不依赖提示工程；偏好本地执行而非云端预处理；需要一个简单、无状态、能接入现有MCP工具链的净化步骤。

不适合的场景同样清楚：邮件来源完全可信（有严格发件人策略的内部企业邮件）；智能体上下文需要富HTML渲染（链接、格式、图片）；已有云端邮件安全网关承担净化；以及无法运行独立MCP服务器进程的无服务器智能体环境。

技术判断

InboxWall证明了一件事：安全预处理应当位于LLM信任边界之外。把净化做成独立MCP服务器，让安全逻辑与智能体编排解耦，过滤规则变得显式、可审计。本地优先架构让邮件数据留在设备上，这对隐私敏感场景很重要，代价是运维复杂度——你得管理MCP服务器生命周期，并在它不可用时处理失败。

净化管道是激进的：剥离所有CSS、JavaScript和不可见Unicode，可能连带删掉合法内容。如果智能体需要保留链接或基本格式，就需要fork项目并调整白名单。对于处理不可信来源邮件的智能体，InboxWall是一个务实的起点，它示范了如何构建一个不依赖LLM自身抗注入能力的安全边界。