パーソナルエージェントMuseがローンチ、多層防御と隔離されたVMで被害の限定を図る

パーソナルエージェントであるMuseが9月8日にローンチされました。開発チームは、Museを使い始めた時点で、真のパーソナル超知能の兆しを見たと述べています。それは、ユーザーを知っていて、実際に作業を行い、バックグラウンドで動き、サブエージェント(subagent)の群れを起動し、自分でツールを作り、自分自身を編集するエージェントです。

開発チームは2026年初頭からMuseの開発と自社での利用を続けており、受信トレイ、カレンダー、シェルをソフトウェアに渡して無人で動かしたのはこれが初めてで、計画どおりにいかないこともありました。Museをすべての人にとって機能させるには、より安全に動作させるための慎重な設計とエンジニアリングが必要であり、このプロジェクトの労力の大半はそこに注がれました。Museのモデルは、このようなエージェントに重要な領域に特に焦点を当てて訓練されています。具体的には、CLIとskillsを使ったゼロショットのtool calling、長いコンテキスト、プロンプトインジェクション(prompt injection)への本質的な認識を備えた長い軌跡での指示追従、およびマルチエージェント連携です。

パーソナルエージェントMuseの開発チームは、モデルの中核性能がどれほど高くても、この種のエージェントはそれでも誤りを犯し、読み込むデータを通じて攻撃されることもあると考えています。そのためMuseは、エージェントが攻撃を受けている可能性を前提にして被害を限定するよう設計されています。ハーネス(harness)は独立した隔離セル内で動作し、実際の認証情報を見ず、外部世界とのやり取りはすべてエージェントが上書きできないSentinelを経由します。

専用VMとコネクタの構成

パーソナルエージェントMuseは、ユーザーとそのMuseがクラウド上で共有する専用のコンピュータを介して動作します。このコンピュータは各Virtual Machine(VM)として提供され、隔離されたlinuxボックスです。各Virtual Machine(VM)はブラウザを備え、エージェントが書くコードのコンパイル、custom skillsの開発、並行するサブエージェント(sub-agent)やcronの処理など、実際の作業をこなせるだけのストレージ、CPU、メモリを備えています。MuseのクライアントであるiOSアプリ、Androidアプリ、Web UIは、secure transport layerを通じて利用者のVirtual Machine(VM)に直接接続します。

Museは、メールや車、家などの他のシステムに接続すると最も役に立ちます。Metaは、サードパーティのシステムやInstagram・Facebookなど他のMetaのアプリにつなぐ初期のconnector群を構築しました。各connectorごとに、サービス提供元と密に連携してそのAPIを統合しています。また、各connectorを最大限に活用する方法をMuseに伝える詳細な指示であるSKILLを書き、改良を重ねました。利用者が必要とする他のサービスが独自のAPIまたはCLIを持っていれば、そのためのcustom connectorをMuseが自分で書くことも可能です。

隔離されたVMとSentinelによる権限判断

Muse Secure VMは、利用者とそのMuseが行うことと、利用者の安全を守るためにMetaが組み込んだものすべてを、Linux isolation primitivesを使って分離するよう慎重に構成されています。適切なメンタルモデルは、1台のマシン上にある2つの隔離されたセキュリティドメインであり、rootを持つLLM駆動のエージェントではありません。Hatchはコードベース内でのMuseの社内名です。中核となるagenticハーネスであるHatch daemonと、利用者のワークスペースとファイルを含むファイルシステム、およびMuseが利用者の代わりに実行するすべてのバイナリとツールは、`systemd-nspawn`のruntime containerの中で動作します。

runtime cellの中のrootは、権限のないホストユーザーにマップされるため、runtime cellのrootはホストのrootではありません。runtime cellは、より機微なデータがあるホストのファイルシステムとは別に、full debian imageを含む独自のroot filesystemを持ちます。また、仮想ネットワークインターフェース、フィルタされたシステムコール（例: `io_uring`は使えない）、制限されたカーネルcapabilities（例: `CAP_SYS_PTRACE`も`CAP_NET_ADMIN`もない）を備えています。セキュリティ上重要なサービスはruntime cellの外部に置かれ、別々のsystemd unitとして動作します。runtime cellが信頼できないデータを処理することが想定されるため、この分離は重要です。

Muse Secure VM内の別々のsystemdユニットとして動く構成要素のうち、`hatch-safety`は、コアモデル推論との間で行き交うリクエストとレスポンスを検査する、独立したモデルと分類器のセットを運用します。この独立したモデルと分類器はfrontier riskの制御やプロンプトインジェクションの試みなど他の脅威の特定に重要であり、runtime cellの外で動かすため、攻撃者はこの保護を無効にできません。`privsep`ワーカーは、組み込みコネクタのコードを厳密に限定された権限で実行し、接続された認証情報をエージェントの手の届かない範囲に置きます。`hatch-authd`は認証情報の保管と、メインのエージェントが機密性の高い認証情報を目にしないようにするcredential surrogationを担います。利用者が接続を選ぶ第三者サービスのOAuthトークンも、Metaの集中型インフラではなく利用者のVM内に保管されます。

Sentinelは、Museとは別のホスト側のエージェントであり、third-partyサービスへのコネクタを使う操作の承認と、ネットワーク上のすべての外向き通信について、唯一の権限の決定者です。Museは操作を提案しますが、操作の実行を許可できるのはSentinelだけです。Museがコネクタ経由で操作しようとすると、該当するコネクタのツールがruntime cell内で呼び出されます。これによりSentinelにリクエストが送られ、そこにはコネクタ、呼び出すメソッド、class of action、スコープ、ユーザーが何を求めたかというコンテキストが記述されます。Sentinelはそのコンテキストから、ユーザーに見える形のリクエストの目的を生成します。Muse Secure VM内で、永続的なアプリケーション状態はすべて、runtime cellとも認証情報ストアとも分離されたpostgresデータベースに保存されます。Muse Secure VM内では、推論用とテレメトリ用のプロキシが、外部インフラへの制約された経路を公開します。runtime cellとVM内の他のサービスとの通信は、すべてSO_PEERCREDとpeer ACLを使ったUnix domain socketを通じて行われます。これにより、カーネルで認証された最小権限のプロセス間通信になり、盗まれるシークレットがありません。

Sentinelは、ユーザーが設定したコネクタポリシー(connector policy)を評価し、その操作を許可するか、拒否するか、ユーザーに確認するかを決めます。実際のネットワークリクエストはすべて、外向き通信の時点でSentinelが管理します。ランタイムのトラフィックは、Linuxのネットワーク制御(userns、vethの境界、eBPFフィルタリング)で構成されたフォワードプロキシ(forward proxy)を経由してSentinelに届きます。Sentinelはレイヤー4とレイヤー7の両方で通信先を評価でき、評価対象はホスト名、解決後および最終的な宛先IPアドレス、ポート、プロトコル、HTTPメソッド、パス、デコードされた実際のリクエストです。SSRF対策の制限により、一見パブリックなホスト名がDNS検索(DNS lookup)後にプライベートなインフラへ解決されることを防ぎます。シークレットや認証トークンが必要なリクエストについて、Sentinelはジャストインタイムで認証情報を挿入する(just-in-time credential insertion)を行います。シークレットや認証トークンが必要なリクエストでは、runtime cellまたはworker内のコードが目にするのは、authdが発行した「代理(surrogate)」トークンだけです。実際のネットワークリクエストが承認されると、Sentinelはネットワークの境界で、surrogateトークンを、authdから得た本物の認証情報に置き換えます。

エージェントは本物のトークンを目にしないため、プロンプトインジェクションなどで実際のシークレットを開示させようとしても無駄です。Museはユーザー承認のシグナルとノイズの比率を整えるために、カーネルレベルのデータフロー追跡を使用し、これをtaintedな外部への流出(tainted egress)と呼びます。各ツール実行プロセスはクリーンな状態で始まり、ユーザーデータを読み取るとtainted状態になります。taintedな外部への流出では、リクエストに対して適切なユーザー承認を判断するためにtaint情報を使います。狭く限定された自動許可ポリシーの条件を満たし、かつ送信先URLに対する他のチェックも通ったクリーンなネットワークリクエストは、ユーザーを煩わせることなく許可できます。taintedなプロセスや検証できないプロセスは自動許可を失い、通常の承認フローに戻ります。Museのネットワーク外部への流出の制御の実装では、ネットワークのインターセプトとプロセスの帰属にeBPF `cgroup`プログラムを使い、taintの伝播には、追加したLinux Security ModuleフックにアタッチしたeBPFプログラムを使います。Sentinelの判断がユーザーに確認することに決まると、Sentinelは保留中の承認を作成し、実行は停止します。

Museはそれでも誤りを犯しますが、組み込まれた安全システムにより、誤りの頻度はずっと低く、被害もずっと小さくなると開発チームは見込んでいます。大規模なドッグフーディング(dogfooding)、エージェントによるレッドチーミング(red teaming)、および非公開のバグバウンティプログラム(bug bounty program)においてセキュリティ研究者が実際の敵対的シナリオで見つけた問題への対応を通じて、強化も進めてきました。Museは、日常の使用体験に透明性とコントロールを組み込み、デフォルトでユーザーの個人情報の慎重な管理者となることを目指して構築されました。また、Museに最も機密性の高いデータを接続することは信頼の行為であると認識しており、そのことを念頭に置いて設計されています。

ここで説明されているのはローンチ時点のシステムです。開発チームは、変化する脅威の状況には今後も注意を払い、必要に応じて変更を加えるとしています。Museの内部の仕組みを詳しく説明するのは、Museをどのように、どの程度信頼できるかを、実際の使い方に即して読者が把握できるようにするためです。

Sentinelは承認リクエストをMuseクライアントに直接送り、承認すべき具体的な操作を示します。ダイアログはMuseとの会話を介さず、クライアントUI内で直接ユーザーに表示されます。ユーザーの回答はSentinelに直接戻され、Sentinelはその判断に基づいて動作し、権威ある承認状態(authoritative approval state)を更新します。人間による承認(human in the loop approval)によって与えられた承認は、会話上の提案ではなく、特定のコネクタ/宛先とユースケースに紐づけられる厳格なケイパビリティ(capability)として扱われます。Museは1回限り、セッション単位、タスク単位、期間限定、または恒久的な許可を取得することに対応しており、Sentinelがユーザーに選ばせる付与タイプを決めます。人間による承認の狙いはすべてをユーザーに確認することではなく、読み取り専用、以前に許可済み、または明らかに低リスクの操作は中断なく進められます。Sentinelは、その後の呼び出しが付与された範囲と正確に一致するようにします。同意が重要な箇所には手間をかける一方で、日常的な操作は滞りなく進むようにしており、このバランスは実際のユーザーでの経験が増えるにつれて調整していく想定です。

Museは、最小権限(least privilege)の原則を可能な限り適用しており、その例としてAPIキーをモデルに見せないことが挙げられます。基盤サービスが対応している場合、Museは読み取りと書き込みのアクセスを分離します。また、OAuthスコープ(OAuth scope)のような粗いグループを超えて、エージェントが行える操作を細かく制御できます。組み込みコネクタ(built-in connectors)については、ロジックをランタイムの外部で`privsep`を用いて厳密に範囲を絞った認証情報アクセスのもとで実行することで、より高い保護を実現しています。組み込みコネクタのCLIはランタイムセル内で動作しますが、行うのは引数の解析、呼び出し元がすでにアクセスを許されているファイルのオープン、型付きの引数とファイルディスクリプタのUnixソケット経由での受け渡しだけで、ツールの実際のビジネスロジックはsystemdでサンドボックス化されたワーカーが実行します。各ワーカーは`cgroup`で識別され、明示的な認証情報の許可リストを持ちます。Privsepは認証情報を扱えるコードをどこで実行するかを決め、Authdは認証された呼び出し元がどの認証情報を受け取れるかを決め、Sentinelは要求された操作を実行してよいかを決めます。Museのようなエージェントでは、ハーネスと同じ環境で動作するサードパーティのサービス向けのCLIベースのコネクタを持つのが標準的な手法です。プロンプトインジェクションによってエージェントがツールのコードを変更させられた場合、そのCLIがアクセスできるサービスの認証情報を用いて不正な操作が行われるリスクがあります。ユーザーは、エージェントにデータの読み取りアクセス(例:「カレンダーを読んで予定の重なりを知らせて」)を与えるほうが安心しやすく、書き込みアクセス(例:「新しい会議を設定して」)は実際の動作を理解してから与えたがる傾向があります。例えば、Gmail側でGmailの読み取りアクセスのOAuthスコープを付与した場合でも、通常それに付いてくるGmail設定へのアクセス権を外せます。システムは、コネクタ、プロセス、認証情報、リクエストの各レベルで、より細かい制御を加えます。各ワーカーは明示的な認証情報の許可リストを持つため、カレンダーのワーカーがリクエストパラメータを変えるだけで、authdにメールの認証情報を要求することはできません。組み込みコネクタについては、対象となるサービスがユーザーの生活に深く入り込んでいることを踏まえ、Museにより安全にアクセスさせる方法も慎重に検討されました。また、メールアカウントは「forgot password」リンクをクリックすることで、ウェブ上で使う他のほとんどのアカウントのパスワードをリセットするのに使える可能性が高いです。

Museはプロンプトインジェクションによる被害を防ぐために、defense-in-depthのアプローチをとっています。モデルレベルの訓練として、Museのモデルはプロンプトインジェクションを認識して抵抗するよう訓練されており、Muse Spark 1.3はこの能力においてSOTAに近いです。ハーネスレベルの保護では、外部のあらゆるソースからモデルのコンテキストにデータが入るとき、そのデータはuntrusted inputとしてラベル付けされます。このラベル付けと、開発者の指示をより強く守るモデルの能力が合わさることで、有害になりうるデータがある状況において、どの指示に従いどの指示を無視するかを理解するモデルの中核能力が増幅されます。プロンプトインジェクション対策として、実際のデータセットにあるプロンプトインジェクションの試みと自社の大規模なエージェント型レッドチーミングで見つかった試みを検出するよう訓練された複数の分類器のアンサンブルが、ファイルやツール呼び出しを通じてモデルのコンテキストに入るすべての外部データに対して、互いに並列で実行されます。これらは、エージェントの動作を操作しようとする試みが見つかったときに断固とした措置をとれるようにするためのものであり、このシステムをモデルとは独立に訓練することで、システム全体としてはるかに高い精度を達成できます。データをVMの外へ移す操作には、human in the loopによる承認が必要です。エージェントが致命的な三要素の3つの機能である、非公開データへのアクセス、信頼できないコンテンツへの露出、およびデータを盗むのに使われうる外部通信をすべて併せ持つと、攻撃者は容易にエージェントをだまして非公開データにアクセスさせ、その攻撃者へ送信させることが可能になります。ユーザーのプライベートデータへのアクセスは、致命的な三要素(lethal trifecta)とされる能力の1つですが、ツールがそもそも果たす最も一般的な用途の1つでもあります。エージェントの下層にもdefense in depthがあり、Museが不適切な動作をするよう説得されたとしても適用される決定論的な境界が存在します。具体的には、runtime cellはシステムアクセスを制限し、privsepはどのコードがどの認証情報を見られるかを制限し、authdはACLを適用し、Sentinelはすべてのアクションとネットワークの外向き通信であるnetwork egressを評価します。Museのブラウザでは、ウェブ上で観察するテキストまたは画像のデータを通じたモデルへのプロンプトインジェクションや誘導が重要な攻撃経路のひとつであり、これまでに述べた保護に加えてさらなる保護を適用しています。なお、モデルレベルの訓練については、プロンプトインジェクションを認識して抵抗するという指標でのモデルレベルの性能を継続的に追跡できる、厳密なevalsのセットを開発しています。

利用者がMuseに入れるすべてのもののsystem of record(記録の正本)は、専用のVirtual Machine(VM)です。Museは、推論とテレメトリに必要な場合に限り、限られたデータをVirtual Machine(VM)の外へ送ります。ユーザーがVMに置いたファイルと、Museがユーザーに代わって生成・使用するものはすべてVMに保存されます。これにはMuseのユーザーに関するメモリも含まれ、ユーザーはこれらのファイルを自由に確認・編集・ダウンロードできます。また、接続したサードパーティのサービス（third-party services）の認証情報と認証トークンは、Metaの他のサービスではなく、Virtual Machine(VM)内の別の隔離されたコンテナに保存されます。ユーザーのVirtual Machine(VM)のデータは継続的にバックアップされ、問題が起きた場合に復元できます。

Museは、組み込みコネクタのロジックをランタイムセルの外部で、`privsep`を使って厳密に範囲を絞った認証情報アクセスのもとで実行しています。ブラウザも、これと同様のパターンに従います。CDPアクセスはランタイムセルの外部にあるブローカー内にあり、ブラウザエージェントはそれに対する狭く制御されたインターフェースを得ます。ブラウザは、Chrome DevTools Protocolの接続を管理する別個のブローカーによって管理されます。Museのブラウザ用サブエージェントは、ページのアクセシビリティツリーのスナップショットを見るため、生のDOMは見ません。このサブエージェントは、認証情報ストアから入力された認証情報を読み取ることも、DOMから手動で取り出すこともできません。また、ページコンテキストでjavascriptを実行できず、script verbもブラウザプロセス内のexecもなく、Chrome devtoolsは無効化されています。ユーザーがブラウザの操作を引き継いだときと、安全な認証情報ストレージがフォームに入力している間は、Museのエージェントは一時停止され、まったく操作できません。Museのブラウザ用の分類器群は、タスクと無関係な個人データがブラウザ経由で外部に出ることを検出対象にしています。また、ウェブページのDOM内にあるプロンプトインジェクションの試み、画像やメディアを介したプロンプトインジェクションの試み、およびブラウザ経由でダウンロードされたファイルを介したプロンプトインジェクションの試みを検知対象としています。さらに、リスクの高いフォームの送信の試みも検出対象にしています。これらの分類器は、検知した脅威に応じて、操作をブロックするか、これから行われる内容の確認をユーザーに求めます。

Museのブラウザは、仮想化レイヤーの背後で動く最新のChromiumベースの実際のブラウザを備えており、ユーザーはいつでも操作を引き継げます。ウェブサイトへのサインインを行う場合、クライアント上のカスタムUIで取得したユーザー名とパスワードは`authd`に直接送られ、安全な認証情報ストアに保存されます。入力内容はメインのエージェントには見えませんが、必要な時点でブラウザウィンドウに注入されます。Muse Spark 1.3モデルはウェブブラウザの操作が特に得意で、Museは各タスクを完了するために専用のブラウザ用サブエージェントを使用します。このサブエージェントには、コンテンツのどの部分が敵対的である可能性があるかについて、ウェブに特化した指示が与えられています。ユーザーが最もよく求めることのひとつは、ブラウザでウェブサイトにサインインすることです。ユーザーは、Museがブラウザ内で行っていることを見ることができます。クライアント上のカスタムUIでユーザー名とパスワードを受け取り、`authd`に直接渡して、Muse VM内のruntime cellの外部にある安全な認証情報ストアに保存します。

Museのメールコネクタは、ワンタイムトークンのパスコード、パスワードリセットリンク、ログイン用マジックリンクを、決定論的フィルターと分類器(classifier)の両方で除外します。これは、メールをMuseに接続しても、エージェント自身や、エージェントを強制的に操ろうとする第三者が、他のサイトでユーザーの代わりに振る舞えないようにするためです。メインのメール受信箱には、ワンタイムトークンのパスコードが多く届いている可能性が高く、メールアカウントは「forgot password」リンクから、ウェブ上の他のほとんどのアカウントのパスワードリセットに使える可能性が高いです。

Museは他のAIシステムと同様に、ときに誤りを犯します。Museは敵対的な環境で動作する必要もあります。プロンプトインジェクションは業界で未解決の問題であり、Museは攻撃を受けない存在ではありません。Metaは、問題が起きたときの影響を限定し、ユーザーが圧倒されずに主導権を保てるようシステムを設計しています。Museでは、スタックのどの層で問題が起きても影響を限定するために、defense in depth(多層防御)の考え方を適用しています。プロンプトインジェクションによる被害リスクを減らすためにとったアプローチは、その好例です。Metaは、パーソナルエージェント向けに、Metaを含むどのサービス提供者も情報を見たりアクセスを付与したりできない完全プライベートモードを、人々が選べるべきだと考えています。MetaはMuse Confidential VMに多額の投資をしており、この機能を今年後半に提供する予定です。Muse Confidential VMは、VM内のデータへのMetaのアクセスを、暗号的かつ検証可能な形で防ぐことを意図しています。バグバウンティプログラムは現在開始されており、成功したプロンプトインジェクションには報奨金が支払われます。これは、見つけることが不可能だと考えているからではなく、このセキュリティのベストプラクティスがMuseの実環境での挙動を最も速く改善するのに役立つためです。

Metaは、同社のアプリ群への投稿や広告を通じてユーザーが誘導されうる悪意あるウェブサイトを検知・ブロックする既存のシステムを持っています。Metaは、ユーザーのVM内でそのリストと照合し、既知の有害なサイトへのブラウザの遷移を止めることができます。Museを使った買い物は、ブラウザの利用事例の中で最も人気のあるものの1つです。購入での間違いはユーザーに実際の金銭的損失を与えかねないため、Metaはこれを特に慎重に扱っています。支払い情報がすでに登録されているウェブサイトで買い物をする場合、Museのブラウザにはチェックアウトページにいることを検出する仕組みが組み込まれており、購入の正確な詳細を示して、毎回人間による承認を求めます。まだ買い物をしたことのないサイト向けに、Museには支払い情報を規約に準拠した形で保存できるウォレットがあります。Museのウォレットは、提供開始時点ではStripe Linkと提携しており、Shop Payは近日対応予定です。Museのウォレットで支払う際は、通常のクレジットカードではなく、使い捨て(single-use)のカード番号が発行されて加盟店のウェブサイトに渡されます。このウォレットでの支払いイベントごとに、人間による承認を求めます。Museのウォレットで発行される使い捨てカードの認証情報は、特定の加盟店と特定の金額に紐づけられ、限られた期間のみ有効です。そのため、プロンプトインジェクションなどの攻撃で盗まれても、攻撃者にとってあまり役に立ちません。

9月8日、パーソナルエージェントMuseのバグバウンティプログラムが誰にでも公開され、問題を責任をもって開示できるようになりました。有効な報告に対しては最大$300,000が支払われ、1人のユーザーに影響する成功したプロンプトインジェクションの試みに対しては最大$130,000が含まれます。

Museの保護策への確信は、継続的なエージェント型レッドチーミング(agentic red teaming)によって得ており、この取り組みは、保護策をオフラインで評価するための非常に難しい評価セット(evals)の構築にも役立ちました。また、Museの保護策について、年間を通じて、バグバウンティプログラムを通じて外部のセキュリティ研究者と協力してきました。このバグバウンティプログラムは、問題を責任ある形で開示する人なら誰にでも開放されています。有効な報告には、成功したプロンプトインジェクションの試みを含む実証された影響に基づき、最大$300,000が支払われます。

Muse Confidential VMは、すでに少人数の信頼できるテスターと使用されており、設計とソースコードを外部の監査人に提供し始めています。現在は監査人のフィードバックを取り込んでいる最中です。公開後は、誰でも見て検査できる継続的な監査の対象となり、専門家はMetaがconfidential VM環境内のデータにアクセスできないことを確認できるようになります。セキュリティやプライバシーの専門家がMuse Confidential VMの早期アクセスを希望する場合は、muse-security@meta.com に連絡できます。

データの扱いと訓練への利用

現在のMuseのアーキテクチャは、各ユーザーのデータを互いに分離して安全に保ちます。Meta職員によるデータへのアクセスは運用ポリシーで制限されていますが、サービスの提供・保護・運用のために必要な場合にMetaがデータにアクセスすることは妨げません。Museは、ユーザーとの会話やVirtual Machine内のデータをMetaの広告システムと共有しません。ただし、Museがインターネットを閲覧する行為はユーザー自身のアクティビティとして表示されるため、例えばデザイナーのサイトでシャツを買わせた場合に、そのデザイナーが訪問を利用してInstagramで広告を表示するといった、表示される広告に影響を与える正当な場面があります。同様に、レストランの予約やFacebook Marketplaceでの商品探しも、表示される広告に間接的に影響することがあります。

ユーザーとMuseの間の往復の会話や、そこから生じるツール呼び出しやサブエージェントへの引き継ぎであるtrajectoriesは、中核のLLMモデルの新しいチェックポイントを訓練するのに有用なデータです。これらのtrajectoriesは、訓練に使われる前に、主要な個人を特定できる情報を除去するようサニタイズされます。データをモデル訓練に一切使われたくない場合は、Museの設定にあるシンプルなスイッチでオプトアウトできます。