Annex：用「类勒索软件」机制保护本地文件免遭 AI Agent 读取

开发者 Brendan Keaton 在 GitHub 上开源了一款名为 Annex 的本地安全工具，专门用于防范本地 AI Agent 读取、篡改或泄露用户敏感文件。整套系统采用自托管 Supabase（PostgreSQL、Kong）、Next.js、Tauri（Rust）与 FastAPI（Python）构建，以 MIT 协议发布，但作者明确标注项目尚未经过安全审计，按「原样」提供。

背景：本地 Agent 的数据风险

文章开篇指出，本地 AI 软件具备读取设备上的文件、API Key、图片及其他敏感信息的能力。虽然社区已出现 .llmignore 等屏蔽方案，但作者认为这只是「握手协议」，无法阻止恶意 agent、prompt 注入攻击，甚至「过度对齐」的良性 agent 泄露数据。在虚拟机或不同用户空间下运行虽然更安全，但作者引用 Anthropic 红队的结论指出，足够强大的模型（例如被称为 Mythos 的代理）仍可突破沙箱。因此，他设计了一种以加密为核心的折中方案。

核心流程：会话式加密

Annex 的使用流程围绕「会话」展开：

• 用户先选定不希望 AI 访问的文件，如 .env、测试文件、含个人身份信息的数据集等。
• 启动 AI Agent 前，发起一个 Annex 会话，系统会以 AES-256-GCM 对受保护文件及文件名进行加密，通常耗时数秒到一分钟。
• 期间 AI 工具正常使用，所有敏感文件均处于密文状态，无法被读取。
• Agent 运行结束后，关闭会话，文件自动解密恢复。

密钥生成：可推导的确定性方案

与常见加密软件不同，Annex 的会话密钥并非随机生成，而是由四个输入拼接后经 SHA256 派生：

• 当前 UTC 日期
• 自增的会话计数
• 注册时获得的六组「恢复种子」之一
• 仅存储在 FastAPI 服务器上的「一次生成、永不外泄」的密钥

注册时用户需创建 6 位 PIN，并获得 6 个恢复种子。作者承认确定性密钥在加密工具中看似「反模式」，但他认为在仅针对本地 AI Agent 的威胁模型下，这是为换取数据库或逻辑故障后仍可恢复文件所做权衡。即便针对性强、专业化的攻击，攻击者也需同时获取服务器密钥、恢复码、用户 PIN 以及物理设备。

文件加密与安全销毁

加密流程逐文件执行：先校验文件可用性，对原始文件做 SHA256 校验上传；随后按大小分块加密（≤4MB 使用 12 字节 nonce，>4MB 按 4MB 分块并使用 7 字节 nonce）；文件名被随机化并加上 .annex 扩展名，例如 CLIENT_TAXES_2026.csv 变成 aj18xl.annex。

最关键的步骤是销毁原文件：先用随机字节覆写，再做「打孔」操作、随机改名（与第四步独立），调用 fsync 落盘，最后 unlink 删除。该流程针对 TRIM 做了适配，在不同操作系统上有独立代码路径，作者将其视为对未来能够读取内存或直接访问磁盘的更强 agent 的预防措施。

会话结束后，会话密钥通过 Rust 的 zeroize 库从内存中清除，并尽最大努力确保其不在本地残留。所有加密、销毁步骤均会上报后端形成清单，便于崩溃后恢复。

局限与定位

作者在多处声明中强调：该项目定位为针对本地 AI Agent 的实验性方案，不替代专业终端防护或企业级数据保护方案；密钥派生方式、依赖单一服务器 secret 等设计均以「本地威胁模型」为前提，不适合作为通用加密工具使用。读者若要在生产环境部署，仍需自行评估并进行独立审计。