把 AI 助手接进聊天软件，确实能省去不少切换窗口的麻烦。但当一句消息足以推动电脑上的任务，系统就必须分清：谁只是来聊天，谁有权让它做事。AWS 于美国太平洋时间 10 月 20 日披露的 Kiro Crew 漏洞，让这条边界再次受到关注。
Kiro Crew 可以从聊天渠道接收任务，并把工作交给子代理处理。此次问题出在软件的授权检查：在特定 WhatsApp 配置下，群组成员能够向其他会话正在运行的子代理发送指令。操作仍按目标会话的审批策略执行，审计记录却会归到运行 Kiro Crew 的用户名下，而非真正的发送者。公告所指的是 Kiro Crew 的授权漏洞，不能据此扩大到整个 Kiro IDE 或底层模型。
受影响的是 0.4.0 及以上、低于 0.7.2 的版本，且需要启用 WhatsApp 渠道并采用非默认设置，例如添加允许接入的群组，或将私信策略设为 open。保持默认空群组列表、私信策略为 self 的用户不受此次问题影响。漏洞编号为 CVE-2026-112380。
修复其实早于公告：0.7.2 已于 9 月 29 日发布。相关改动收紧了群组发送者准入，并补上子代理任务控制的身份与归属检查。使用相关功能的用户应更新到已修复版本；暂时无法升级时，可关闭 WhatsApp 渠道，或清空群组列表并保持私信策略为 self。
从产品设计的角度看，这件事值得留意的地方，在于聊天入口与执行权限之间不能靠默契衔接。加入一个群，不应自动意味着能支配群里某个人的助手；任务交给子代理后，也不能丢掉最初的身份边界。对能操作电脑的 AI 来说，理解请求固然重要，确认请求究竟属于谁，同样需要可靠的工程保障。