我们如何为Muse构建安全体系

今天我们发布了Muse——我们的个人Agent。自2026年初以来，我们自己一直在研发和使用Muse。刚上手时，我们就看到了真正意义上的个人超级智能的曙光：一个了解你、能替你办事、在后台默默工作、能指挥一群子智能体、能自己造工具、甚至能自我改造的Agent。

但这也是我们第一次把收件箱、日历和一个shell交给一段软件，让它无人值守地跑起来——结果并不总是如我们所愿。要让这项技术真正服务于每个人，必须经过精心的设计和工程打磨，让它运行得更安全。这篇文章要讲的，正是我们在这上面下的最大功夫。

我们训练模型时，专门针对这类Agent最关键的能力做了强化：用CLI和技能做零样本工具调用、长上下文、长轨迹指令跟随（天然具备提示词注入防范意识）、多智能体协同。

但无论模型内核多强，这类Agent都会犯错，也会时不时被它读到的数据攻击。所以我们设计系统时就假定Agent可能正在被攻击，并把潜在破坏压到最小——执行框架运行在独立的隔离单元里，看不到真实凭证，所有与外界的交互都要经过一道Agent无法绕过的Sentinel哨兵。Muse照样会犯错，但得益于这套安全体系，犯错的频率会低得多，造成的破坏也会小得多。

我们在大量内部试用、Agent红队测试，以及私人漏洞赏金计划中安全研究人员发现的真实对抗场景里，不断加固Muse。今天，我们把Muse漏洞赏金计划向所有人开放，欢迎大家负责任地披露问题。有效报告最高可获得30万美元奖金，其中针对单用户的提示词注入攻击成功案例最高可获13万美元。

把Muse底层的工作原理讲透，是希望你对"实际用起来到底能多信任它"有个具体的概念。下面描述的是发布时的系统状态。当然，我们会持续关注威胁态势的变化，并随之调整。

现状概览

云端专属电脑里的Agent

你和你的Muse共享一台云端专属电脑。Muse就住在里面，你接入的所有服务的数据和凭证都安全地存放在这里。每台虚拟机都是一台隔离的Linux机器，配有浏览器，以及足以干实事的存储、CPU和内存——比如编译Agent写的代码、开发自定义技能、同时调度多个子智能体和定时任务。

你的电脑，你的数据

这台专属虚拟机是你放进Muse的一切数据的权威记录。下文会讲到，Muse只在必要时把有限的数据传出虚拟机，用于推理和遥测。

客户端

Muse客户端（iOS和Android应用、网页版）通过安全的传输层直连你的虚拟机。

连接器

把邮箱等系统（甚至你的车、你的家）接进来，Muse才最好用。我们已经为第三方系统和Instagram、Facebook等Meta系应用做了一批初始连接器。每个连接器我们都和服务商密切配合做API对接，并反复打磨SKILL——也就是给Muse的详细操作说明，教它把每个连接器用出最大价值。如果某个服务有自己的API或CLI，Muse还能自己为你写自定义连接器。

Muse安全虚拟机

这台虚拟机的结构经过精心设计，用Linux隔离原语把"你和你的Muse的活动"和"我们为保你安全而内置的一切"隔离开。正确的心理模型是：一台机器上两个隔离的安全域，而不是"一个拿了root权限的LLM Agent"。

Hatch是Muse在代码库里的内部代号。守护进程（核心Agent执行框架），以及存放你的工作区和文件的文件系统，还有Muse替你执行的所有二进制文件和工具，都运行在一个systemd-nspawn运行时容器里。运行时单元里的root被映射到宿主机上的一个非特权用户，所以单元里的root不是宿主机的root。这个单元有自己独立的根文件系统（一套完整的Debian镜像），与存放你更敏感数据的宿主机文件系统完全隔离。它还有独立的虚拟网卡、经过过滤的系统调用（比如禁用了io_uring）、受限的内核权限（比如没有CAP_SYS_PTRACE和CAP_NET_ADMIN）。

安全敏感的服务运行在运行时单元之外。这种划分很关键，因为运行时单元注定要处理不可信数据。这些服务以独立的systemd单元运行：

• hatch-safety运行一套独立的模型和分类器，检查进出核心模型推理的请求和响应。这对管控前沿风险、识别提示词注入等威胁很重要。把它们放在运行时单元之外，攻击者就关不掉这些防护。
• privsep工作进程以严格限定的权限执行内置连接器代码，让连接凭证始终处于Agent的触及范围之外。
• hatch-authd负责凭证存储（包括你选择接入的第三方服务的OAuth令牌——存在你的虚拟机里，而不是Meta的中心化基础设施），以及凭证替代，让你的主Agent永远看不到敏感凭证。
• Sentinel是连接器动作和网络出口的唯一授权方。
• 所有持久化应用状态存在PostgreSQL数据库里，与运行时单元和凭证存储都隔离。
• 推理和遥测代理只向外部基础设施开放受限通道。

运行时单元与虚拟机内其他服务之间的所有通信都走Unix域套接字，配合SO_PEERCRED和对端ACL。这是经过内核认证的最小权限进程间通信，没有可偷的密钥。

内置的Sentinel哨兵

Sentinel是运行在宿主机侧、独立于你的Muse的另一个Agent。它是连接器动作和所有网络出口的唯一授权方。Muse只能提议动作，只有Sentinel能批准执行。

连接器

当Muse想通过连接器动作时，相关的连接器工具先在运行时单元里被调用，向Sentinel提交一份请求，说明连接器、要调用的方法、动作类别、作用范围，以及用户原本想要什么，Sentinel据此生成一条用户可见的申请理由。Sentinel根据你设定的连接器策略，决定这个动作是放行、拒绝，还是先问你。

网络出口

每一个具体的网络请求都要在出口处过Sentinel这一关。运行时流量经由一台前置代理到达Sentinel，代理用Linux网络控制手段（userns、veth边界和eBPF过滤）做了隔离。Sentinel可以在第4层和第7层两个层面评估目标：主机名、解析和最终落点的IP地址、端口、协议、HTTP方法、路径，以及解码后的实际请求内容。SSRF防护能防止"看起来是公网的主机名在DNS解析后指向内网基础设施"这类把戏。

Sentinel还负责对需要密钥或认证令牌的请求做即时凭证注入。运行时单元里的代码或工作进程能看到的永远只是一个"替代令牌"，由authd签发。请求获得授权后，Sentinel才会在网络边界把替代令牌换成从authd拿到的真实凭证。Agent永远看不到真实令牌，所以任何想靠提示词注入哄骗Agent说出真实密钥的尝试都注定徒劳。

为了平衡用户确认的信噪比，Muse用了内核级的数据流追踪，我们叫它"污染追踪出站（tainted egress）"。每个工具执行进程启动时都是干净的，一旦读了用户数据就被打上污染标记。干净的网络请求如果符合严格限定的自动放行策略，并且出站URL也通过了其他检查，就可以直接放行，不打扰用户。污染标记用来决定什么样的请求需要用户确认。被污染或无法验证的进程失去自动放行资格，走常规确认流程。实现上用eBPF的cgroup程序做网络拦截和进程归因，再加上挂在我们新增的Linux安全模块钩子上的eBPF程序做污染传播。

人在回路

当Sentinel的决定是"问用户"，它会创建一个待处理的确认请求，执行随即暂停。Sentinel把请求直接发到Muse客户端，说明要确认的具体动作。对话框直接出现在客户端UI里——而不是在你和Muse的聊天里——你的答复直接路由回Sentinel，由它执行你的决定。之后Sentinel更新它的权威授权状态，放行或拒绝相应操作。

经由人在回路授予的确认是严格的能力凭证，不是聊天里的口头建议。它们绑定在特定的连接器、目标和用例上。Muse支持一次性的、会话级的、任务级的、有时限的和永久的授权。由Sentinel决定向用户呈现哪几种授权类型，并确保后续调用与授权范围精确匹配。

重点不是事事都问你。只读的、以前放行过的、明显低风险的动作都可以一路畅行。目标是把摩擦放在真正需要你知情同意的地方，同时让日常操作顺畅无阻。这个平衡点我们会随着真实用户经验的积累持续调优。

最小权限

"永远不让模型看到API密钥"就是最小权限原则的一个例子。模型不需要看到API密钥——那就别让它看到——这样它就没法通过别的渠道无意中泄露出去。Muse把这条原则用到了所有能用的地方。比如：

很多服务都有读和写两种操作。用户一般更愿意先给Agent读权限（比如"读我的日历，帮我标出冲突"），等实际体验过系统表现再考虑给写权限（比如"帮我约新的会议"）。只要底层服务支持，Muse就把读写权限拆开。除了OAuth scope那种粗粒度分组，Muse还能精细控制Agent能替你做什么，一直细化到连接器、进程、凭证、请求四个层级。（举个例子：你在Gmail那边给了Muse读取的OAuth scope，通常会连带拿到Gmail设置页的访问权，但在Muse里你可以把这一项单独拿掉。）

这类Agent的常规做法是：第三方服务的CLI连接器和执行框架跑在同一个环境里。风险在于，Agent可能被提示词注入胁迫去改工具代码，用那些CLI能接触到的服务凭证干坏事。Muse用privsep把内置连接器的逻辑放到运行时单元之外、以严格限定的凭证权限运行，防护等级更高。

内置连接器的CLI跑在运行时单元里，只做参数解析、打开调用者本来就有权访问的文件，然后把类型化参数和文件描述符经由Unix套接字传出去。真正干活的业务逻辑由一个经过systemd沙箱化的工作进程执行。

每个工作进程用cgroup标识，有明确的凭证白名单。日历工作进程不可能靠改个请求参数就从authd要到邮箱凭证。

• Privsep决定"有凭证能力的代码"在哪里执行
• Authd决定"经过认证的调用者"能拿到哪些凭证材料
• Sentinel决定"请求的动作"能不能干

浏览器也是一样的路数。CDP连接由运行时单元之外的一个代理管理，浏览器Agent拿到的只是一个窄而受控的接口。

对于内置连接器，我们还认真想过：这些服务和你的生活贴得这么近，怎么给Muse更安全的访问？想想你的主邮箱：里面躺着大量一次性验证码，你的邮箱账号还能靠"忘记密码"链接重置你几乎所有其他账号。把邮箱接给Muse，绝不能让Agent、或胁迫Agent的人，顶着你的身份去别的网站为所欲为。所以Muse的邮件连接器用确定性过滤加分类器模型两道手段，把一次性令牌、密码重置链接和登录魔法链接过滤掉。

纵深防御

和所有AI系统一样，Muse会犯错，也不得不在对抗环境里干活。我们用纵深防御的思路，把任何一层的故障影响都压到最小。拿防提示词注入这套组合拳举例：

Simon Willison在2025年6月提出了"致命三要素"，用来描述提示词注入成立的前提条件，这个问题让我们着迷至今。

致命三要素是指：

• 能接触你的私人数据——这本来就是工具最常见的用途！
• 能接触不可信内容——攻击者控制的文本（或图片）能以任何方式进入你的LLM。
• 能对外通信，并可能被用来偷你的数据（我常叫它"数据外泄"）。

如果你的Agent同时具备这三样，攻击者就能轻易哄它去读你的私人数据，再发给攻击者。

——Simon Willison

我们用纵深防御来防提示词注入造成实质伤害：

• 模型层训练——我们的模型专门训练过识别和抵抗提示词注入。我们做了一套严格的评测，能持续跟踪这个指标上的模型表现。Muse Spark 1.3在这项能力上接近SOTA。
• 执行框架层防护——任何外部来源的数据进入模型上下文时都会被打上"不可信输入"标签。配合模型"更强地跟随开发者指令"的能力，模型在有害数据面前"听谁的、不听谁的"的判断力会被进一步放大。
• 一组提示词注入检测分类器，训练数据来自真实数据集里的注入尝试，加上我们对经由文件和工具调用进入模型上下文的所有外部数据做的大规模Agent红队测试。它们并行运行，一旦发现操纵Agent行为的企图就果断处置。这套系统和模型独立训练，整体准确率显著更高。
• 上文说过的人在回路确认，管住一切流出虚拟机的数据动作。

在Agent之下，我们同样做了纵深防御：就算Muse被说服去干坏事，确定性边界依然有效。运行时单元限制系统访问，privsep限定哪些代码能看到哪些凭证，authd执行ACL，Sentinel评估每一个动作和所有网络出口。

浏览器

Muse有一个跑在虚拟化层后面的、真正的最新版Chromium浏览器。用户能看到Muse在浏览器里的一举一动，随时可以接管。模型从网上看到的数据（文本或图片）里藏着提示词注入或操控，是另一条重要攻击链，我们在上面提到的防护之外又加了几层。

• 用户最常用的场景之一就是在浏览器里登录网站。和处理API令牌的思路类似（但换了一套和密码管理器配合更好的定制UI），我们在客户端上弹定制界面收你的用户名密码，直接路由给authd，存进运行时单元之外的安全凭证库。你输入的东西直达安全存储，主Agent看不见，只在需要时注入浏览器窗口。
• 驱动浏览器完成用户目标，正是Muse Spark 1.3模型最擅长的。Muse用专门的浏览器子智能体做每个任务——读页面、逛网站、填表单等等。这个子智能体有一套专门的网页版指令，告诉它哪些内容可能是对抗性的。
• 浏览器由独立的代理管理Chrome DevTools Protocol连接。驱动浏览器的子智能体看到的是页面的无障碍树快照——不是原始DOM（这也意味着它读不到从凭证库填进去的密码，也没法从DOM里反向抠出来）。它不能在页面上下文里跑JavaScript，没有脚本动词，浏览器进程里不能exec，Chrome开发者工具也被禁用。用户接管浏览器、或安全凭证库正在填表单时，Agent会被暂停，完全动不了。
• 此外我们还做了一组分类器，在Muse用浏览器时提供另一层独立防护，按检测到的威胁类型，或直接拦截动作，或请用户复核即将发生的事。它们盯着：
  • 经由浏览器外泄与当前任务无关的个人数据；
  • 网页DOM里藏着的提示词注入企图；
  • 网页图片/媒体里藏着的提示词注入企图；
  • 经由浏览器下载的文件里藏着的提示词注入企图；
  • 高风险表单的提交企图。
• 最后，Meta已有一套系统，能检测和拦截经由旗下应用帖子或广告指向的恶意网站。我们能在你的虚拟机里直接比对这份名单，阻止浏览器导航到已知的有害站点。

购物支付

用Muse买东西是最受欢迎的浏览器场景之一，错了可是真金白银，所以我们格外小心。如果你在已经存过支付凭证的网站购物，浏览器能识别出你到了结账页，每次都弹起人在回路确认，把购买明细原样摆在你面前。在没买过的网站，Muse内置钱包可以合规地存支付凭证。发布时我们接入了Stripe Link，Shop Pay随后就到。付款时发的是一个一次性卡号，给到商户网站的是它，而不是你的真实信用卡。每一次都会有人在回路确认。这个凭证绑定特定商户、特定金额，只在有限时间内有效。就算被提示词注入或其他攻击偷走，对攻击者也没什么用。

漏洞赏金

我们靠持续的Agent红队测试来建立对系统的信心，过程中还攒出了一套极难的评测集，用于离线评估我们的防护。另外，这一年我们一直通过漏洞赏金计划和外部安全研究人员合作。今天，这个漏洞赏金计划向所有愿意负责任披露问题的人开放。有效报告按实际影响最高可获30万美元奖金，包括成功的提示词注入攻击。

即将推出：Muse机密虚拟机

我们做Muse的初衷，是让它默认成为你个人信息的谨慎管家，透明和可控长在使用体验里。今天的Muse架构把每个用户的数据相互隔离并保护起来，用运营政策限制Meta员工访问你的数据。但这并不能从技术上阻止Meta在必要时为支持、保护或运营服务而访问数据。

我们相信，人们应该能为个人Agent选择一种完全隐私的模式，连Meta或任何其他服务商都看不到、也动不了你的信息。

所以我们正在重注投入Muse机密虚拟机，计划今年晚些时候交付。Muse机密虚拟机的目标，是用密码学和可验证的方式让Meta无法访问你虚拟机里的数据。现在已经有一小批受信任的测试者在用这套系统，我们也开始把设计和源代码交给外部审计。正在吸收审计反馈，发布后会有持续审计，任何人都能查看和检验。专家们将能确认Meta确实没有能力访问机密虚拟机环境里的数据。也欢迎安全和隐私专家联系我们，申请抢先体验这个版本。你们的参与和审视会让它更强。（联系邮箱：muse-security@meta.com。）

我们的数据政策

把最敏感的数据交给Muse，是信任之举。我们的设计对得起这份信任。你放进虚拟机的所有文件、Muse替你生成或使用的所有东西，都存在那里。你可以自由查看、编辑、下载这些文件，包括Muse关于你的记忆。第三方服务的凭证和认证令牌也一样——它们存在你虚拟机里一个独立的隔离容器中，不在Meta的其他服务里。虚拟机数据持续备份，出了问题可以恢复。

Muse不会把你的对话或虚拟机里的数据共享给Meta广告系统。但有些合理场景下，你用Muse的方式确实会影响你看到的广告。Muse上网时算的是你的活动：比如你让Muse去某个设计师网站买件衬衫，设计师可能拿你的这次访问在Instagram上给你推广告。同样，让Muse订餐厅、在Facebook Marketplace上找好物，也可能间接影响广告。

推理数据——你和你的Muse之间来回的对话、产生的工具调用和子智能体交接（"轨迹"）——是训练核心LLM新版本的有用数据。为了保护隐私，这些轨迹在用于训练前会做清洗，去掉关键的个人可识别信息。我们觉得这是个好的默认设置：每个人用Muse的集体经验，都会让个人Agent更懂人间烟火。如果你完全不想让数据用于模型训练，在Muse设置里一键就能关掉。

结语

Muse不是刀枪不入。提示词注入仍是全行业没解开的难题，Muse也会犯错。我们的设计，是在出问题时把影响框住，让用户始终掌控局面，又不被打扰到心烦。

有两件事对我们帮助最大。如果你是安全研究人员，或者就喜欢拆东西，漏洞赏金计划今天开放。悬赏成功的提示词注入攻击，不是因为我们觉得它不可能，而是因为这条安全最佳实践能最快改善Muse在真实世界里的表现。如果你是隐私专家，欢迎来帮我们把Muse机密虚拟机打磨好——我们想和少数专家深度合作，在产品上市过程中一路请你们把关。