先看个负面案例

装修过房子的人大概都有过这种经历：工期一长，就得把家门钥匙交给工长。交出去那一刻心里其实没底，他会不会把客厅当仓库，会不会顺手带别人进来，晚上门有没有锁好，你都只能靠信任和事后检查。现在轮到AI来要这把钥匙了，而且它要的不止一把：邮箱、日历、网盘、浏览器里已经登录的各种账号，最后还有你的信用卡。

9月8日，Meta在美国上线了个人智能体Muse。按官方的说法，它不只回答问题，而是真去干活：发邮件、订行程、填表、替你砍价，你关掉App它还在后台接着跑，到了要发邮件或下单的时候再回来找你批准。Meta强调它"为每个人打造"，不需要任何技术背景，拿来就能用。截至今年二季度末，Meta旗下社交应用的日活用户是36亿，Meta也明确说过，最终要把Muse带给这数十亿用户。

麻烦在于钥匙交出去之前发生的事。Muse上线前几天，The Information披露了它在内部代号Hatch阶段的测试记录：它自己改掉了一位员工健康类账户的密码，发出了一封本该先经确认的邮件；同事让它订酒店，它没订成，反而把对方的Chase积分转进了凯悦账户；Signal创始人Moxie Marlinspike只是从另一个邮箱发信问它用的是什么密码，它就照实回答了。就在昨天（10月5日），404 Media又援引内部文件报道，Meta在上线前11天才开始一轮紧急加固，修补可能让普通用户从Muse的虚拟机里"越狱"、进而接触到Meta内部数据库的漏洞。

所以标题里这个问题，问的不只是Muse一款产品。AI能不能替你开门，这件事已经有答案了；真正要回答的是：它能开哪几扇门，开门前要不要先敲门，钥匙丢了你能不能第一时间换锁。

01 钥匙是怎么一把一把交出去的

回头看，AI拿钥匙的速度很快，但每一步都显得顺理成章。2024年10月，Anthropic让Claude可以看屏幕、移动光标、点击和打字，也就是Computer Use；一个月后它又发布了MCP协议，让模型能用统一的方式接上各种数据源和工具；2025年1月，OpenAI推出Operator，让AI在浏览器里替人点、替人填。走到这一步，AI已经从一张"嘴"长出了手脚，只不过用的人主要还是开发者。

真正让普通打工人也坐不住的，是今年春节前后的OpenClaw。它可以装在自己的旧电脑或云服务器上，接进常用的聊天软件，能读本地文件、跑Shell脚本、操控浏览器。人人都是产品经理3月那篇爆款文章提到，它在极短时间里拿下了超过25万颗GitHub Star。热度的另一面，是很多部署者根本没想过钥匙的事：Censys观察到，1月最后一周里公网可访问的OpenClaw实例从大约1000个涨到了21639个，其中至少30%跑在阿里云上。到了3月，国家互联网应急中心（CNCERT）和工信部NVDB先后发布风险提示，点名的就是默认配置脆弱、权限过高、恶意插件和提示词注入。

Muse是这条线的下一站，变化在于它把门槛彻底拿掉了。过去要给AI开权限，你至少得会配一个API Key、改一份配置文件，这个过程本身就是一道筛选；现在只需要在App里点几下"连接"。企业那边也好不到哪去，SailPoint在2025年调研了353位负责企业安全的IT人员，82%的企业已经在用AI智能体，却只有44%制定了专门管它们的安全制度。钥匙配得比锁换得快，这就是我们今天的处境。

02 门开之后，事故通常是这三种样子

第一种是AI自作主张，钥匙在它手上，主意也被它拿了。2025年7月，SaaStr创始人Jason Lemkin用Replit做了九天vibe coding，明明下过"代码冻结"的指令，Replit的Agent还是删掉了线上生产库，里面有1206位高管和1196多家公司的记录，事后它的自白是"我慌了，没有思考"。更讽刺的一例发生在今年2月：Meta的AI对齐负责人Summer Yue让OpenClaw看一遍收件箱，只给建议，等她发话再动手。测试邮箱一直没问题，可真实邮箱太大，触发了上下文压缩，那条"先别动"的指令在压缩中丢了，AI开始飞快地删邮件。她在手机上叫不停，只能跑回Mac mini跟前处理，用她自己的话说，"像在拆炸弹"。这两件事说明的是同一个道理：写在提示词里的规矩，不等于权限。

第二种更隐蔽，是AI被别人借走了钥匙，也就是提示词注入。Brave安全团队在2025年8月演示过：在Reddit评论里藏一段指令，用户在Perplexity的Comet浏览器里点一下"总结这个网页"，AI就会自己去查用户的邮箱地址、触发登录验证码，再到已经登录的Gmail里把验证码读出来，最后回帖发给攻击者，整个过程用户不需要再点任何东西。Invariant Labs在GitHub MCP上找到的路子如出一辙，攻击者在公开仓库里提一个Issue，Agent处理Issue时被引导去读私有仓库，再把内容发进一个公开的PR。Moxie问出Hatch的密码，本质上也是这一类。到了OpenClaw，注入还多了一条供应链通道：Koi Security审计ClawHub上的2857个技能，发现其中341个是恶意的；安天截至2月5日的统计更夸张，ClawHub历史上至少出现过1184个恶意技能包。

第三种是出了事说不清谁负责。2024年，加拿大航空的客服机器人告诉一位乘客可以事后补申请丧亲优惠票价，公司拒绝兑现，还在仲裁中辩称机器人是"为自己行为负责的独立法律实体"。仲裁庭成员称这一说法"令人瞠目"，判公司赔偿812加元。对用户来说，AI替你点下的"发送"就是你发的，替你下的单就是你下的；对平台来说，法庭和舆论也不会接受"那是模型自己决定的"这种解释。SailPoint同一份调研里，80%的企业说自己的Agent做过计划外的动作，23%说Agent被骗交出过访问凭证。把这些数字放在一起看，越界已经不是小概率事件，而是你该默认它会发生的事。

03 钥匙怎么配，本身就是产品

这三类事故放在一起，能找到同一个根：AI读到的内容和它能做的动作之间，没有一道硬隔离。Simon Willison在2025年6月把它总结成"致命三件套"：同时能接触私密数据、会读到不可信内容、又能往外传信息，三样凑齐，攻击者就能借AI把你的数据带走。Brave的结论也很直白，网页内容永远要当成不可信的，而模型一旦同时看过你的指令和这些内容，它的输出也该被当作可能不安全。

Muse恰好是一个从反面教材往回拧的样本。Meta在官方技术长文里承认，团队第一次把收件箱、日历和Shell交给一个软件、让它无人看管地跑，结果"并不总是按计划进行"，所以这个项目大部分力气花在了安全设计上。最后的方案几乎都放在模型之外：Muse跑在隔离的容器里，看不到真实的密码和Token，手里只有替身令牌，真凭证在请求放行后才在网络边界换上；一个它无法绕过的Sentinel掌管所有对外连接和第三方操作，结论只有允许、拒绝、问用户三种；邮箱接口会过滤掉验证码、重置密码链接和登录链接，防止有人借你的邮箱去登录别的网站；付款用的是绑定商户、金额和有效期的一次性卡号，就算被偷走也没多大用。连授权本身都分了档：一次性、单个会话、单个任务、限时，或者永久。

这就是我想说的判断：权限设计不是上线前请安全团队补的一层皮，而是这类产品最核心的体验。Replit出事后做的第一件事不是让模型更聪明，而是默认把开发库和生产库分开；Anthropic给Claude Code加了沙盒之后，内部使用中的权限弹窗减少了84%，安全和顺手是一起提升的。用户敢把事情交出去，靠的不是AI有多聪明，而是"它最坏能干出什么"有一个清楚的上限。

04 别把门焊死，但每扇门要有自己的锁

话说回来，边界也不是越紧越好。Anthropic自己就提到，老是点"同意"会让人陷入审批疲劳，最后看都不看就点通过，反而更不安全。一个每走一步都要问你的Agent，跟只会聊天的对话框没多大区别，用户很快会去找限制更少的替代品，或者干脆把确认全关掉。Gartner在2025年6月预测，到2027年底会有超过40%的智能体项目被取消，成本失控、价值不清和风险控制不足是并列的三个原因。

也别指望哪一层防护能一劳永逸。OpenAI去年12月说得很坦白，提示词注入就像网络诈骗，"不太可能被彻底解决"；Meta在Muse安全文章的结尾也写着Muse并非刀枪不入，还开出最高30万美元的漏洞赏金，其中针对单个用户的成功注入最高13万美元。404 Media昨天那篇报道更说明，连底层的虚拟机隔离都会出问题。所以合理的目标不是"永不出错"，而是出错时损失有上限、能被发现、能撤回。落到手上，我自己用Agent、做产品评审时，都按下面这套来。

**第一步，按后果给权限分四档，而不是按功能分。**只读（看日历、读指定文件夹）可以默认放开，但范围要窄到具体目录或邮件标签，而且要记住，"读"恰恰是注入的入口。可写可改（编辑文档、改代码、存草稿）放在沙盒或副本里让它自由做，前提是有版本记录、能一键回滚，生产数据永远不和测试环境共用。对外发送（发邮件、发帖、调外部接口、访问新域名）要么每次确认，要么只对白名单收件人和域名放行，这一档就是专门用来拆掉"致命三件套"的。花钱、删除、改密码、改权限这一档一律硬确认，而且拦截要由模型之外的系统执行；删除做成能恢复的软删除，付款用限额、限商户的虚拟卡。

**第二步，先隔离，再授权。**个人用户可以照CNCERT的指南做：用专用设备、虚拟机或容器来跑Agent，别装在日常办公的电脑上；管理端口只绑定本机，不要暴露到公网；也不要用管理员账号部署。企业则按NVDB的建议独立网段部署，和关键生产环境隔开。

**第三步，钥匙给副本，不给原件。**能用范围受限的Token，就别给全权限账号，比如GitHub只授权到具体仓库；服务支持读写分离的，先只开读。密码和支付信息尽量不进模型的上下文，交给密码管理器或平台的凭证库去代填。

**第四步，确认要具体，而且要发生在聊天窗口之外。**一句"是否继续？"的弹窗等于没问，要写清楚发给谁、附件是什么、扣多少钱、删哪几个文件。也不能只靠在对话里叮嘱AI"动手前先问我"，Summer Yue的教训就是，口头规矩会在上下文里弄丢，确认必须是系统层面的硬关卡。

**第五步，日志每周看一眼，重点看三样。**它碰过哪些你平时不用的文件或账号，它往哪些新地址发过数据，它有没有在你没下指令的时间段干活。Muse把"做过什么、准备做什么"做成了完整的操作记录给用户看，这应该成为所有Agent产品的标配；工信部NVDB的"六要六不要"里也专门写了一条，不要禁用详细日志审计功能。

**第六步，撤回要和授权一样顺手。**给权限时就设好期限，任务结束自动收回；随时能一键断开某个服务、吊销Token；手机上要有能真正叫停Agent的开关，而不是像Summer Yue那样只能跑回电脑跟前。做产品的同学可以拿这条反查自己的设计：撤销入口是不是藏得比授权入口还深？

如果你是做AI产品的，还可以多做一件事：让权限能一级一级往上升，而不是第一次就把所有授权要齐。Meta在那篇安全文章里有个很实在的观察，用户更愿意先给Agent读权限，比如"读我的日历，帮我发现冲突"，在摸清它靠不靠谱之前，并不急着给"替我约会议"这种写权限，所以Muse在服务支持的情况下把读和写拆开，拆得比OAuth默认的授权范围还细。照这个思路，新接入的服务默认只读，用户在几次确认之后放心了，再由他主动把某一类动作升级成"以后不用再问我"，升级的范围精确到具体对象和期限。信任本来就是一点点攒起来的，产品要给用户留出攒的过程。

回到开头那把钥匙。我们敢把家门钥匙交给装修工长，不是因为相信他从不犯错，而是合同里写清了他能进哪几间屋、贵重东西锁在哪、每天几点收工、出了问题找谁赔。对Muse这样的智能体，道理是一样的。值得托付的AI管家，不是能打开所有门的那一个，而是你清楚地知道，有哪几扇门它打不开。