Meta 发布个人智能体 Muse 并公开其安全架构与漏洞赏金计划

跳转到主要内容

* AI 研究
* AI 开发者

试用 Muse

我们如何将安全性融入 Muse

2026 年 9 月 8 日·20 分钟阅读

Tarek Sheasha，软件工程师兼 Meta Superintelligence Labs 副总裁

[视频 1](blob:https://research.meta.ai/70389970-0fa5-4a06-8981-f07e948a724c)

播放 Tarek Sheasha 介绍 Muse Secure VM 及其安全、隐私和安全保护措施。播放

显示字幕 Tarek Sheasha 介绍 Muse Secure VM 及其安全、隐私和安全保护措施。显示字幕静音 Tarek Sheasha 介绍 Muse Secure VM 及其安全、隐私和安全保护措施。静音

Tarek Sheasha 介绍 Muse Secure VM 及其安全、隐私和安全保护措施。播放位置 0:00，共 1:47

今天我们推出了 Muse——我们的个人智能体。自 2026 年初以来，我们一直在研发并使用 Muse。一开始使用它，我们就看到了真正的个人超级智能的曙光——一个了解你、真正能做事、在后台工作、启动子智能体集群、构建自己的工具并自我编辑的智能体。

这也是我们第一次把收件箱、日历和一个 shell 交给一个软件，让它无人值守地运行——而这并不总是按计划进行。要让这项技术为所有人服务，需要精心的设计和工程来实现更安全的运行。这个项目的大部分精力都投入在这里，本文将详细解释我们的方法。

我们训练模型时特别关注了这类智能体至关重要的领域：使用 CLI 和技能的零样本工具调用、长上下文、具有对提示注入内在感知的长轨迹指令遵循，以及多智能体协调。

无论模型的核心能力有多强，这样的智能体仍然会犯错，有时还会通过它读取的数据遭到攻击。因此我们将系统设计为假设智能体可能正受到攻击，并限制潜在损害——执行框架运行在自己的隔离单元中，看不到真实凭证，与外部世界的每一次交互都经过智能体无法覆盖的 Sentinel。Muse 仍然会犯错，但由于我们内置的安全系统，我们预计错误会少得多，造成的损害也会小得多。

我们基于大量的内部试用、智能体红队测试，以及安全研究人员在我们的私密漏洞赏金计划中发现的真实对抗场景问题，对 Muse 进行了加固。今天，我们向所有人开放 Muse 漏洞赏金计划，以便负责任地披露问题。该计划对有效报告最高奖励 30 万美元，其中对影响单个用户的成功提示注入尝试最高奖励 13 万美元。

通过详细介绍 Muse 的内部工作原理，我们希望让你了解在实践中可以如何——以及在多大程度上——信任它。以下描述的是发布时的系统。当然，我们将继续关注不断变化的威胁态势，并根据需要做出调整。

形势概览

你自有云计算机中的智能体

你和你的 Muse 在云端共享一台专属计算机。这里是你的 Muse 生活的地方，也是你连接的任何服务的所有数据和凭据安全存储的地方。每台虚拟机（VM）都是一个隔离的 Linux 盒子，配有浏览器以及足够的存储、CPU 和内存来完成实际工作——比如编译 agent 编写的代码、开发自定义技能，以及处理并发的子 agent 和定时任务。

你的计算机，你的数据

你的专属 VM 是你放入 Muse 的一切内容的记录系统。如下所述，Muse 在推理和遥测必要时会从 VM 向外发送有限的数据。

客户端

Muse 客户端（iOS 和 Android 应用、Web UI）通过安全传输层直接连接到你的 VM。

连接器

当你把 Muse 连接到你的电子邮件以及汽车或家居等其他系统时，它才最有用。我们构建了一套初始连接器，用于连接第三方系统以及 Instagram 和 Facebook 等其他 Meta 应用。对于每个连接器，我们都与服务提供商紧密合作以集成其 API，并且我们编写并迭代了 SKILL——给 Muse 的详细指令——以充分利用每个连接器。如果其他你关心的服务有自己的 API 或 CLI，Muse 也可以为它们编写自己的自定义连接器。

Muse 安全 VM

VM 经过精心构建，使用 Linux 隔离原语将你和你的 Muse 所做的事情与我们所构建的一切隔离开来，以保障你的安全。正确的心智模型是一台机器上的两个隔离安全域，而不是一个拥有 root 权限的 LLM 驱动的 agent。

Image 3: Muse system architecture showing user controls, the isolated runtime cell, host-side safety and credential services, Sentinel, and connections to external services.

The Hatch1Hatch 是我们在代码库中对 Muse 的内部称呼。守护进程（核心 agentic harness）以及包含你的工作区和文件的文件系统，还有 Muse 代表你执行的所有二进制文件和工具，都在一个 systemd-nspawn 运行时容器中运行。运行时单元内的 root 被映射到非特权主机用户，因此运行时单元内的 root 不是主机 root。该单元拥有自己的根文件系统（包括完整的 debian 镜像），与存放你其他更敏感数据的主机文件系统分离。它还获得一个虚拟网络接口、经过过滤的系统调用（例如没有 io_uring）以及有限的内核能力（例如没有 CAP_SYS_PTRACE 和没有 CAP_NET_ADMIN）。

安全敏感服务存在于运行时单元之外。这种分离很重要，因为运行时单元预计会处理不受信任的数据。这些服务作为独立的 systemd 单元运行：

hatch-safety 运行一组独立的模型和分类器，检查进出核心模型推理的请求和响应。这些对于控制前沿风险和识别其他威胁（如提示注入尝试）非常重要。在运行时单元之外运行这些意味着攻击者无法禁用这些保护。
privsep 工作进程以严格限定的权限执行内置连接器代码，使连接的凭据保持在 agent 的范围之外。
hatch-authd 负责凭据存储（包括你选择连接的第三方服务的 OAuth 令牌——这些存储在你的 VM 中，而不是集中式 Meta 基础设施中）以及凭据代理，因此你的主 agent 永远不会看到敏感凭据。
Sentinel 是连接器操作和网络出口的唯一权限机构。
所有持久应用状态都存储在一个 postgres 数据库中，与运行时单元和凭据存储分离。
用于推理和遥测的代理暴露了通往外部基础设施的受限路径。

运行时单元与虚拟机中其他服务之间的所有通信都通过带有 SO_PEERCRED 和 peer ACL 的 Unix 域套接字进行。这提供了内核认证的、最小权限的进程间通信，且没有可被窃取的机密。

内置哨兵

Sentinel 是独立于你的 Muse 的主机侧代理。它是唯一拥有权限的机构，负责批准通过连接器对第三方服务执行操作，以及所有网络出口。Muse 提出操作建议，但只有 Sentinel 才能授予执行操作的权限。

连接器

当 Muse 想要通过连接器执行操作时，相关的连接器工具会在运行时单元中被调用。该工具会向 Sentinel 提交请求，描述连接器、要调用的方法、操作类别、其范围，以及用户所提请求的上下文，Sentinel 据此生成用户可见的请求目的。Sentinel 评估由用户设置的连接器策略，并决定该操作应被 允许、拒绝，还是询问用户。

网络出口

每个具体的网络请求在出口处都由 Sentinel 管控。运行时流量通过一个配置了 Linux 网络控制（userns、veth 边界和 eBPF 过滤）的正向代理到达 Sentinel。Sentinel 可以在第 4 层和第 7 层评估目标：主机名、解析后的最终目标 IP 地址、端口、协议、HTTP 方法、路径，以及实际解码后的请求。SSRF 限制可防止看似公开的主机名在 DNS 查询后解析到私有基础设施。

Sentinel 还会为任何需要机密或认证令牌的请求执行即时凭据插入。对于所有此类请求，运行时单元或工作进程中的代码只会看到由 authd 铸造的“代理”令牌。在具体网络请求获得授权后，Sentinel 会在网络边界处将任何代理令牌替换为从 authd 获取的真实凭据。代理永远不会看到真实令牌，这意味着任何通过提示注入或其他方式胁迫代理泄露真实机密的尝试都是徒劳的。

为了平衡用户批准的信噪比，Muse 使用内核级数据流跟踪，我们称之为“污点出口”。每个工具执行进程都从干净状态开始，如果读取了用户数据就会被污染。已经符合狭义自动允许策略——并且还通过出站 URL 的其他检查——的干净网络请求，可以在不打扰用户的情况下被放行。污点信息用于确定对请求的合适用户批准。被污染或无法验证的进程会失去自动允许，并回退到正常的批准流程。该实现使用 eBPF cgroup 程序进行网络拦截和进程归因，外加我们为污点传播添加的挂接到 Linux 安全模块钩子上的 eBPF 程序。

人在回路中

当 Sentinel 的决定解析为询问用户时，Sentinel 会创建一个待批准项，执行随即停止。Sentinel 将该请求直接发送到 Muse 客户端，描述要批准的确切操作。对话框会直接在客户端 UI 中呈现给用户——而不是通过他们与 Muse 的对话——用户的回答会直接路由回 Sentinel，由其根据用户的决定采取行动。Sentinel 随后更新其权威批准状态，并允许操作继续或酌情拒绝。

通过 human in the loop 系统授予的批准是严格的能力，而非对话式建议。它们绑定到特定的连接器/目标和使用场景。Muse 支持获取一次性、会话范围、任务范围、时间限制或永久权限。Sentinel 决定呈现哪些授权类型供用户选择，并确保后续调用与授予的范围完全匹配。

关键不在于事无巨细地询问用户。只读的、先前已允许的或明显低风险的操作可以无中断地进行。目标是在同意至关重要的地方设置阻力，同时让日常操作顺畅进行。随着我们对真实用户经验的积累，这种平衡是我们预期会随时间调整的。

最小权限

从不向模型展示 API 密钥，是我们应用最小权限原则的一个例子。模型不需要看到 API 密钥——所以它看不到——这意味着它无法通过其他途径意外泄露它们。Muse 在一切可能的地方应用这一原则。例如：

许多服务支持读和写操作。用户往往更愿意授予其 agent 对自己数据的读取权限（例如，“读取我的日历以向我标记冲突”），并倾向于花时间了解系统在实践中的运作情况后，再授予写入权限（例如，“为我安排新会议”）。在底层服务支持的情况下，Muse 将读取和写入权限分开。Muse 还提供细粒度控制，精确规定 agent 可以代表用户执行哪些操作，超越通常作为 OAuth 范围暴露的粗粒度分组。（例如，如果你在 Gmail 一侧授予 Muse Gmail 读取访问的 OAuth 范围，你可以移除通常随之而来的访问 Gmail 设置的能力）。系统在连接器、进程、凭据和请求级别增加了更细粒度的控制。

对于像 Muse 这样的 agent，一种标准做法是为第三方服务提供基于 CLI 的连接器，它们与 harness 运行在同一环境中。一个风险是，agent 可能通过提示注入被胁迫更改工具代码，利用这些 CLI 有权访问的服务凭据做坏事。Muse 通过将内置连接器的逻辑运行在运行时单元之外，并使用 privsep 进行严格限定的凭据访问，实现了更高程度的保护。

内置连接器的 CLI 运行在运行时单元中，它们只是解析参数、打开调用者已被允许访问的任何文件，并通过 Unix socket 传递类型化参数和文件描述符。然后由 systemd 沙箱化的 worker 执行工具的业务逻辑。

每个 worker 由其 cgroup 标识，并具有明确的凭据允许列表。日历 worker 不能仅仅通过更改请求参数就向 authd 索要电子邮件凭据。

Privsep 决定具备凭据能力的代码在哪里执行
Authd 决定经过身份验证的调用者可以接收哪些凭据材料
Sentinel 决定所请求的操作是否可以执行

浏览器遵循类似的模式。CDP 访问位于运行时单元之外的代理中，浏览器 agent 获得一个狭窄、受控的接口来访问它。

对于内置连接器，我们还仔细考虑了如何在 Muse 深度融入你生活的情况下，为它提供更安全的访问权限。想想你的主邮箱收件箱：你可能会在那里收到很多一次性令牌验证码。而且，通过点击“忘记密码”链接，你的邮箱账户很可能可以用来重置你在网上使用的大多数其他账户的密码。将你的邮箱连接到 Muse，不应允许该智能体或胁迫该智能体的其他人代表你在其他网站上行事。因此，Muse 的邮箱连接器通过确定性过滤器和分类器模型，过滤掉一次性令牌、密码重置链接和登录魔法链接。

纵深防御

像任何 AI 系统一样，Muse 有时也会犯错。它还需要在对抗性环境中行动。我们应用纵深防御的理念，来限制技术栈中任何一层出现问题所造成的影响。我们为降低提示注入危害风险所采取的方法就是一个很好的例子。

Simon Willison 在 2025 年 6 月创造了“致命三要素”一词，用来描述提示注入的前提条件，而这个问题一直是我们关注的焦点。

致命三要素的能力包括： * 访问你的私人数据——这本来就是工具最常见的用途之一！ * 接触不可信内容——任何能让恶意攻击者控制的文本（或图像）进入你的 LLM 的机制。 * 能够以可用于窃取你数据的方式对外通信。（我常把这称为“数据外泄”……）。如果你的智能体同时具备这三种特征，攻击者就能轻易诱使它访问你的私人数据并将其发送给攻击者。 – Simon Willison

我们采取纵深防御的方法来防止提示注入造成危害：

模型层面训练——我们的模型经过训练，能够识别并抵抗提示注入。我们开发了一套严格的评估，使我们能够随时间跟踪模型在这一指标上的表现。Muse Spark 1.3 在这项能力上接近 SOTA。
框架层面保护——当数据从任何外部来源进入模型上下文时，它会被标记为不可信输入。这一点，加上模型更强地遵循开发者指令的能力，意味着在存在潜在有害数据时，模型理解应遵循哪些指令、应忽略哪些指令的核心能力得到放大。
多个提示注入检测分类器的集成，这些分类器经过训练，能够检测真实数据集中发现的提示注入尝试，以及我们自己的规模化智能体红队测试，针对通过文件和工具调用进入模型上下文的所有外部数据运行。它们彼此并行运行，并在发现操纵智能体行动的尝试时，能够采取坚决行动。通过独立于模型训练这一系统，我们可以在整体上实现显著更高的准确率。
如上所述，对于将数据移出 VM 的操作，需要人工在环审批

在智能体之下，我们也有纵深防御：即使 Muse 被说服做出不良行为，确定性边界仍然适用。运行时单元限制系统访问，privsep 限制哪些代码可以看到哪些凭据，authd 应用 ACL，Sentinel 评估每一个操作和所有网络出口。

浏览器

Muse 在虚拟化层后面运行着一个真正最新的基于 Chromium 的浏览器。用户可以看到 Muse 在浏览器中做什么，并随时接管。通过 Muse 在网络上观察到的数据（无论是文本还是图像）对模型进行提示注入/引导，是另一个重要的攻击向量，我们对此应用了上述之外的额外保护措施。

用户最常见的需求之一是在浏览器中登录网站。与 Muse 处理 API 令牌的方式类似，但使用不同的自定义 UI，以便更好地与密码管理器集成，我们在客户端提供一个自定义 UI 来捕获你的用户名和密码，将它们直接路由到 authd，并将它们存储在 Muse VM 中运行时单元之外的安全凭据存储中。你输入的内容直接进入安全存储，对你的主代理不可见，但会在需要时注入到浏览器窗口中。
驱动网络浏览器来实现用户的目标是 Muse Spark 1.3 模型特别擅长的事情。Muse 使用一个特殊的浏览器子代理来完成每项任务——阅读页面、遍历网站、填写表单等。这个子代理具有类似的、针对网络的特定指令，说明内容的哪些部分可能是对抗性的。
浏览器由一个单独的管理程序管理，该程序管理 Chrome DevTools Protocol 连接。驱动浏览器的子代理看到的是页面的可访问性树快照——而不是原始 DOM。（这也意味着它无法读取从凭据存储输入的凭据，也无法手动退出 DOM。）它无法在页面上下文中运行 javascript，没有脚本动词，无法在浏览器进程中执行，并且 Chrome devtools 被禁用。当用户接管浏览器控制权时，或在安全凭据存储填写表单时，代理会暂停，完全无法行动。
此外，我们实现了一系列分类器，当 Muse 与浏览器一起工作时，它们提供另一个独立的保护层，根据检测到的威胁，它们要么阻止操作，要么提示用户查看即将发生的事情。这些分类器会留意：
* 通过浏览器外泄与当前任务无关的个人数据。
* 网页 DOM 中存在尝试的提示注入。
* 网页上通过图像/媒体存在尝试的提示注入。
* 通过浏览器下载的文件中存在尝试的提示注入。
* 尝试提交高风险表单。

最后，Meta 拥有现有系统，可以检测并阻止用户可能通过我们系列应用或广告中的帖子被引导到的恶意网站。我们能够在用户的 VM 内与该列表进行匹配，并阻止浏览器导航到已知的有害网站。

购买

使用 Muse 购物是最受欢迎的浏览器使用场景之一。由于这里的失误可能让用户损失真金白银，我们对此格外谨慎。如果你在已存有支付凭证的网站上购物，我们已在浏览器中内置了检测机制，识别你是否处于结账页面，并在每次结账时提示人工介入审批，附上此次购买的确切详情。对于你此前未曾购物过的网站，Muse 内置了一个钱包，可以合规地存储支付凭证。发布时，我们已与 Stripe Link 合作，Shop Pay 也即将上线。付款时，系统会签发一个一次性卡号，传递给商家网站的是这个卡号，而不是你的常规信用卡。每一次此类操作，我们都会提供人工介入审批。该凭证绑定特定的商家、特定的金额，并且仅在有限时间内有效。这样一来，即使它通过提示注入或其他攻击被窃取，对攻击者来说也用处不大。

漏洞赏金

我们通过持续的智能体红队测试来增强对系统的信心，这也帮助我们构建了一套非常困难的评估集，可用于离线评估我们的防护措施。此外，我们全年通过漏洞赏金计划与外部安全研究人员合作。今天，我们向所有负责任地披露问题的人开放这个漏洞赏金计划。该计划对有效报告最高奖励 30 万美元，奖励金额取决于所展示的影响，包括成功的提示注入尝试。

即将推出：Muse 机密虚拟机

我们构建 Muse 的目标是让它默认成为你个人信息的谨慎管理者，并将透明度和控制权融入日常体验。如今的 Muse 架构将每个用户的数据彼此隔离并保持安全。它通过运营政策限制 Meta 人员对你数据的访问。但在为支持、保护或运营服务所必需时，它并不阻止 Meta 访问数据。

我们认为，人们也应该能够为个人智能体选择完全私密模式，在这种模式下，即使是 Meta 或任何其他服务提供商也无法查看或授予对你信息的访问权限。

因此，我们正在大力投资 Muse 机密虚拟机，并计划在今年晚些时候交付这一能力。Muse 机密虚拟机旨在以加密且可验证的方式阻止 Meta 访问你虚拟机中的数据。我们已在与一小群受信任的测试者使用该系统，并已开始向外部审计人员提供该系统的设计和源代码。我们正在收集审计人员的反馈，一旦发布，将对该系统进行持续审计，任何人都可以看到并检查。专家将能够确认 Meta 无权访问机密虚拟机环境内的数据。我们也欢迎安全和隐私专家就这一版本产品的早期访问与我们联系。他们的合作与审视将使其更加强大。_（可通过 [muse-security@meta.com](mailto:muse-security@meta.com) 联系我们。）_

我们的数据政策

我们知道，将你最敏感的数据连接到 Muse 是一种信任之举。我们在设计 Muse 时就考虑到了这一点。你放入 VM 的所有文件，以及 Muse 代表你生成或使用的所有内容，都存储在那里。你可以自由查看、编辑和下载这些文件，包括 Muse 关于你的记忆。这同样适用于你连接的任何第三方服务的凭据和认证令牌——它们存储在你 VM 中一个独立的隔离容器里，而不是在其他 Meta 服务中。你的 VM 数据会持续备份，因此如果出现问题，你可以将其恢复。

Muse 不会与 Meta 广告系统分享你的对话或虚拟机中的数据。话虽如此，在某些合理场景下，你使用 Muse 的方式可能会影响你看到的广告。当 Muse 浏览互联网时，它会显示为你的活动，因此如果你让 Muse 从某服装设计师的网站购买一件衬衫，该设计师可能会利用你的这次访问在 Instagram 上向你展示广告。同样，如果 Muse 为你预订餐厅，或帮你在 Facebook Marketplace 上找到一件很棒的产品，这也可能间接影响你看到的广告。

推理数据，即你和你的 Muse 之间的来回对话，以及由此产生的工具调用和子代理交接（“轨迹”），是用于训练核心 LLM 模型新检查点的有用数据。为保护用户隐私，这些轨迹在用于训练前会经过净化处理，以移除关键的个人身份信息。我们认为这是一个不错的默认设置——随着我们所有人共同使用该产品，并帮助模型理解人类生活的复杂性，每位 Muse 用户都会获得更好的个人代理。如果你完全不想让你的数据被用于模型训练，可以通过 Muse 设置中的一个简单开关选择退出。

结论

Muse 并非不受攻击影响。提示注入仍是业界一个未解决的问题——Muse 有时也会犯错。我们设计该系统，是为了在出错时限制影响，并帮助用户保持掌控，而不至于不堪重负。

有两件事对我们帮助最大。如果你是安全研究员，或者只是喜欢尝试攻破系统，漏洞赏金计划现已开放。我们会为成功的提示注入攻击支付赏金——不是因为我们觉得找到它们不可能，而是因为这一安全最佳实践将帮助我们以最快速度改进 Muse 在现实世界中的表现。如果你是隐私专家，并且愿意帮助我们让 Muse Confidential VM 变得出色，请联系我们——在我们将其推向市场之际，我们希望与少数专家密切合作，为我们的工作提供建议和审查。