AI 邮件助手会读到隐藏指令吗？用 InBox Wall 在本机清洗邮件内容
把邮件交给 AI 总结或起草回复时，风险不只来自正文里看得见的文字。HTML 邮件可以用 CSS 把指令藏起来：人看到的是正常通知，模型解析原始 HTML 时却可能读到“忽略先前指令”之类内容。InBox Wall 是一个本地优先的 Python 项目，尝试在邮箱与 AI 之间加一道只读清洗层。它不是反垃圾邮件系统，也不应被当作完整的提示注入防护保证；更适合希望把邮件处理留在本机、并能审计过滤结果的开发者。
数据如何经过这道边界
项目 README 描述的处理链有四步：通过 IMAP 以只读方式读取近期邮件；对 HTML 内联样式后扫描可见性与文本；将安全文本写入 safemail.db，隔离内容写进独立的 vault.db；最后由本地 REST API 和 MCP 服务提供清洗结果。AI 接触的是安全库中的文本，而不是原始 HTML 或隔离库。README 还说明 IMAP 获取使用 mark_seen=False，不会把邮件标记为已读。
清洗并非简单删除 display:none。它会考虑继承样式、不可见字符和同形字符，并将文本提取限制在可见 HTML 标签白名单内。对未知输入、扫描器异常或超大文件，项目采用 fail-closed：将邮件判为 LOCKED_AWAY，不把正文交给 AI。被隔离的邮件可以在仪表板中检查，用户可选择保持锁定、人工审阅后释放，或报告误报。
这种分库设计值得关注：若模型只拥有调用安全 API/MCP 的权限，隔离库就不应被纳入它的工具权限范围。安全边界最终仍取决于部署者如何配置本地服务及其凭据，不能只依赖“本地运行”这几个字。
安装与运行
仓库要求 Python 3.10 或更高版本。README 给出的开发安装方式是：
git clone https://github.com/Annora998/inboxwall.git cd inboxwall pip install -e .
项目提供四个常用入口：inboxwall-doctor 检查系统状态，inboxwall-sync 通过操作系统密钥链安全同步邮件凭据，inboxwall-serve 启动仪表板与 API，inboxwall-mcp 启动 MCP 服务。仓库还列出 inboxwall-benchmark 测试入口。具体参数和邮箱配置应以仓库当前文档为准；此处不臆测命令行选项。
首次接入时，建议先用测试邮箱验证只读行为与邮件解析结果，再连接日常邮箱；确认 AI 客户端只配置安全 API/MCP，而不挂载 vault.db。对被锁定邮件应通过仪表板人工判断，不要为了让自动化继续而默认放行。项目说明 API 使用启动时生成的 bearer token，并校验 Host 请求头；本地监听地址、访问控制和令牌保护依旧需要妥善配置。
能力边界要讲清楚
InBox Wall 当前声明的防护范围包括 CSS 隐藏文本、部分不可见 Unicode、已知提示注入短语及非渲染标签中的文本。README 同时明确列出边界：附件（PDF、Office 文件等）不扫描；链接没有信誉分析；图片没有 OCR；纯粹依靠措辞诱导的社会工程也无法识别。若 CSS 内联失败，系统选择锁定邮件，而不是回退到可能不安全的解析路径。
因此，它适合作为 AI 邮件流水线中的纵深防御组件，不能替代邮件服务商的垃圾邮件/钓鱼防护，也不能代替人工确认高风险操作。项目 README 将其定位为本地工具，并称不收集遥测、邮件数据保存在本机。上线前应自行评估依赖、更新节奏与安全边界；尤其要为邮箱数据库和隔离库设置可靠的本机备份与访问权限。
如果你正在构建会读取邮件的 Agent，真正重要的问题不是“模型能不能看懂 HTML”，而是它能看到哪些数据、能调用哪些操作，以及异常时系统是否默认拒绝。InBox Wall 提供了一个可检查的本地实现思路：先清洗、再隔离、只把有限文本交给模型，同时把无法判断的内容留给人。