桌面端 AI 代理正在获得越来越高的系统权限，而它的攻击面也随之从云端蔓延到本地。
发生了什么
据 The Verge 报道，Meta 已为其 Muse macOS 应用发布补丁，修复一个已被发现的零日漏洞。该漏洞由安全研究员 Patrick Wardle 找出，问题出在 Muse 中一个未公开的设置项：攻击者只要能在本机运行代码，就可能利用它把转录处理从 Meta 的服务器重定向到别处，进而取得对 AI 代理的控制权。
需要说明的是，目前公开的信息仅限于此——漏洞的具体利用链、影响范围、是否存在在野利用，Meta 与研究者都未给出更多细节。
为什么重要
这起事件的价值不在于漏洞本身有多复杂，而在于它暴露了 AI 代理这类产品的一个结构性风险。
传统桌面软件的漏洞，通常止步于读取文件或提权。但 AI 代理不同：它天然被设计成"能替你做事"——读取屏幕、访问文件、调用外部服务、把内容发往云端。一旦攻击者能改写代理的数据流向，比如把本该发往官方服务器的音频转录请求指向自己的端点，那么被劫持的不只是数据，还有代理后续的决策与动作。
换句话说，AI 代理把"输入通道"和"执行能力"绑在了一起。过去一个被污染的输入最多是隐私泄露，现在它可能直接变成对用户账户、文件乃至第三方服务的操作权限。
另一个值得注意的点是"未公开设置"这个细节。这类隐藏开关常见于产品迭代期，用于灰度或调试，但它们往往缺少与正式功能同等的安全审查，也更容易被忽视。对快速迭代的 AI 应用来说，这是一个容易被低估的盲区。
影响与看点
对普通用户而言，最直接的动作是尽快更新 Muse 到已修复版本。由于该漏洞需要攻击者先在本机执行代码，风险并非无差别扩散，但"本地代码执行"在现实中并不罕见——恶意 npm 包、被投毒的下载、钓鱼附件都可能成为入口。
对开发者与安全团队，这更像一个提醒：AI 代理类应用需要把"数据出站目标"当作安全边界来管理。转录、推理、工具调用这些环节的端点配置，应当被显式约束、可审计，而不是依赖隐藏设置或运行时默认值。
对行业来说，Muse 事件是 AI 代理安全议题的一次预演。随着更多厂商把代理能力下沉到系统层，类似的本地劫持、端点重定向、权限越界只会更频繁。谁能先把代理的"能力"和"信任边界"拆开设计，谁就更可能在下一轮竞争中少踩坑。
一个独立判断：AI 代理的安全讨论，正在从"模型会不会说错话"转向"代理会不会被夺走方向盘"。后者才是真正需要工程化解决的问题。
