個人情報を扱う常駐型AIエージェント「Muse」のセキュリティの仕組み

個人情報を扱う常駐型AIエージェント「Muse」のセキュリティの仕組みについてまとめました。

1. はじめに

2026年9月8日、Metaは常駐型AIエージェント「Muse」のセキュリティ設計について、技術記事「How We Built Safety Into Muse」を公開しました。

Museは、ユーザーの好みや個人情報を記憶し、メールの確認、予定の管理、買い物、Web操作などを自律的に実行するAIエージェントです。
こうした機能は便利ですが、住所・パスワード・メール・決済情報などをAIに預けても安全なのかという問題があります。

Metaは、この問題に対して、ユーザー専用のクラウドVM、認証情報の分離、権限管理、プロンプトインジェクション対策を組み合わせた仕組みを採用しています。

今回は、この技術記事をもとに、Museのセキュリティの仕組みを紹介します。

2. Muse Secure VM

2-1. Muse Secure VM - ユーザー専用の実行環境

Museでは、ユーザーごとに専用のLinux仮想マシン「Muse Secure VM」が用意されます。
このVMには、ブラウザやストレージなどが備わっており、AIエージェントがプログラムの実行、ファイル操作、サブエージェントの起動などを行えます。

主な特徴は次のとおりです。

VM内部は、大きく2つの領域に分かれています。

AIがプログラムやツールを実行する「AI実行領域」と、データや認証情報を管理する「保護領域」を分離しています。
これにより、AIが誤動作したり、外部から攻撃されたりしても、重要な情報へのアクセスを制限し、被害を抑える設計になっています。

2-2. PostgreSQL - 個人情報とメモリの保存

Museでは、ユーザーに関する情報やエージェントの状態を、専用VM内に保持します。メモリなどの永続的なアプリケーションデータは、AI実行領域から分離された「PostgreSQL」で管理されます。また、ユーザーのファイルやMuseが生成したファイルも専用VM内に保存されます。

ユーザーは保存されたメモリを確認・編集・ダウンロードできます。
たとえば、住所や食べ物の好みを記憶しておけば、Webフォームの入力やレストラン探しに活用できます。

ただし、メモリの内部形式や、ベクトル検索・RAGを利用しているかなどの詳細は公開されていません。

2-3. hatch-authd - パスワードとAPIキーの保護

Museでは、パスワードやOAuthトークンなどを、AIから隔離された認証情報ストアで管理します。
この役割を担うのが「hatch-authd」です。

たとえば、MuseがGmailにアクセスする場合、次の流れになります。

AIには本物の認証トークンではなく、代理トークンが渡されます。実際の通信時に、Sentinelが必要な認証情報に置き換えます。
これにより、AIがパスワードやAPIキーを直接読み取るリスクを抑えています。

また、メールに含まれるワンタイムパスコードやパスワード再設定リンクなども、フィルターや分類モデルによって除外されます。

2-4. privsep - 権限分離

「privsep」（Privilege Separation）は、外部サービスを操作するプログラムを、AIの実行環境から隔離する仕組みです。
MuseがGmailやGoogle Calendarを操作する際、AIは操作を要求するだけで、実際の処理は権限を制限された専用ワーカーが実行します。

たとえば、カレンダーを操作するワーカーには、メール用の認証情報へのアクセスを許可しません。
これにより、AIが悪意ある指示に従った場合でも、ワーカーに与えられていない認証情報へのアクセスを防ぐ設計になっています。

2-5. Sentinel - 操作と通信の権限管理

「Sentinel」は、Museによる外部サービスの操作やネットワーク通信を制御するコンポーネントです。
privsepが「どの権限で処理を実行できるか」を制限するのに対し、Sentinelは「その操作を許可してよいか」を判断します。

判断は次の3種類です。

承認が必要な場合は、AIとの会話とは独立した画面を表示します。これは「Human in the Loop」（人間による確認・承認）と呼ばれる仕組みで、購入などの重要な操作をユーザーが承認します。独立した画面を使うことで、悪意ある指示による承認の偽装を防ぎます。

承認は、1回限り、タスク単位、期限付き、継続的な許可など、範囲を指定できます。また、外部通信では、接続先のドメインやIPアドレス、HTTPメソッド、URLなどを検査します。

さらに、Linuxの「eBPF」を使って、ユーザーデータにアクセスしたプロセスを追跡します。ユーザーデータにアクセスしたプロセスは、自動的な通信許可の対象から外され、必要に応じてユーザーの承認を求められます。

これにより、個人情報にアクセスしたプログラムが、無条件に外部へ情報を送信するリスクを抑えています。

3. Computer Useと買い物の安全対策

3-1. Computer Useの安全対策

MuseはChromiumベースのブラウザを利用して、Webサイトの操作を実行できます。ブラウザ操作には専用のサブエージェントが使われますが、AIからはChrome DevToolsを直接利用できず、操作できる機能も制限されています。

主な制限は次のとおりです。

パスワードは専用UIから保護領域へ保存され、必要なときだけブラウザに入力されます。

3-2. 買い物の安全対策

Museでは、買い物の決済にも特別な仕組みを用意しています。
既存の決済情報を使う場合でも、購入するたびにユーザーの承認が必要です。

初めて利用するショップで決済する場合には、Museのウォレット機能と「Stripe Link」の連携により、使い捨てカード番号が発行されます。このカード番号には、利用先の店舗、金額、有効期間の制限が設定されます。
そのため、決済情報が何らかの理由で漏洩した場合でも、通常のクレジットカード番号が漏れる場合より被害を限定できます。

4. プロンプトインジェクション対策

常駐型AIエージェントの大きな脅威が「プロンプトインジェクション」です。
これは、メールやWebページなどに悪意ある指示を埋め込み、それを読んだAIエージェントに、本来許可されていない操作を実行させる攻撃です。

Museでは、複数の防御策を組み合わせています。

特に重要なのは、AIモデルが攻撃を見抜けなかった場合でも、別の仕組みで操作を止められることです。
ただし、Meta自身もプロンプトインジェクションは未解決の問題であり、Museが完全に安全というわけではないと説明しています。

5. Metaは個人情報を閲覧できるのか

現行のMuse Secure VMは、ユーザー間のデータを隔離し、Meta従業員からのアクセスを運用ポリシーで制限しています。
しかし、現行のMuse Secure VMは、Metaによるユーザーデータへのアクセスを技術的に完全に防止する設計ではありません。Metaは、サービスの運用、サポート、セキュリティ確保などに必要な場合、データにアクセスできると説明しています。

この問題に対応するため、Metaは「Muse Confidential VM」も開発しています。これは、暗号技術によってMeta自身もVM内の情報へアクセスできないことを検証可能にする仕組みです。

2026年9月の発表時点では限定的なテスト段階で、年内の提供が予定されていました。ただし、2026年11月現在、一般提供の開始は確認されていません。

6. AIの学習へのデータ利用

Museでは、会話内容やツール実行履歴、サブエージェント間の処理履歴などが、AIモデルの学習に利用される場合があります。
Metaは、学習に利用する前に、これらのデータから主要な個人識別情報を除去する処理を行うと説明しています。
ただし、初期設定では学習への利用が有効になっており、利用を希望しない場合はMuseの設定からオプトアウトする必要があります。

Museは個人情報やメール、カレンダーなどを扱うため、プライバシーを重視する場合は、学習へのデータ利用を無効にしておくことをおすすめします。

また、Metaによると、Museの会話やVM内のデータをMetaの広告システムへ直接共有することはありません。ただし、Museが外部サイトを訪問した結果、そのサイトの広告配信に間接的な影響を与える可能性はあります。

7. まとめ

Museのセキュリティ設計で特徴的なのは、AIモデルの判断だけに安全性を依存させず、実行環境・認証情報・外部通信・承認処理を分離していることです。

特に、次の仕組みが重要です。

従来のチャットAIとは異なり、常駐型AIエージェントには、個人情報を長期間保存し、外部サービスを操作する能力があります。

そのため、今後はモデルの性能だけでなく、「AIに何を見せるか」「何を実行させるか」「誰が保存情報にアクセスできるか」というセキュリティ設計が、AIエージェントを選ぶ重要な基準になりそうです。

関連