AI 助手正在获得越来越多的系统权限，而 Muse 的这次翻车说明，权限给得越快，安全债欠得越狠。

发生了什么

据 WIRED 报道，Meta 推出的 Muse AI 助手被曝存在一个零日漏洞。按照 Meta 的说法，该漏洞一旦被利用，攻击者可以在受害者的 Mac 上做“任何他们想做的事”。Meta 表示已经针对该漏洞发布了修复。

报道没有披露漏洞的具体技术细节，也没有说明是否已有用户受到影响。但“任意操作”这一描述本身已经足够严重——它意味着攻击者可能获得接近完全控制的能力，而非仅仅是读取某些数据。

为什么重要

这不是一次孤立的工程失误，而是 AI 助手这类产品形态自带的结构性矛盾。

传统软件的权限边界相对清晰：一个文本编辑器不需要访问你的摄像头，一个浏览器插件的能力范围可以被沙箱限制。但 AI 助手的设计目标恰恰是“替用户操作电脑”——读文件、开应用、点按钮、填表单。要做到这些，它必须拿到相当高的系统权限，并且需要一条从自然语言指令到实际系统调用的执行链路。

这条链路越长、权限越高，攻击面就越大。而 AI 助手还有一个额外的麻烦：它的输入是自然语言，天然模糊、可注入。攻击者未必需要找到内存溢出这类传统漏洞，一段精心构造的文本、一个被污染的网页或文件，就可能诱导助手执行非预期的操作。这类“提示注入”类风险在传统安全模型里几乎没有对应物。

Muse 的漏洞被定性为零日，说明它在被公开前并不为防御方所知。对一款刚推向市场的助手产品来说，这意味着安全审计的节奏没有跟上功能上线的节奏。

影响与看点

对用户而言，最现实的问题是：你愿意给一个 AI 助手多大的权限？如果它需要访问本地文件系统和应用控制能力，那么它的安全水平就必须按操作系统级组件来要求，而不是按一个聊天机器人来要求。

对开发者和平台方而言，这起事件指向几个值得关注的方向。一是权限最小化——助手是否真的需要“任意操作”，还是可以拆分成可授权、可审计的细粒度能力。二是执行隔离——高风险操作是否应强制经过沙箱或用户确认。三是可观测性——用户能否看到助手到底做了什么，而不是只看到一个结果。

对行业来说，Muse 不会是最后一个出问题的 AI 助手。当所有大厂都在把助手从“回答问题”推向“替你干活”，安全模型必须同步升级。把系统级权限交给一个以自然语言为输入、行为边界模糊的组件，本质上是在用可用性换风险。

一个克制的判断是：AI 助手的安全问题不会靠单次补丁解决，它需要的是产品设计层面的权限重构。谁先把这件事做扎实，谁才可能真正让用户放心地把电脑交出去。