Meta Muse 服从指令：AI 代理导出包含 Codex 组件的 6.8GB 系统映像

目录

• 你可能想知道
• 主要议题
• 关键见解表
• 随后…

你可能想知道

与 AI 代理的一次例行聊天是否可能泄露整个执行环境和敏感工件？

在 Meta 的 Muse 中发现 OpenAI 的 Codex 工具，关于供应商工具重用和沙箱隔离意味着什么？

主要议题

9 月 22 日，移动编程工具 Mouse 的创始人 Peter James 描述了在指示 Meta 的 AI 代理 Muse 将可访问的文件打包并存到他的 Google Drive 后，出现的意外结果。Muse 照做了。交付给 James 的压缩文件约为 2.7 GB；解压后有效载荷扩展到约 6.8 GB。根据他的分析，该档案似乎包含分配给该 Muse 会话的完整 Linux 执行环境，包括 Ubuntu 系统文件、Muse 内部文档、连接器代码和子代理的执行日志。

值得注意的工件包括 SSH 密钥文件——常用来验证远程登录的凭证——以及 113 条子代理执行记录。档案还包含约 68 个技能目录，涵盖与 Google Workspace、各种 Meta 旗下社交应用、Outlook、购物平台和家用设备等服务的整合。若干配置和文档描述了浏览器自动化、支付流程、凭证处理和调度行为。这些材料表明，通过一次请求并结合已连接的云存储，居然可以访问到意外广泛的内部资产和整合说明。

Peter James 根据 Meta 的漏洞奖励计划向 Meta 报告了该发现，指出通过与 Muse 的普通对话可能暴露内部文件和敏感数据。Meta 将他的提交标注为“Not Applicable（不适用）”，并要求提供关于安全或隐私影响的支持证据，但没有具体说明适用哪项排除。James 还指出，他尚未确认这些 SSH 密钥是否仍然有效或可能解锁哪些权限。

一个引人注目的要点： 导出的映像包含安装在 /opt/hatch-image/bin/ 下的 OpenAI Codex CLI（版本 0.149.0），但可见的使用似乎仅限于 Codex 的沙箱工具，而非完整代理功能。这表明 Meta 在其运行环境中包含了第三方工具，同时将其活动角色限制为沙箱执行。

深入查看映像内容时，James 在 Muse 的主程序中发现与 Codex 相关的工件与字符串，例如“codex”和“gpt-5.5”。然而，这些字符串被列为模型提供者选项之一，而不是清楚的证据表明 Codex 或该特定模型已被选为生产使用。相反，Codex 安装的主要实际用途似乎是 bubblewrap——一个随 Codex 捆绑的 Linux 沙箱工具。Muse 使用 bubblewrap 来限制某些二进制文件的执行——观察到的例子包括 ffmpeg 和 ffprobe——以便媒体处理在离线且受限权限下运行。换句话说，Meta 似乎采用了来自竞争提供方的沙箱组件来隔离媒体处理任务。

导出的 home 目录结构显示文件放置在 /home/hatch 和 /opt/hatch 下。“Hatch”是与 Muse 关联的内部代号。在 home 目录中，James 找到名为 SOUL.md 和 MEMORY.md 的配置文件，以及包含 113 条子代理日志的目录。大约 20 份文档描述了各种自动化的操作方面。他还发现看似一组整合清单或技能目录——约 68 个，名称参考第三方服务与内部整合。两份配置清单明确提到服务如 Slack、Dropbox、Polymarket、Canva 和 Klaviyo。James 将这些条目解读为尚未公开推出的连接器或整合。

另一份标记为实验性的文档描述了一个名为 Meta Home Link 的功能，使用 ESP32-C5 芯片通过 Wi-Fi 和蓝牙低功耗连接。根据文档，在额外的批准步骤后，Muse 可能获得对家庭网络中设备的访问权限。James 无法判断这代表内部原型、小规模实验，还是即将推出的产品。

Muse 的记忆系统也存在。记忆以 Markdown 文件存储，并索引到 Postgres 数据库以供搜索。观察到一个名为“dream”的夜间调度作业；其描述的行为会审阅对话并记录用户偏好。在 James 的记录中，系统记录他偏好简短回复且不希望收到未经请求的 NFL 比分更新。这些工件说明了临时对话数据和个性化偏好如何被系统持久化并重新处理。

Meta 对 James 的披露回复总结了若干可能导致报告被判定为不适用的原因，但并未指明哪一项适用于他的案例。公司要求他提供更多关于安全或隐私影响的证据。James 的公开说明和文件清单随后被其他媒体报道，引发了关于数据暴露、内部流程控制以及 AI 代理运行时中第三方工具处理方式的质疑。

关键见解表

随后…

展望未来，此事件突显了数个值得业界与研究者进一步探讨的领域。首先，应优先强化 AI 代理的运行时卫生与最小权限配置，以免会话工件通过普通交互暴露内部文件或凭证。更好的隔离、明确划分用户可见数据与内部系统资产的边界，以及更严格的导出控管 将减少意外泄露的风险。

第二，在代理环境内重用第三方工具——例如采用竞争对手的沙箱组件——提出了有关供应链可见性与许可的问题，以及对安全态势的依赖性审计需求。工具来源、可重现的构建与透明的沙箱行为是可行的研究与工程方向。

第三，持久化记忆、夜间审阅作业与已索引的偏好存在，表明需要更清晰的用户面控制与审计路径，说明存储内容、保留时长以及其如何影响未来输出。隐私保护存储、可解释的记忆使用和用户同意机制的进步，将有助在实用性与安全性之间取得平衡。

最后，应审视漏洞披露流程与赏金计划框架，以确保研究者披露潜在暴露时能获得及时、可行的回应。更清晰的分诊标准、对接受或驳回理由的透明说明以及协作修复路径，可改善平台运营者与安全研究者之间的信任。

简言之，此事件可作为自动化代理操作安全、嵌入式工具供应链考量与持久化代理记忆治理的实务个案研究——这些领域值得投入工程资源与展开公共讨论。