AI 邮件助手如何防住隐藏指令？用 InBox Wall 建立本地清洗边界
把邮件交给 AI 总结或代拟回复，看起来只是把文本发给模型；实际输入却常是 HTML。发件人可以用白色小字、隐藏 CSS 或零宽字符藏入人眼难以发现的指令。传统反垃圾邮件关注恶意链接和附件，却未必会清理这些专门针对模型输入的内容。
InBox Wall 是一个本地优先的 Python 项目，试图在邮箱和 AI 助手之间增加一道只读清洗层：先通过 IMAP 读取邮件，分析 HTML 与 Unicode，再把可见文本交给本机 REST API 或 MCP 服务。它适合作为纵深防御的一环，而不是“提示注入已解决”的保证。
数据路径：原文与安全文本分开
项目 README 描述的处理链路可概括为四步：
- 只读获取：IMAP 拉取邮件时使用
mark_seen=False，避免同步过程改变未读状态。 - 解析和筛查：内联 CSS 后检查 DOM 文本节点，识别
display:none、不可见、屏幕外定位、极小字号等隐藏样式；同时处理零宽字符和西里尔字母形似字符等情况。 - 隔离存储：清洁文本进入
safemail.db，被拦截内容及原始隐藏片段进入单独的vault.db。AI 侧接口只查询安全库，不应直接取得隔离库或原始 HTML。 - 受控提供：本地 REST API 和 MCP 服务对外提供清洗后的内容；README 还说明接口使用启动时生成的 Bearer token，并验证 Host，降低本机服务被跨站或 DNS rebinding 滥用的风险。
这套设计的关键不只是“匹配恶意句子”，而是缩小 AI 能读到的数据面：即使隔离区保留了原始证据，也不把它和正常邮件正文放在同一条读取路径上。项目还使用随机 nonce 包裹交给 AI 的内容，并清理可能伪造边界标记的字面文本，降低内容冒充系统边界的机会。
安装与启动
README 给出的前置条件是 Python 3.10 或更高版本。基本安装方式如下：
git clone https://github.com/Annora998/inboxwall.git cd inboxwall pip install -e .
项目列出的命令入口包括健康检查、同步、Web/API 服务和 MCP 服务：
inboxwall-doctor inboxwall-sync inboxwall-serve inboxwall-mcp
其中 inboxwall-sync 可将 IMAP 凭据存入操作系统原生凭据管理器；具体能否使用 Windows Credential Manager、macOS Keychain 或 Linux Secret Service，取决于本机环境配置。第一次运行前，建议先看仓库当前配置说明，使用专门测试邮箱验证 IMAP 权限和同步范围，再接入真实工作流。不要把真实邮箱密码写进脚本、示例或版本库。
适合什么场景，又有哪些盲区
如果你在本地运行 AI 邮件工作流，希望降低隐藏 HTML 指令混入模型上下文的概率，InBox Wall 的本地数据库隔离、只读邮箱访问和 MCP 接口是值得评估的组合。使用时可以先检查仪表盘中的 X-Ray 视图与审计记录，确认哪些文本被移除，再让模型读取清洁结果；误报内容应经过人工复核后再释放。
但它的边界同样重要。项目明确说明目前不扫描 PDF、Office 等附件，不做链接信誉分析，也不对图片执行 OCR；它无法识别没有技术隐藏手段的社会工程话术。此外，项目是本地单机方案，邮件不会因此自动获得跨设备同步能力。若 CSS 内联失败，设计选择是锁定邮件而不是放宽处理，这提升了失败时的安全性，却可能带来可用性问题。
安全工具不能替代邮件服务商的反垃圾与钓鱼防护，也不能替代人工确认。更稳妥的做法是把 InBox Wall 放在输入预处理环节，同时让 Agent 对发送、转发、删除等高影响操作保留审批；定期更新规则，并用自有测试样本检查漏检和误报。README 提到的样本库仅用于开发与演示，生产评估应扩充为覆盖真实邮件结构、语言和攻击变体的测试集。
结语：InBox Wall 的价值在于把“邮件原文”和“可供 AI 使用的文本”明确分层，并提供可审计的本地处理路径。它不能证明每封邮件都安全，但能让 AI 邮件工作流少依赖模型自行辨认隐藏 HTML 的能力。