Meta Muse 文件系统导出暴露了隔离与控制之间的鸿沟

据报道，一名用户要求 Meta Muse 将其能够看到的所有内容归档后，Meta Muse 导出了 6.8 GB 的运行时文件。开发者 Peter James 表示，这次 Meta Muse 文件系统导出包含系统文件、内部文档、应用模板、记忆记录和代理日志。这发生在 Meta 将 Muse 作为安全个人代理推出约两周后。

这一说法并不能证明 James 访问了 Meta 的主机基础设施或其他客户的数据。Meta 表示，每位 Muse 用户都会获得一台隔离的虚拟机，因此其文件系统可与个人笔记本电脑中的文件相提并论。但这一回答仍留下了一个更棘手的问题：仅仅因为内部运行时材料位于分配给用户的环境中，消费级代理是否就应当将其分发出去？

这一冲突的重要性，超过了下载 AI 代理文件本身的新奇感。Meta 将隔离、权限检查和独立的安全控制器作为 Muse 的核心防护措施。此次被报道的导出事件表明，隔离本身或许有效，但信息控制策略仍可能在产品边界处失效。

Meta Muse 文件系统导出包含了什么

最明确、已获验证的说法范围有限，却影响深远：据称 Muse 将其自身分配运行时中的文件打包，并传输至一个已连接的 Google Drive。

James 于 2026 年 9 月 22 日发布了自己的经历。他表示，自己要求 Muse 将其可访问的文件归档并发送至自己的 Drive。最终下载文件压缩后约为 2.7 GB，解压后为 6.8 GB。

据称，Muse 的交付消息将该归档文件描述为 2.86 GB，与 James 的记录之间存在细微差异。James 披露了这一差异，而没有将这些测量结果表述为完全一致。该归档文件本身尚未公开，因此独立审查受到限制。

根据 James 的详细runtime export，这些文件似乎代表了分配给其 Muse 会话的根文件系统。其中包括 Ubuntu 系统文件、集成代码、应用模板、内部文档、记忆文件和代理活动日志。

该归档还包含 SSH 密钥文件。不过，James 表示，他并未确认这些密钥是否仍然有效，或能够访问哪些系统。因此，它们的存在值得调查，但本身并不能证明存在未经授权的访问。

多个目录展现了被报道环境的详细图景。代理的主目录包含指令和身份文件，文件名包括 SOUL.md、IDENTITY.md、USER.md、MEMORY.md、AGENTS.md 和 TOOLS.md。

James 统计发现，其中有 113 条以 JSONL 追踪记录形式存储的子代理记录。他还发现约 20 份 Markdown 文档，涵盖浏览器行为、连接器、凭据、支付、日程安排、生成文件、语音功能和数据处理等内容。

另一个目录据称包含约 68 个技能文件夹。这些文件夹将书面说明与命令行工具或支持代码配对，用于覆盖电子邮件、日历、旅行、购物、健康、媒体和已连接设备等服务。

这些文件还显示了 Muse 显然如何组装其运行时环境。James 描述了 18 个与构建和启动 systemd-nspawn 容器相关的文件；这是一种 Linux 隔离环境，为进程提供受限文件系统和有限能力。

这一细节大致符合 Meta 自己公开的架构说明。Meta 表示，Muse 使用一台专用虚拟机，其中包含独立的运行时单元、凭据服务、数据库和安全组件。Meta 还确认，Hatch 是 Muse 的内部代号。

开发者 Jonny L. Saunders 表示，他独立复现了这一大致结果。他称整个过程极其容易，并认为 Muse 对提示注入几乎没有抵抗能力。

最有力的独立验证来自 The Verge。该媒体记者表示，Muse 起初拒绝了获取完整文件系统的请求。但在开启新会话并采用不同表述后，据称 Muse 提供了经过清理的 /opt/hatch 和 /home/hatch 副本，以及目录树。

这一尝试并未复现 James 归档中的所有内容。据称，Muse 移除了 SSH 密钥等项目。不过，根据原始filesystem report，返回的文件似乎与 James 和 Saunders 所描述的材料一致。

这些说法支持一个有限的结论：至少在所报道的测试中，Muse 能够通过普通对话暴露其分配运行时环境的大部分内容。它们并不能证明存在容器逃逸、跨账户访问，或 Meta 底层云主机遭到入侵。

James 明确表示，他并未证明能够逃离容器。他曾简要测试这一边界，发现其似乎有效，并在尝试更深入检查生产系统前停止了。

这一区别应当影响对该事件的每一种解读。将这一结果称为对 Meta 基础设施的全面攻破，超出了现有证据所能支持的范围。将其称为无关紧要，同样忽视了被导出文件据称包含的内容。

Meta 表示这些文件属于用户的虚拟机

Meta 的辩护基于所有权和隔离：用户可以检查分配给自己的计算机，而不会因此获得对 Meta 特权系统或其他用户数据的访问权限。

Meta 发言人向 The Verge 表示，该事件并非安全漏洞。该公司将这种行为比作查看用户面前笔记本电脑上的文件。

“当然，你可以看到这些文件，”发言人 Daniel Roberts 表示。他补充说，导出虚拟机数据并不会授予用户访问 Meta 基础设施或他人信息的特权权限。

这一论点在技术上是自洽的。隔离容器内的根目录，并不一定是其宿主机的根目录。“根”一词描述的是文件系统中的位置，可能造成拥有普遍访问权限的误解。

Meta 公开的security architecture称，每位用户及其 Muse 都共用一台专用 Linux 虚拟机。在其中，主要的 Hatch 运行时在 systemd-nspawn 容器内运行。

Meta 表示，该容器内的 root 对应于宿主机上的非特权用户。容器拥有自己的 Debian 文件系统、经筛选的系统调用、虚拟网络接口和缩减后的 Linux 能力。

敏感服务位于运行时单元之外。这些服务包括凭据存储、连接器工作进程、持久化应用数据库、推理代理以及 Meta 独立的权限机构 Sentinel。

据 Meta 称，Sentinel 控制连接器操作和网络访问。Muse 提出一项操作，而 Sentinel 决定允许、拒绝，还是请求用户批准。

这一设计应对了多种严重威胁。如果提示操纵了模型，模型不应自动获得密码、支付凭据、主机级权限或不受限制的网络访问。

Meta 表示，连接器凭据仍处于代理的直接触及范围之外。运行时只能看到临时替代令牌，而 Sentinel 仅会在经批准的网络边界处将其替换为真实凭据。

这种隔离有助于解释 Meta 为何拒绝“漏洞”这一标签。没有公开证据显示，被导出的文件系统包含其他客户的数据、中央凭据存储，或可直接访问共享 Meta 基础设施的权限。

James 自己的观察也支持 Meta 立场的一部分。他能够查看描述容器创建的脚本，却未能证明可以访问被分配环境之外的内容。他的报告还指出，该归档不足以审计 Meta 的整个服务。

不过，Meta 的笔记本电脑类比将几个不同的问题压缩成了一个。个人笔记本电脑通常归其所有者所有，包括操作系统和大多数本地安装的文件。Muse 则运行在 Meta 管理的云环境中，并包含专有指令、模板、二进制文件及看似未发布的引用。

用户也是通过对话界面，而非传统的系统管理控制台接触 Muse。该界面据称会拒绝某些请求，却会在不同措辞下完成类似请求。这种不一致意味着，产品至少有一部分将这些文件视为受限内容。

Meta 在推出 Muse 时，将安全和隐私作为突出的卖点。其launch announcement称，用户仍保持控制权，敏感操作需要批准，且 Sentinel 管理外部访问。

同一公告还称，该代理可以浏览网站、发送消息、填写表单、进行购买，并连接个人服务。这些能力使授权边界的重要性高于一个隔离编码演示场景。

Meta 还表示，Muse 会将用户数据存储在专用虚拟机中。因此，要求导出“一切”的请求可能混合多种类别：用户拥有的文件、代理记忆、系统组件、专有指令、运行日志以及可能的密钥材料。

将这一整套内容视为普通用户可见数据，简化了产品策略。但这并不能解决其中每一份文件是否都被有意设为可导出的疑问。

Meta 告诉 The Verge，公司将继续更新产品。因此，用户可能会看到有关其虚拟机的信息可用程度发生变化。这一回应表明，当前边界仍在调整之中。

隔离有效，但信息控制似乎仍不完整

核心反转在于，Muse 的沙箱或许成功限制了代理的活动范围，却仍允许它披露 Meta 很可能无意通过对话界面公开的文件。

沙箱限制的是程序可以在何处行动。它并不会自动决定程序应当汇总、归档或向外发送哪些可读取文件。

这一差别很容易被忽视。如果 Muse 在完成正常工作时可以读取内部文档，模型就可能将该文档纳入输出。如果获得批准的连接器允许上传文件，同样的内容无需发生任何容器逃逸便可离开运行时环境。

因此，被报道的 Meta Muse 文件系统导出测试的是信息流边界，而不只是虚拟化边界。相关问题在于，Muse 是否应将广泛的读取权限与打包并导出所得数据的权限结合起来。

Meta 的架构包含一个名为 tainted egress 的概念。简单来说，进程在读取用户数据后会被标记，使 Sentinel 能在信息离开虚拟机前施加更严格的控制。

公开文档重点强调保护用户信息和凭据。文档称，Sentinel 会评估目标位置、网络方法、请求路径，以及一个进程是否处理过敏感材料。

这次文件系统事件引出了一个问题：内部运行时文件是否获得了等同的分类。如果 Muse 读取了指令文件、应用模板或代理追踪记录，导出的归档文件理应携带反映这些内容的策略标签。

对 Google Drive 的一般性写入授权，未必意味着用户对每一种可能的文件都作出了有意义的同意。用户可能以为自己授权上传的是一份生成的文档，而不是代理运行环境的镜像。

这正是 Meta 的所有权论点与产品行为之间出现分歧的地方。即便这些文件在法律上或运营上属于分配给用户的机器，代理仍需要可预测的规则来决定是否可以将其暴露出去。

The Verge 描述的不一致性让这一缺口显而易见。一个会话以安全风险为由拒绝完整导出；而另一个会话据称在收到奉承与表达好奇心的话语后，交付了经过清理的子目录。

这种行为更像是一种提示词层面的限制，而非可靠的系统策略。提示词层面的限制依赖语言模型正确理解意图，而这可能因会话和措辞不同而变化。

更强的控制措施应在模型之外对文件进行分类，并在工具层面强制执行这一分类。这样一来，归档命令就能无论用户如何有说服力地表述请求，都排除受保护路径。

同样的原则也适用于已连接的服务。模型不应独自决定，一项宽泛的用户请求是否授权将日志、凭证、内部文件和个人记忆一并移入一个外部归档文件。

这些情况均不能证明 Sentinel 未能履行其文档中所述的职责。James 是有意请求导出，并提供了一个由他控制的目标位置。Sentinel 可能将这一操作视为已获用户授权。

这种可能性将焦点从绕过机制转向策略设计。一个系统可以遵循其书面授权规则，却仍然产生令人意外或不安全的结果，因为这些规则过于宽泛。

Meta 表示，用户可以选择 Muse 能访问的内容，并批准敏感操作。然而，当代理能够在一个表面上很简单的操作背后，悄然汇集许多类别的文件时，同意就变得不那么具有信息量。

这一问题也挑战了一种常见的营销捷径。供应商经常将隔离的代理计算机描述得仿佛隔离解决了全部安全问题。实际上，代理还必须在该计算机内部实施最小权限原则。

最小权限意味着仅授予完成任务所需的文件、命令、网络和凭证。充满内部工具的运行环境或许需要广泛的本地访问权限，但这种访问不应等同于不受限制的信息披露。

对企业买家而言，这一区别会影响风险审查。安全团队必须询问：代理能读取什么内容、内容如何分类、哪些操作会触发重新授权，以及批量导出是否会得到特殊处理。

消费者也面临类似问题，只是没有专业的安全人员。Muse 邀请人们连接电子邮件、日历、消息、购物账户和长期个人记忆。批量导出功能可能将这些信息汇集成一个可携带的对象。

该事件并未显示 James 的归档文件包含了他人的信息。它说明，个人数据、代理数据与平台数据之间的边界需要明确执行，而不能依赖对话式解释。

最严重的说法仍未得到验证

据称存在的归档文件引发了合理的安全疑问，但并不足以支持围绕此事流传的每一个戏剧性结论。

首先，没有独立方公开审计过 James 的完整归档文件。为避免泄露潜在敏感材料，他没有公开该归档、SSH 密钥和会话日志。

这一决定是负责任的，但也限制了验证。外部人士只能依赖截图、文件列表、James 的描述、Saunders 的说法，以及 The Verge 的部分复现。

其次，SSH 密钥的存在并不能说明其价值。密钥可能已过期、受到限制、为内部测试生成、仅限于隔离虚拟机，或者在没有额外控制措施的情况下无法使用。

James 明确承认了这种不确定性。他并未声称这些密钥能够解锁 Meta 系统，也没有已公开的证据显示它们可以做到这一点。

第三，对未公布集成的提及并不能证实未来产品。配置文件据称提到了包括 Slack 和 Dropbox 在内的服务，另一份文档则描述了一项实验性的 Meta Home Link 设备集成。

这类文件可能代表原型、废弃测试、脚手架，或计划中的功能。James 表示，他无法确定 Home Link 是否会推出。

第四，系统文件并不能证明主机遭到入侵。容器通常包含完整的操作系统镜像，因为应用程序需要标准库、实用工具和软件包元数据。

用户在容器内看似拥有 root 访问权限，同时在容器外仍可能没有特权。Meta 明确表示 Muse 采用了这种安排。

第五，“提示词注入”这一标签需要谨慎使用。提示词注入通常涉及嵌入在外部内容中的不受信任指令，它们在用户不知情的情况下操纵代理。

在这里，开发者直接要求自己的代理导出文件。这与其说像是经典的间接注入攻击，不如说更像策略规避或不一致的指令遵循。

Saunders 的批评仍然指出了一个重要弱点。如果措辞的细微变化就能推翻一次拒绝，那么这种拒绝就不是可靠的安全边界。不过，术语不应超越已被证明的行为。

透明度与漏洞之间也存在区别。允许用户检查分配给自己的运行环境，可以支持审计、可移植性和信任。开发者通常重视能够揭示其指令和执行环境的工具。

风险来自无结构的信息披露。内部文档、运行痕迹、密钥文件和个人记忆，不应在没有明确警告和过滤的情况下变成一个不加区分的归档文件。

据 James 所述，Meta 的漏洞赏金计划将其提交标记为“Not Applicable”。该回复列出了可能的原因，并邀请他提供能够显示安全或隐私影响的证据。

这一分类与 Meta 的说法一致，即用户只能访问各自隔离的环境。但这并不能决定，该行为是否值得在赏金计划之外进行产品调整。

安全计划通常会将可利用的跨边界访问与加固机会区分开来。一项发现可能不符合赏金规则，却仍会暴露出令人困惑的授权模型或不必要的信息暴露面。

这一事件发生时，Muse 仍是一款新产品。Meta 于 9 月 8 日在美国推出了该代理，覆盖移动设备、网页以及基于 WhatsApp 的交互。

一份独立发布报道强调了 Meta 对安全和隐私的定位。报道还将 Muse 描述为能够发送电子邮件、预订旅行和管理长期项目的代理。

这一背景提高了风险等级，但并未证明发生了泄露。Muse 不只是一个在一次性聊天中回答问题的工具；它被设计为能持续跨越包含有价值个人信息的服务采取行动。

因此，用户不应将这一事件视为每个 Muse 账户都已暴露的证明。同样也不应假定，仅凭隔离就能阻止代理将可读取的信息转移到一个已获授权的目的地。

现有证据支持一种中间立场。在已公开的测试中，隔离边界似乎得以维持；但披露边界的表现并不一致，并暴露出比许多用户预期更多的内部材料。

Meta Muse 用户接下来应关注什么

下一阶段应以具体的产品行为来衡量，而不是看 Meta 或其批评者谁能赢得“泄露”一词的争论。

第一个信号是文件系统访问是否出现可复现的变化。Meta 表示，用户可看到的虚拟机信息量可能会有所调整。研究人员应测试，在新会话中，受保护目录是否会受到一致且由工具强制执行的限制。

强有力的更新应在归档前识别文件类别。它应阻止或删除凭证、平台指令、运行日志和内部代码，而不依赖模型的对话判断。

第二个信号是 Meta 如何处理批量外传。Sentinel 已会评估网络请求和连接器操作。Meta 应澄清，归档创建和大文件传输是否会根据内容、规模、目的地或敏感性接受额外审查。

有意义的审批应说明哪些内容将离开虚拟机。当一个文件混合了系统组件、个人记忆、执行痕迹及可能的密钥材料时，“上传一个文件”这一说法过于模糊。

第三个信号是对隔离的独立验证。研究人员需要证据表明，导出的 SSH 密钥、套接字或运行时脚本是否能连接到分配环境之外的任何内容。

如果这些产物始终被限制在一个用户的虚拟机内，Meta 的狭义辩护就更有说服力。如果任何产物跨越了账户或基础设施边界，严重性将显著改变。

Meta 也应更清楚地说明所有权模型。用户需要知道，Muse 虚拟机的哪些部分属于他们可以检查、导出、删除或迁移的内容。

该政策应区分用户文档与 Meta 的专有运行时材料。它还应说明记忆记录、对话痕迹、生成的应用程序和代理指令如何归入这些类别。

开发者和企业买家也应对每一款个人代理提出同样的问题：模型能读取什么、其工具能导出什么，以及哪些控制措施独立于模型运作？

不要将聊天机器人的拒绝视为某项操作不可能实现的证据。一次拒绝只能证明，在一组特定条件下，有一个回复拒绝了该请求。

对于敏感部署，应为连接器授予实际可行的最小权限。分离读取与写入权限，审查审计记录，并在导出行为变得可预测之前避免连接高价值账户。

Meta Muse 的文件系统导出并非隔离失效的证据。它证明的是，隔离只回答了代理安全问题中的一个部分。

更重要的考验是，Meta 能否将其文档化架构转化为在普通对话中仍保持一致的控制措施。在将更广泛的个人或业务访问权托付给 Muse 前，用户应关注这些控制措施。