Meta Muse 架构拆解为什么它的 Agent 偷不走你的密码TL;DR 速览每个用户一个隔离云 VMAgent、浏览器、数据都在里面Sentinel 独立审批Agent 只负责提议放行权不在它手里凭证代理化Agent 只看到占位 token真密钥在网络边界注入免费额度每周最高 1 亿 tokenMeta 发布了个人 AI 智能体Muse。功能清单读起来很标准替你网购、写发邮件、规划行程、填表单、跟运营商谈账单、甚至帮你卖车卖个好价。这些能力别的 Agent 也都有。但 Muse 真正值得技术人看的地方不在功能在它的安全架构。这套设计解决的是所有 Agent 都会撞上的同一个问题你要让 Agent 替你干活就必须给它权限可你一旦给它权限就相当于把钥匙交出去了。这篇不聊它能干什么聊它是怎么把钥匙管住的。这几层设计思路你自建 Agent 时能直接抄。一、先说清楚它是什么一句话Muse 是一个住在独立虚拟机里、24 小时替你干活的个人 Agent由扎克伯格本人在 X 上宣布底座是 Meta 的 Muse Spark 1.3 模型。三个关键数字每周最高 1 亿 token 免费超出走订阅每个用户一个独立的云端虚拟机Muse Secure VM美国先行iOS / Android / Web / WhatsApp 四个入口开发者视角要注意一点Muse 本身不能自托管但它的底层模型 Muse Spark 1.3 已经可以通过 Meta Model API 和 Muse Code 使用开源权重在路线图上。二、问题的本质Agent 的权限边界是工程问题先说清楚为什么这件事难。传统聊天机器人是无状态、无权限的你问它问题它给你文字它碰不到你的任何账户。而 Agent 完全不同——要替你下单它得有你的购物账号要替你发邮件它得有你的邮箱授权要替你填表它得读你的浏览器状态。于是 Agent 面临三重风险风险具体表现提示注入网页/邮件里藏一句指令Agent 照做了凭证泄露Agent 上下文里有真实密钥被诱导吐出越权操作Agent 判断失误做了你没授权的动作而这三者的根源是同一个Agent 和权限绑得太紧了。Muse 的设计思路核心就是把这两者拆开。三、Muse 的答案Secure VM SentinelMuse 的架构分两层理解这两层这套设计就通了。第一层Muse Secure VM——把 Agent 关进一个专属房间。每个用户的 Muse 跑在一台独立的云虚拟机上Agent 本体、它的浏览器、以及你连接的各种数据全部装在这个 VM 里与其他用户的实例物理隔离。更细的是它内部的进程结构Agent 的运行时harness跑在一个 **systemd-nspawn 运行时容器runtime cell**里这个 cell 做了两件事——过滤系统调用syscall、限制内核能力kernel capabilities。而安全关键的服务不在这个 cell 里放在同一个 VM 上的 cell 之外。这个分层很讲究Agent 所在的容器权限被削到最低安全服务在容器外Agent 碰不到。第二层也是最关键的一层Sentinel——一个专职审批的 Agent。扎克伯格的原话是“一个与你 Muse 分离的 Sentinel agent 跑在你的 VM 上。每一个发往网络的行动或数据都必须经过 Sentinel 批准。内核强制执行这一点它知道什么时候需要征求你的许可。”请注意这句话里三个信息量极大的词“分离”——Sentinel 不是 Muse 的一个模块是另一个 Agent。这保证了即使 Muse 被提示注入操控它也操控不了 Sentinel。“每一次”——审批不是抽样是全量拦截。“内核强制执行”——这不是应用层的君子协定是内核级的强制约束。Muse 想绕过 Sentinel 直接出网在内核层面就走不通。用一句话概括这套模型Muse 负责提议只有 Sentinel 负责放行。而且审批是在两个网络层同时做的L4传输层和 L7应用层。L4 管能不能连出去L7 管发出去的内容是什么——双层拦截避免只查一层被绕过。四、最妙的一层凭证代理化前面三层解决了能不能做这一层解决的是偷不偷得到。这是我认为 Muse 架构里最值得抄的设计。传统做法Agent 要发邮件你得把邮箱密码或 OAuth token 放进它的上下文。问题是——只要密钥在上下文里提示注入就有机会把它套出来。Muse 的做法Agent 永远看不到真实凭证。它拿到的只是一个占位 tokenplaceholder token真实密钥由 Sentinel 在网络边界注入。这个设计的精妙之处在于它让通过提示注入窃取凭证这件事在结构上失效了。不是加大了难度是没有东西可偷——Agent 的上下文里从头到尾就没有真实密钥攻击者诱导它吐出来的只是一个没有实际权限的占位符。安全设计里最高级的思路从来不是防住攻击而是让攻击失去目标。五、eBPF 污点追踪把数据敏感度变成审批门槛还有一层更细的机制内核级的 eBPF 污点追踪taint tracking。它的作用是区分请求的干净程度——一个请求如果从头到尾没接触过你的个人数据那它的风险低一个请求如果读过了你的邮件、碰过了你的账户信息那它的敏感度高审批门槛就应该更严。这个思路解决的是一个很实际的问题如果所有操作都弹窗让你确认你会烦到把 Agent 关掉如果所有操作都自动放行迟早出事。按数据接触面来分级是在可用性和安全性之间找一个动态平衡点。同类的细节还有几个浏览器子 Agent 看到的是可访问性树accessibility tree不是原始 DOM而且不能执行 JavaScript。这一刀砍掉了大量基于脚本的注入路径——网页里藏一段 JS对它是无效的。邮件连接器默认过滤一次性验证码和密码重置链接。这个设计很聪明它精准掐断了Agent 读取邮件 → 拿到验证码 → 完成身份验证这条攻击链。完整审计轨迹你随时能看到 Agent 做过什么、以及它计划做什么。六、钱的问题Agent 怎么付款Agent 一旦能花钱风险就上了另一个量级。Muse 的方案是接 Stripe 的Link为 Agent 生成单次使用的支付卡真实卡号全程不暴露。Meta 声称 Muse 是第一个受 Link 购买保护的 AI Agent保护范围包括商品损坏或丢失、符合条件的降价、免手续费退货和退货保障。后续还计划支持 Shop Pay以及通过 1Password 复用你已有的登录态。七、这五条设计原则你自建 Agent 时可以直接抄Muse 是消费级产品你未必会用它。但它的架构原则放在任何自建 Agent 上都成立原则一把执行和授权拆成两个组件。不要让同一个 Agent 既决定做什么、又决定能不能做。哪怕你的实现只是两个独立的函数调用这个边界也要划出来。原则二密钥不进 Agent 上下文。如果你现在的做法是把 API key 写进 prompt 或环境变量让 Agent 直接读那你的架构和把密码写在便利贴上没有本质区别。正确做法是让 Agent 拿占位符真实凭证由外层代理在出网时注入。原则三审批要全量不能抽样。安全机制一旦偶尔生效就等于没有——攻击者只需要找到不生效的那条路径。原则四按数据接触面分级授权。读操作和写操作分开、干净请求和脏请求分开。所有操作一律弹窗确认的 Agent 会被用户关掉一律放行的 Agent 会出事。原则五留审计轨迹。Agent 必须能回答我做了什么、我要做什么。这不是合规需求而是你在出事时唯一能复盘的东西。八、定价与可用性项目内容免费额度每周最高 1 亿 token超额订阅制入口iOS / Android / Web / WhatsApp美国先行后续集成进 Meta 智能眼镜隐私选项可关闭交互数据用于模型训练对话详情不与广告系统共享规划中Muse Confidential VM整个 VM 加密密钥仅用户持有最后那条值得单独说Muse Confidential VM 意味着连 Meta 自己都读不到你的数据。这是从我们承诺不看到我们看不了的转变——在安全设计上这两种承诺的可信度完全不在一个量级。我的判断Muse 这次发布功能层面没什么意外架构层面是一次真正的升级。它把 Agent 安全从伦理讨论拽回了工程实现Secure VM 划边界、Sentinel 收放行权、凭证代理化让攻击失去目标、eBPF 污点追踪做动态分级。这套设计的核心思想只有一个词解耦。把执行和授权解耦、把 Agent 和密钥解耦、把想做什么和能不能做解耦。而这三件事恰好是绝大多数自建 Agent 都没做的——我们习惯给 Agent 一个万能 API key然后祈祷它别出错。对技术人的实际启发是别再问我的 Agent 会不会被提示注入攻破要问如果它被攻破了攻击者能拿到什么。如果答案是一个没有实际权限的占位符那你的架构就是对的。Muse 最大的价值不是它替用户干了多少活而是它证明了一个能干脏活的 Agent也可以是一个拿不到钥匙的 Agent——这两件事从来不矛盾只是大多数人没去做那个解耦。 Meta Muse 架构拆解：为什么它的 Agent 偷不走你的密码
Meta Muse 架构拆解为什么它的 Agent 偷不走你的密码TL;DR 速览每个用户一个隔离云 VMAgent、浏览器、数据都在里面Sentinel 独立审批Agent 只负责提议放行权不在它手里凭证代理化Agent 只看到占位 token真密钥在网络边界注入免费额度每周最高 1 亿 tokenMeta 发布了个人 AI 智能体Muse。功能清单读起来很标准替你网购、写发邮件、规划行程、填表单、跟运营商谈账单、甚至帮你卖车卖个好价。这些能力别的 Agent 也都有。但 Muse 真正值得技术人看的地方不在功能在它的安全架构。这套设计解决的是所有 Agent 都会撞上的同一个问题你要让 Agent 替你干活就必须给它权限可你一旦给它权限就相当于把钥匙交出去了。这篇不聊它能干什么聊它是怎么把钥匙管住的。这几层设计思路你自建 Agent 时能直接抄。一、先说清楚它是什么一句话Muse 是一个住在独立虚拟机里、24 小时替你干活的个人 Agent由扎克伯格本人在 X 上宣布底座是 Meta 的 Muse Spark 1.3 模型。三个关键数字每周最高 1 亿 token 免费超出走订阅每个用户一个独立的云端虚拟机Muse Secure VM美国先行iOS / Android / Web / WhatsApp 四个入口开发者视角要注意一点Muse 本身不能自托管但它的底层模型 Muse Spark 1.3 已经可以通过 Meta Model API 和 Muse Code 使用开源权重在路线图上。二、问题的本质Agent 的权限边界是工程问题先说清楚为什么这件事难。传统聊天机器人是无状态、无权限的你问它问题它给你文字它碰不到你的任何账户。而 Agent 完全不同——要替你下单它得有你的购物账号要替你发邮件它得有你的邮箱授权要替你填表它得读你的浏览器状态。于是 Agent 面临三重风险风险具体表现提示注入网页/邮件里藏一句指令Agent 照做了凭证泄露Agent 上下文里有真实密钥被诱导吐出越权操作Agent 判断失误做了你没授权的动作而这三者的根源是同一个Agent 和权限绑得太紧了。Muse 的设计思路核心就是把这两者拆开。三、Muse 的答案Secure VM SentinelMuse 的架构分两层理解这两层这套设计就通了。第一层Muse Secure VM——把 Agent 关进一个专属房间。每个用户的 Muse 跑在一台独立的云虚拟机上Agent 本体、它的浏览器、以及你连接的各种数据全部装在这个 VM 里与其他用户的实例物理隔离。更细的是它内部的进程结构Agent 的运行时harness跑在一个 **systemd-nspawn 运行时容器runtime cell**里这个 cell 做了两件事——过滤系统调用syscall、限制内核能力kernel capabilities。而安全关键的服务不在这个 cell 里放在同一个 VM 上的 cell 之外。这个分层很讲究Agent 所在的容器权限被削到最低安全服务在容器外Agent 碰不到。第二层也是最关键的一层Sentinel——一个专职审批的 Agent。扎克伯格的原话是“一个与你 Muse 分离的 Sentinel agent 跑在你的 VM 上。每一个发往网络的行动或数据都必须经过 Sentinel 批准。内核强制执行这一点它知道什么时候需要征求你的许可。”请注意这句话里三个信息量极大的词“分离”——Sentinel 不是 Muse 的一个模块是另一个 Agent。这保证了即使 Muse 被提示注入操控它也操控不了 Sentinel。“每一次”——审批不是抽样是全量拦截。“内核强制执行”——这不是应用层的君子协定是内核级的强制约束。Muse 想绕过 Sentinel 直接出网在内核层面就走不通。用一句话概括这套模型Muse 负责提议只有 Sentinel 负责放行。而且审批是在两个网络层同时做的L4传输层和 L7应用层。L4 管能不能连出去L7 管发出去的内容是什么——双层拦截避免只查一层被绕过。四、最妙的一层凭证代理化前面三层解决了能不能做这一层解决的是偷不偷得到。这是我认为 Muse 架构里最值得抄的设计。传统做法Agent 要发邮件你得把邮箱密码或 OAuth token 放进它的上下文。问题是——只要密钥在上下文里提示注入就有机会把它套出来。Muse 的做法Agent 永远看不到真实凭证。它拿到的只是一个占位 tokenplaceholder token真实密钥由 Sentinel 在网络边界注入。这个设计的精妙之处在于它让通过提示注入窃取凭证这件事在结构上失效了。不是加大了难度是没有东西可偷——Agent 的上下文里从头到尾就没有真实密钥攻击者诱导它吐出来的只是一个没有实际权限的占位符。安全设计里最高级的思路从来不是防住攻击而是让攻击失去目标。五、eBPF 污点追踪把数据敏感度变成审批门槛还有一层更细的机制内核级的 eBPF 污点追踪taint tracking。它的作用是区分请求的干净程度——一个请求如果从头到尾没接触过你的个人数据那它的风险低一个请求如果读过了你的邮件、碰过了你的账户信息那它的敏感度高审批门槛就应该更严。这个思路解决的是一个很实际的问题如果所有操作都弹窗让你确认你会烦到把 Agent 关掉如果所有操作都自动放行迟早出事。按数据接触面来分级是在可用性和安全性之间找一个动态平衡点。同类的细节还有几个浏览器子 Agent 看到的是可访问性树accessibility tree不是原始 DOM而且不能执行 JavaScript。这一刀砍掉了大量基于脚本的注入路径——网页里藏一段 JS对它是无效的。邮件连接器默认过滤一次性验证码和密码重置链接。这个设计很聪明它精准掐断了Agent 读取邮件 → 拿到验证码 → 完成身份验证这条攻击链。完整审计轨迹你随时能看到 Agent 做过什么、以及它计划做什么。六、钱的问题Agent 怎么付款Agent 一旦能花钱风险就上了另一个量级。Muse 的方案是接 Stripe 的Link为 Agent 生成单次使用的支付卡真实卡号全程不暴露。Meta 声称 Muse 是第一个受 Link 购买保护的 AI Agent保护范围包括商品损坏或丢失、符合条件的降价、免手续费退货和退货保障。后续还计划支持 Shop Pay以及通过 1Password 复用你已有的登录态。七、这五条设计原则你自建 Agent 时可以直接抄Muse 是消费级产品你未必会用它。但它的架构原则放在任何自建 Agent 上都成立原则一把执行和授权拆成两个组件。不要让同一个 Agent 既决定做什么、又决定能不能做。哪怕你的实现只是两个独立的函数调用这个边界也要划出来。原则二密钥不进 Agent 上下文。如果你现在的做法是把 API key 写进 prompt 或环境变量让 Agent 直接读那你的架构和把密码写在便利贴上没有本质区别。正确做法是让 Agent 拿占位符真实凭证由外层代理在出网时注入。原则三审批要全量不能抽样。安全机制一旦偶尔生效就等于没有——攻击者只需要找到不生效的那条路径。原则四按数据接触面分级授权。读操作和写操作分开、干净请求和脏请求分开。所有操作一律弹窗确认的 Agent 会被用户关掉一律放行的 Agent 会出事。原则五留审计轨迹。Agent 必须能回答我做了什么、我要做什么。这不是合规需求而是你在出事时唯一能复盘的东西。八、定价与可用性项目内容免费额度每周最高 1 亿 token超额订阅制入口iOS / Android / Web / WhatsApp美国先行后续集成进 Meta 智能眼镜隐私选项可关闭交互数据用于模型训练对话详情不与广告系统共享规划中Muse Confidential VM整个 VM 加密密钥仅用户持有最后那条值得单独说Muse Confidential VM 意味着连 Meta 自己都读不到你的数据。这是从我们承诺不看到我们看不了的转变——在安全设计上这两种承诺的可信度完全不在一个量级。我的判断Muse 这次发布功能层面没什么意外架构层面是一次真正的升级。它把 Agent 安全从伦理讨论拽回了工程实现Secure VM 划边界、Sentinel 收放行权、凭证代理化让攻击失去目标、eBPF 污点追踪做动态分级。这套设计的核心思想只有一个词解耦。把执行和授权解耦、把 Agent 和密钥解耦、把想做什么和能不能做解耦。而这三件事恰好是绝大多数自建 Agent 都没做的——我们习惯给 Agent 一个万能 API key然后祈祷它别出错。对技术人的实际启发是别再问我的 Agent 会不会被提示注入攻破要问如果它被攻破了攻击者能拿到什么。如果答案是一个没有实际权限的占位符那你的架构就是对的。Muse 最大的价值不是它替用户干了多少活而是它证明了一个能干脏活的 Agent也可以是一个拿不到钥匙的 Agent——这两件事从来不矛盾只是大多数人没去做那个解耦。