从 Meta Muse 看 Agent 安全：我们究竟交出了哪些权限？

让助手查一张机票，和让它替你订票、付款，再把行程发给别人，是几件不同的事。对话可以很顺畅，权限却在每一步发生变化。

Meta Muse 让这个问题变得具体。9 月 8 日推出个人 Agent 后，Meta 又在 9 月 29 日扩展了小企业应用。它的吸引力不难理解：少一点在应用之间搬运信息的时间，多一个能帮忙把事情跟进下去的助手。个人产品发布 · 小企业应用说明

更难回答的是：为了这份方便，我们需要交出多少访问权限？助手做错事时，谁还能让它停下来？

本文依据截至 2026 年 10 月 3 日可查的公开资料写成，没有进行 Muse 实测或漏洞复现。有关设计的描述来自官方文档，事件信息来自所链接的报道。

有用，不一定意味着拥有更多权限

整理邮件、起草回复、比较行程、准备营销方案，都是容易理解的使用起点。用户可以先看结果，再决定是否采取行动。发送、购买和修改记录则不同，出错后往往需要别人一起处理。

一家小企业可能希望助手找出尚未回复的客户邮件，却不愿意让它直接退款。这不是产品能力不完整，而是合理的分工。

所以，只看任务完成率还不够。更值得计算的是：扣除检查和返工之后，到底节省了多少时间，又承担了什么后果。一次发错对象的敏感邮件，可能抵消很多次成功摘要带来的便利。

只读 Agent，也可能把数据带出去

安全研究者 Simon Willison 用三个条件描述了一类危险组合：能访问私人数据、会接触不可信内容、还可以对外通信。攻击者可能借文档中的指令，把这三种能力串起来。这是一种威胁模型，不是说所有具备这些能力的系统都已经遭到入侵。原始分析

一个邮件助手就可能遇到这种情况：它读到一封外部来信，同时能查看你的私人往来。如果它听从来信里夹带的指令，把无关邮件内容放进回复，就已经造成泄露。整个过程不需要修改数据库，用的甚至是正常的发信工具。

Meta 自己提出的 Agents Rule of Two 也讨论了这个组合。当不可信输入、敏感访问，以及外部通信或状态修改缺一不可时，它建议增加监督或可靠验证，而不是继续放任自主执行。Meta 同时说明，这套原则并不能解决所有失败模式。Meta 安全原则

因此，“只读”只说明了部分权限。读到哪些信息、之后能把它们发到哪里，同样决定着风险。

谁来批准助手的下一步？

按照 Meta 的说明，Muse 运行在专属云端虚拟机（VM）中，内部再通过 systemd-nspawn 容器将 Agent 与安全敏感服务隔离。Sentinel 管理连接器操作和网络出口，独立的凭据处理机制则避免主 Agent 直接接触底层密钥。Muse 安全架构

这种分工的价值，在一次普通的发信操作里就能看出来。用户同意把行程发给同事，并不意味着也同意发给后来换上的陌生地址。如果收件人发生变化，原来的批准就不再代表用户对这封邮件的真实意愿。

断开连接器也是如此。对用户来说，这意味着“以后别再访问了”；对后台系统来说，却可能还有排队任务、重试和已经分派出去的工作。撤销能否覆盖这些任务，决定了界面上的关闭按钮是否真的有效。

另外一些风险不太容易从界面看出来：新工具是否绕开了原有网络限制，进程能否读到任务之外的文件，失败后的反复重试会不会继续消耗预算。架构说明给出了设计思路，实际运行记录才能说明这些细节处理得怎样。

这些是沿着类似架构展开的风险分析，并非本文发现的 Muse 漏洞。OWASP 的 Agentic 安全工作同样关注工具滥用、行为劫持，以及身份和权限滥用，而不只关注提示词本身。OWASP 风险框架

苹果的提醒，把本地电脑重新拉回视野

10 月 2 日，苹果宣布计划为 macOS 的完全磁盘访问权限增加控制，让用户更明确地决定是否授予这类广泛访问。公告谈到了自主 Agent 带来的风险，但没有点名 Muse，也没有给出这些改动已在哪个系统版本中交付的信息。苹果开发者公告

这件事提醒我们：云端环境隔离得再仔细，也不能弥补本地授权过宽的问题。一个只是想整理文件夹的人，未必意识到自己可能同时开放了无关通信内容。邮件和消息里，还有从未授权这个助手的其他人的信息。

更好的产品体验，是让用户只开放完成任务所需的部分，而不是先交出广泛权限，再靠长篇提示解释风险。提示帮助人理解选择，更窄的权限则降低选择的代价。

风险提示变醒目，不代表漏洞已经修好

9 月 25 日，路透社援引 The Information 报道，研究员提交的漏洞可能影响用户专属的 Muse 云端环境，Meta 将加强安全提示。这篇报道没有证明用户数据已被窃取，也没有提供足以核验完整修复的细节。路透社报道，CNA 转载

因此，是否发生过实际泄露、修复覆盖到什么程度，仍是这份报道没有回答的问题。它与另行报道的 Mac 客户端问题是否相关，也缺少证据。

这会直接影响团队的采用判断。受影响版本和攻击前提关系到自己的环境是否在范围内；修复方式以及旧会话是否需要失效，则关系到更新后还要做什么。更醒目的警告能提醒用户谨慎，却不能替代这些信息。

付款安全，不等于买得正确

Stripe 对 Muse 的支付集成区分了两条路径：支持 Link 的商户使用已保存的支付方式，其他商户则可使用限定于获批购买的单次虚拟卡。公告说明，每次交易总额都需用户批准，Muse 不接触底层支付信息。Stripe 集成说明

这解决的是凭据暴露问题，不代表商品、商户、数量、收货地址和订阅条件都选对了。如果确认页只展示总价，用户仍可能看不出哪里出了错。付款机制之外，确认界面是否提供足够信息，同样重要。

隐私方面，“不用来训练”“不用于广告”和“服务商无法访问”也是不同的承诺。Meta 的公开说明提供训练退出选项，并区分广告与服务运营访问；发布文档中的 Confidential VM 则属于后续能力，而非当前默认保障。撰写本文时，隐私政策与服务条款全文需要登录才能查看，因此这里的分析仅限于可公开读取的说明。Meta 数据说明 · 隐私政策 · 服务条款

同样的问题，也会出现在代码审查里

审查 Agent 会读取外部 PR，可能接触私有仓库上下文，还能发布评论。这已经形成前文所说的信息外泄路径。如果继续运行 PR 中的测试，就又多了一种风险：即使模型没有听从恶意指令，不可信代码本身也可能执行危险操作。GitHub 关于不可信输入和工作流权限的安全建议，在这里依然适用。GitHub 安全指南

读取代码、运行测试、发表评论、修改代码和合并 PR，是不同权限。正常 PR 能展示助手有没有用，夹带恶意内容的 PR 则能暴露另一面：它是否读了无关文件、执行了不该执行的操作，或者把信息发到了外部。相比一句“我已拒绝”，实际执行和数据外发记录更能说明发生了什么。

这些也是 BartsAI 关注的问题。Risk Probe 可以帮助团队梳理自己报告的架构条件，50 项清单 和 Python Starter 则为进一步检查提供参考。它们是了解和测试系统的起点，不是部署安全认证。

我们不需要先回答一个 Agent 在抽象意义上是否值得信任。更实际的问题是：它拥有什么权限，做错后会发生什么，以及我们是否还能让它停下来。