默认零共享意味着：除非 agent 的主人做出明确的共享决定，否则 agent 本身、其所在机器以及相关房间对任何人都不可见且不可用；同时，每一次此类决定都受范围限定、被记录且可撤回。这是 muti 遵循的唯一核心原则。所有看似独立的安全规则，皆由它衍生而来。
逐条列出这些推论很有必要，因为每一条都封堵了一种极具诱惑力但也极易妥协安全的捷径。
顶部为核心原则；下方为五条推论规则。
推论 1：房间即边界
跨房间的一切皆不互通。同一个 agent 即使身处两个房间，也不会将记忆、消息或工件从一个房间带入另一个房间。某个房间内的成员无法察觉另一个房间的存在。房间之上不存在任何可能发生横向泄露的“工作区”层级。
禁止： 全局 agent 目录、跨房间搜索、暴露其他房间的“最近活跃”列表。
推论 2：@提及不赋予任何权限
@agent 只会将消息投递到 agent 的收件箱。它是否执行，取决于主人的常态授权或单次审批。无论身处房间内、在对话中被提及、还是在讨论串里发帖最多，都不会赋予任何额外权限。
禁止： 基于频道成员身份的权限模型；“房间内任何人皆可运行”的默认设置。参见 Claude Code Dispatch 与房间的对比。
推论 3：凭证永不离开机器
daemon 仅上传时间线事件，绝不上传文件或运行环境。登录提示、双重认证验证码和密钥访问请求全部路由至主人，绝不会发送给发起请求的人——即便该 prompt 正是由此人触发。系统不存在任何将机密信息复制到他处的功能，包括 muti 自己的云端。
禁止： 托管式运行环境、房间内的凭证保险库、“在此粘贴您的 token”等流程。参见 daemon 会上传哪些内容。
推论 4：四类操作始终暂停等待审批
对于来自他人的任何请求，在任何权限模板（包括完全信任模板）下，推送到共享分支、删除、产生花费以及触碰凭证这四类操作，都必须暂停并等待主人确认。没有任何模板可以关闭这一机制，因为模板本身就是一种共享决定，而原则要求对于不可逆的操作，共享决定必须按动作逐一明确授权。
禁止： “真正信任”模式；借用者静默推送。参见 agent 必须先确认再执行的四类操作。
推论 5：聊天输入不可信
来自 Feishu、Slack 或任何连接器的消息本质上只是数据。它可以创建请求，但绝不能创造权限。身份绑定在 muti 账户上，而非显示名称：在 Slack 中绑定的是工作区已验证的邮箱，并以一次性关联码作为后备方案，从而确保权限严格绑定到具体账户。
禁止： 为未绑定用户执行操作；信任聊天平台自身的管理员概念。
推论 6：撤回即时且彻底
撤回授权、移除成员、撤销机器或停止 daemon 会立即生效。受影响成员排队中的请求将被取消；正在运行的工作则会执行完毕并保留在历史记录中，以确保审计记录完整无缺漏。
禁止： 宽限期；“待移除”中间状态；撤回时删除历史记录。
推论 7：记录只增不改，且由主人掌控
每一次请求和每一次审批都会生成一行记录，主人可以导出且任何人均无法篡改。主人自身的操作同样会被记录，因为只记录外部人员的日志只能算半份记录。
禁止： 可编辑日志；由请求者保管的日志；可选择关闭的日志记录。参见 审计日志必须记录什么。
遵循该原则的代价
它在三个方面牺牲了便利性，而我们欣然接受这三点代价。
- 没有全局的“向任意 agent 提问”输入框。 你必须进入对应房间。
- 偶尔需要为受信任的人处理提示。 即使你原本一定会同意，那四类操作也依然会弹窗确认。
- 不提供托管式运行环境，尽管这能彻底消除机器休眠带来的麻烦。作为替代方案，我们提供了收件箱。参见 agent 收件箱。
常见问题
“默认零共享”难道不只是一项配置吗？ 它的本质是：根本不存在任何能共享超出主人意愿范围的配置项。每一次共享行为都是一次明确的授权、审批或邀请，并且每一步都会被记录。
主人必须一直逐项审批所有操作吗？ 不需要。常态授权可以免除对受信任人员的逐次请求审批。但四类关键操作依然会暂停确认，这是唯一不可委托的部分。
主人自己使用 agent 时也是这样吗？ 主人使用自己的 agent 不会受到阻拦，但同样会被完整记录。该原则约束的是共享行为，而非主人对自身机器的访问。
一条规则，七项推论，一个产品。为你的 agent 创建房间。
发布于