預設零共享意味著在 agent 的主人做出明確的分享決定之前，agent 本身、其所在機器或其所屬房間的任何內容，對任何人都不可見、不可用；而且每一個分享決定都有明確範圍、皆留有紀錄，且均可撤銷。這是 muti 底層唯一的準則。所有看似獨立的安全規則，都是這條準則的延伸。
把這些延伸結果列出來很有必要，因為每一條都禁止了一個原本可能極具誘惑力的捷徑。
頂部為核心原則；下方為五條規則，各自為其延伸結果。
結果 1：房間即是邊界
任何東西都不能跨越房間。身處兩個房間的 agent 不會把記憶、訊息或產物從一個房間帶到另一個房間。身在某個房間裡的人，無法看見另一個房間的存在。房間之上沒有「工作區」層級，因此不會發生橫向洩漏。
禁止： 全域 agent 目錄、跨房間搜尋，以及會暴露其他房間的「最近活動」清單。
結果 2：提及不賦予任何權限
@agent 只會把訊息送進 agent 的收件匣。它是否執行，取決於常態授權或主人的批准。身處房間中、被提及，或是討論串中發言最活躍的人，都不會因此獲得任何權限。
禁止： 頻道成員權限模型；「房間內的任何人皆可執行」的預設設定。請參閱 Claude Code Dispatch vs a room。
結果 3：憑證永不離開機器
daemon 上傳的是時間線事件，而非檔案或環境。登入、雙重驗證碼與金鑰存取只會導向主人，絕不會流向請求者——即使是觸發該 prompt 的請求者也一樣。系統中沒有任何功能會把機密複製到其他地方，包括 muti 自己的雲端。
禁止： 代管執行環境、房間內的憑證保存庫、「在此貼上您的 token」等流程。請參閱 what the daemon uploads。
結果 4：四項動作一律暫停
推送到共享分支、刪除、花費金額以及接觸憑證，只要來自其他人的請求，無論在哪種權限範本下（包含完全信任），都必須停下來等待主人確認。沒有任何範本能關閉此限制，因為範本本身就是一種分享決定，而準則規定：面對不可逆的動作，每一項分享決定都必須逐一明確授權。
禁止： 「完全信任」模式；借用者私下靜默推送。請參閱 four actions an agent should always ask before doing。
結果 5：聊天輸入不可信
來自 Feishu、Slack 或任何連接器的訊息都只是資料。它可以建立請求，但不能建立權限。身分綁定的是 muti 帳號，而不是顯示名稱：在 Slack 中是透過工作區已驗證的電子郵件綁定，並以一次性連結碼作為備援，因此權限是附加在帳號上。
禁止： 針對未綁定身分的使用者執行操作；盲目信任通訊軟體上的管理員概念。
結果 6：撤銷立即且徹底
撤銷授權、移除成員、撤銷機器或停止 daemon 都會立即生效。受影響對象排隊中的請求會被取消；正在執行的工作會完成並保留在歷史紀錄中，確保紀錄毫無缺漏。
禁止： 寬限期；「待移除」狀態；撤銷時刪除歷史紀錄。
結果 7：紀錄只增不減，且由主人掌控
每一個請求與每一次批准都會產生一行紀錄，主人可以隨時匯出，且任何人都無法編輯。主人自己的操作也會被記錄，因為只記錄外部人員的紀錄只是半套紀錄。
禁止： 可編輯的紀錄；由請求者持有的紀錄；可選擇停用的日誌記錄。請參閱 what an audit log must record。
堅持這項原則的代價
它在三個地方犧牲了便利性，而我們全盤接受這三點代價。
- 沒有全域的「詢問任何 agent」輸入框。 你必須身處房間之中。
- 對信任的人偶爾仍會跳出提示。 即使你本來就會同意，那四項動作依然會發出詢問。
- 沒有代管執行環境，即便代管能徹底解決機器休眠的問題。取而代之的解法是收件匣。請參閱 the agent inbox。
常見問題
「預設不分享任何東西」不就只是一個設定嗎？ 它的本質是：不存在任何可能分享超出主人選擇範圍的設定。每一次分享行為都必須是明確的授權、批准或邀請，且每一項都會留下紀錄。
主人必須永遠批准每一件事嗎？ 不用。常態授權可以為你信任的人免去逐次請求批准。但四項關鍵動作仍會暫停；這是唯一無法委派的部分。
主人自己使用 agent 時呢？ 主人使用自己的 agent 不會受到關卡阻擋，但紀錄方式完全一致。這條原則規範的是「分享」，而非主人存取自己機器的方式。
一條準則，七個延伸結果，成就一款產品。為你的 agent 開設房間。
發布於