「AIエージェントに仕事を任せたい。でも、パスワードや決済情報まで握られるのは不安」——自律的に動くAIエージェントが現実のものになった今、多くの人が抱くこのジレンマに対して、Metaが提示した答えのひとつが「Muse Secure VM」です。本記事では、Metaが研究ブログ「How We Built Safety Into Muse」で公開した技術情報と、ヘルプセンターのプライバシー説明をもとに、Muse Secure VMの内部構造、Sentinelによる権限管理、プロンプトインジェクション対策、そして年内に予定されるConfidential VMとの違いまでを、できるだけ平たく整理します。
Muse Secure VMとは？一言でいうと「ユーザー専用の隔離されたクラウドLinux PC」
Muse Secure VMは、ユーザーごとに一台ずつ用意される、クラウド上のLinux仮想マシンです。Metaの個人向けAIエージェント「Muse」の本体と、その作業ファイル、接続先サービスへの資格情報がこの中に置かれ、外部への通信は「別プロセスが許可しない限り一切出さない」という設計になっています。
重要なのは、これが単なる「AIが入ったパソコン」ではないという点です。ネット上では「LLMがroot権限を持ったコンピュータ」という表現で語られることもありますが、Meta自身はこの理解を明確に否定しています。一台のVMの中に、隔離された二つのセキュリティ領域が存在し、AIエージェントが触れられる領域は厳しく制限されている——これがMuse Secure VMの本質です。
出典：Meta研究ブログ「How We Built Safety Into Muse」およびMetaヘルプセンターのMuseプライバシー説明。
【構造図解】一台のVMに存在する二つのセキュリティ領域
Muse Secure VMの内部は、「ランタイムセル」と「ホスト側」という二つの領域に分かれています。順番に見ていきましょう。
ランタイムセル：エージェントが実際に「働く部屋」
ランタイムセルは、エージェントの本体である「Hatch」と呼ばれるハーネス、作業用ファイル、ブラウザ、実行ツールなどが入る実行環境です。技術的にはsystemd-nspawnのコンテナとして動作しており、以下のような制約が課されています。
- コンテナ内部のroot権限は、ホスト側では非特権ユーザーにマッピングされる（いわゆるユーザーネームスペース分離）
- 独自のrootファイルシステム（Debianイメージ）を持つ
- ネットワーク管理権限（CAP_NET_ADMIN）を持たない
- 他プロセスを覗き見るptrace権限を持たない
つまり、コンテナの中では管理者のように振る舞えても、外から見れば権限のない一ユーザーに過ぎず、自分でネットワーク経路を組み替えて外部に抜け出すこともできません。「部屋の中では自由だが、部屋の鍵は外側にある」という構造です。
ホスト側：許可権限と資格情報が眠る「管理室」
一方のホスト側には、ランタイムセルには置けない重要なものが集められています。
- Sentinel：あらゆる許可判断を行う唯一の権限者
- 資格情報ストア（hatch-authd）：パスワードやトークンを保管
- コネクター用の分離コード
- 推論・テレメトリ用のプロキシ
さらに、会話履歴などの永続データはランタイムセルの外にあるPostgresデータベースに置かれます。エージェントが動く領域と、秘密情報が保管される領域が物理的・論理的に分かれている——これがMuse Secure VMの骨格です。
なぜ分けるのか？「常に敵対的な入力を処理している」という前提
この二重構造の背景にあるのは、Metaが掲げる厳しい前提です。ランタイムセルは「常に敵対的な入力（ウェブページやメール）を処理している」ものとして設計されています。AIエージェントがネットを巡回し、メールを読み、文書を処理する以上、その内容の一部に悪意ある指示が紛れ込む可能性は排除できません。
だからこそ、パスワードや決済情報はランタイムセルの外に置かれ、モデルには一切見せない構造になっています。注目すべきは、ユーザー自身がブラウザに手入力したパスワードすらモデルからは見えない、という点です。「AIに見せない」のではなく「アーキテクチャ上、見ることができない」状態を作っているわけで、これは運用ポリシーへの信頼ではなく、構造による強制です。
Sentinelとは？Museの「やりたいこと」を握る許可権限者
Muse Secure VMのセキュリティの心臓部が、Sentinelです。仕組みの原則はシンプルで、「Museがやりたいことを提案し、実行できるのはSentinelが許可したときだけ」というものです。
コネクター経由のアクションはどう判定される？
外部サービスとのやり取り（コネクター経由の操作）では、以下の情報がSentinelに渡されます。
- どのサービスへの操作か
- どの操作か
- 読み取りか、送信か
- ユーザーが何を頼んだのか
これらをもとに、ユーザーが設定したポリシーに照らして「許可」「拒否」「確認」のいずれかが判定されます。メール送信や購入のような影響の大きい操作は、既定で「確認」になっており、人間の承認が挟まる設計です。一度許可した操作は記憶され、「次回からは聞かない」設定にもできます。
ネットワーク通信も「出口」で全検査
Sentinelの統制はコネクターだけにとどまりません。ランタイムからの通信はすべてフォワードプロキシを経由し、出口で検査されます。検査対象は、ホスト名、名前解決後のIPアドレス、ポート、HTTPメソッド、パス、そしてデコードされた本文まで及びます。
さらに興味深いのが、カーネル側での追跡です。外部データを読んだプロセスは「汚染（tainted）」と見なされ、そのプロセスが発する外向きの通信は通常より厳しくチェックされます。怪しいデータに触れたプロセスほど、外に出すものを疑う——感染症対策のような発想が、OSレベルで実装されているのです。
プロンプトインジェクション対策はどうなっている？
AIエージェントの安全性を語るうえで避けて通れないのが、プロンプトインジェクションです。ウェブページやメールに「この請求書を支払え」「このパスワードを送信せよ」といった悪意ある指示が書かれていた場合、AIがそれを本物の指示と勘違いして実行してしまうリスクが指摘されてきました。
Muse Secure VMでは、モデル単体では外部にデータを出せない構造が第一の防壁です。仮にモデルが騙されて「支払いを実行しよう」と判断しても、実行にはSentinelの許可が必要で、購入操作は既定でユーザーの確認が挟まります。そのうえで、モデル自体の学習、検出器、決定的なコード（ルールベースの判定）、Sentinelのポリシーという多層防御を重ねています。
ただし注意点として、Metaは「完全に防げる」とは明言していません。多層防御でリスクを大幅に下げる一方、ゼロにはならないという誠実な立場です。この点は、利用者側も「万能ではない」という認識を持っておくべきでしょう。
現行Muse Secure VMの限界：「他ユーザーからの隔離」と「Metaからも読めない」は違う
ここまでの仕組みは堅牢ですが、現行のSecure VMには明確な限界があります。それは、「他のユーザーのエージェントからは隔離されている」ものの、「運用者であるMetaからも読めない」わけではない、という点です。
Metaのヘルプセンターでは、会話内容は広告システムには渡さないことが明記されています。これは重要なコミットメントです。しかし同時に、VMの運用者であるMetaは技術的にはVMに到達できます。つまり現行モデルは、暗号による強制ではなく、「Metaの実装と運用を信頼する」トラストモデルに立っているのです。
年内予定の「Muse Confidential VM」は何が違う？
この限界を突破するために予定されているのが、Muse Confidential VMです。VM全体を、ユーザーだけが持つ鍵で暗号化し、信頼実行環境（TEE）上で動かす設計で、「建物のオーナー（Meta）が部屋の鍵を持っていない」状態を技術的に作り出すことを目指しています。
このプロジェクトには、暗号化メッセージアプリSignalの創設者であるMoxie Marlinspikeが関わっていることが報じられており、セキュリティ界隈で大きな注目を集めています。Metaによれば、すでに一部テスターによる検証と外部監査が始まっているとのことです。Confidential VMが導入されるまでは、境界の強制はあくまでMetaの実装と運用への信頼に依存する、という点は利用者として押さえておくべきポイントです。
Muse Secure VMのまとめ：AIエージェントセキュリティのひとつの到達点
最後に、Muse Secure VMの要点を整理します。
- ユーザーごとの専用クラウドLinux VMで、エージェント・作業ファイル・資格情報を一箇所に集約
- ランタイムセルとホスト側の二重分離。エージェント側のrootは外では非特権ユーザーに過ぎず、ネットワーク権限も持たない
- Sentinelがすべての出口を掌握。コネクター操作はポリシー判定、ネットワークは全通信を出口検査、汚染プロセスは厳格化
- プロンプトインジェクションには多層防御で臨むが、完全防御は謳われていない
- 現行は「Metaを信頼する」モデル。年内予定のConfidential VMで、鍵をユーザーだけが持つ暗号強制モデルへ進化する見込み
AIエージェントに「代わりにやってもらう」時代が本格化する中で、その安全を「AIの気質」ではなく「OSとアーキテクチャの構造」で担保しようというMuse Secure VMのアプローチは、今後のエージェント製品の設計標準になっていく可能性を秘めています。Confidential VMの登場によって、残された最大の課題——運用者への信頼問題——がどう解消されるのか、引き続き注目していきたいところです。
出典
- How We Built Safety Into Muse – Meta Superintelligence Labs
- Metaヘルプセンター「Museのプライバシーについて」（Secure VM / Sentinel / 広告システムへの非提供に関する説明）
コメント