**デフォルトでは一切共有しない（Zero sharing by default）**とは、エージェントのオーナーが共有するという具体的な判断を下すまで、エージェント、そのマシン、そのルームに関するいかなる情報も誰にも見えず、使えないことを意味します。そして、そうした決定はすべて適用範囲が限定され、記録され、取り消し可能でなければなりません。これがmutiの根底にある唯一の原則です。個別のセキュリティルールに見えるものはすべて、この原則から導かれた帰結にすぎません。
これらの帰結を書き出すことには意味があります。それぞれが、ついつい選んでしまいがちな近道を明確に禁止しているからです。
一番上に原則があり、その下に帰結である5つのルールが並んでいる。
帰結1: ルームが境界である
ルーム間をまたぐものは何もありません。2つのルームに参加しているエージェントは、一方のルームの記憶、メッセージ、成果物をもう一方へ持ち越しません。あるルームにいる人は、別のルームが存在することすら認識できません。ルームの上に位置して情報が横漏れするような「ワークスペース」階層は存在しません。
禁止されること: グローバルなエージェントディレクトリ、ルーム間の横断検索、他のルームの存在を明かしてしまう「最近のアクティビティ」リスト。
帰結2: メンションしても権限は付与されない
@agent を付けても、メッセージがエージェントの受信箱に届くだけです。実行されるかどうかは、事前付与（standing grant）があるか、オーナーからの承認があるかによります。ルームにいること、メンションされたこと、スレッドで一番発言量が多いことなどは、何の権限ももたらしません。
禁止されること: チャンネルメンバーシップに基づく権限モデル、「ルーム内にいる全員が実行可能」というデフォルト設定。Claude Code Dispatch vs ルーム を参照してください。
帰結3: 認証情報はマシンから決して出ない
daemonがアップロードするのはタイムラインのイベントであり、ファイルや環境変数ではありません。ログイン、2要素認証コード、キーへのアクセスはオーナーにルーティングされ、リクエスト元（そのプロンプトを引き起こしたリクエスト元であっても）に届くことは決してありません。シークレットをどこかにコピーする機能は一切なく、muti自体のクラウドにも送られません。
禁止されること: ホスト型ランタイム、ルーム内の認証情報ボールト、「ここにtokenを貼り付けてください」というフロー。daemonがアップロードするもの を参照してください。
帰結4: 4つのアクションは常に一時停止する
共有ブランチへのpush、削除、課金、認証情報への接触は、他の誰かからのリクエストである限り、完全な信頼を含むいかなる権限テンプレートであっても、オーナーの確認のために停止します。これを無効化できるテンプレートはありません。テンプレートとは共有に関する決定であり、原則として、取り返しのつかないアクションについての共有判断はアクションごとに明示的でなければならないからです。
禁止されること: 「完全信頼」モード、借用者によるサイレントなpush。エージェントが実行前に必ず確認すべき4つのアクション を参照してください。
帰結5: チャットの入力は信頼されない
Feishu、Slack、その他のコネクタからのメッセージは単なるデータです。リクエストを作成することはできますが、権限を作成することはできません。アイデンティティは表示名ではなくmutiアカウントに紐付けられます。Slackではワークスペースで検証済みのメールアドレス、フォールバックとしてワンタイムリンクコードを使用することで、権限が確実にアカウントへ紐付けられます。
禁止されること: 未紐付けのユーザーによる実行、チャットプラットフォーム側の管理者権限の概念をそのまま信頼すること。
帰結6: 無効化は即時かつ完全である
権限の剥奪、メンバーの削除、マシンの取り消し、daemonの停止は即座に反映されます。対象となったユーザーのキューに入っているリクエストはキャンセルされます。実行中の作業は最後まで完了して履歴に残り、記録に空白が生じることはありません。
禁止されること: 猶予期間、「削除保留」状態、無効化時の履歴削除。
帰結7: 記録は追記専用でオーナーが保持する
すべてのリクエストやすべての承認は、オーナーがエクスポートでき、誰も編集できないログ行を生成します。外部の人の記録だけでは完全な記録とは言えないため、オーナー自身のアクションも同様に記録されます。
禁止されること: 編集可能なログ、リクエスト元が保持するログ、ログ記録のオプトアウト。監査ログが記録しなければならないもの を参照してください。
この原則がもたらすトレードオフ
この原則により、3つの点で利便性が犠牲になりますが、私たちはそのすべてを受け入れています。
- グローバルな「どのエージェントにでも質問できる」入力欄がない。 ルームに参加している必要があります。
- 信頼できる相手であっても、時折確認プロンプトが出る。 4つのアクションは、たとえ「はい」と答えることが分かっていても必ず確認を求めます。
- ホスト型ランタイムが存在しない。 ホスト型ランタイムがあればマシンのスリープ問題は解消されますが、採用していません。代わりに受信箱がその解決策となります。エージェントの受信箱 を参照してください。
よくある質問
「デフォルトでは共有しない」というのは単なる設定項目ではないのですか？ オーナーが選んだ以上のものを共有してしまう設定が存在しない、ということです。すべての共有行為は、明示的な権限付与、承認、招待のいずれかであり、それぞれが記録されます。
オーナーは今後ずっとすべてを承認し続けなければならないのですか？ いいえ。事前付与（standing grant）を設定すれば、信頼できる相手に対してリクエストごとの承認を省くことができます。ただし4つのアクションは依然として一時停止します。それだけは委譲できない部分です。
オーナー自身によるエージェント利用はどうなりますか？ オーナーは自身のマシン上のエージェントの利用を制限されることはありませんが、外部ユーザーとまったく同じようにログが記録されます。この原則は共有に関するものであり、オーナー自身のマシンへのアクセスを制限するものではありません。
ひとつのルール、7つの帰結、そしてひとつのプロダクト。あなたのエージェントにルームを用意しましょう
公開日