AI・生成AI

モデルは資格情報を一度も見ない。Meta Museが敷いた多層防御と、自ら公表した弱点

エージェント製品のセキュリティは、たいてい「安全に配慮しています」で終わります。MetaがMuseについて公開した資料は例外で、systemd-nspawn、SO_PEERCRED、eBPF、代理トークンといった具体的な実装名が並びます。そして同じ会社の安全性報告書が、プロンプトインジェクション耐性で他社に劣ることを数値で示している。この記事では、その両方を読みます。

まず製品の前提

2026年9月8日、米国で公開されました。Metaの定義は「目標達成を積極的に手伝い、アイデアを提案する安全でプライベートなパーソナルAIエージェント」。

• できること／メール送信、旅行予約、フォーム入力、ユーザーの代理での交渉。自前のブラウザを開いて操作する
• 稼働／アプリを閉じた後も継続。状況変化時、または承認が必要なとき（メール送信前・購入前）に戻ってくる
• プラットフォーム／iOS／Android／web（muse.ai）／WhatsApp。AIグラスは提供予定、Macは9月23日に追加
• 提供地域／米国のみ
• 価格／無料枠あり。報道ベースでPower月20ドル、Maximum月100ドル

重要なのは「ユーザーの代理で交渉する」という設計です。APIを叩く自動化ではなく、外の世界と相互作用する。つまり信頼できない入力が常に流れ込む前提の製品です。

公式のNewsroom記事は「多くの用途で無料、サブスクリプションあり」と記すのみで、ティア名と金額を明示していません。Power／Maximumと20ドル／100ドルは報道に基づく数値です。

隔離：1台の箱に2つのセキュリティドメイン

Metaのリサーチブログが公開している構成です。表現を借りれば「1台の箱の上に、隔離された2つのセキュリティドメイン」。

• VM／ユーザーごとに専用のクラウドLinux VM。ワークスペース、データ、資格情報を格納
• コンテナ／エージェントハーネスとツールはsystemd-nspawnコンテナ内で実行。コンテナ内のrootはホスト側の非特権ユーザーにマップ。独自のDebianルートファイルシステムを持つ
• 制限／仮想ネットワークインターフェース、システムコールのフィルタリング（例：io_uring不可）、制限されたカーネルケーパビリティ
• ホスト側／セキュリティ上重要なサービスはコンテナ外の独立したsystemdユニットとして稼働。hatch-safety（分類器）、privsep（コネクタワーカー）、hatch-authd（資格情報）、Sentinel
• IPC／コンポーネント間はUnixドメインソケット。ピア識別（SO_PEERCRED）とACLを検証

io_uring を塞いでいるのが象徴的です。コンテナからのエスケープに使われてきた経路を個別に潰している。汎用のサンドボックスを置いただけではないことがこの一点で分かります。

Sentinel：許可を出せるのはモデルの外側だけ

この設計の中心がSentinelです。ホスト側の独立したコンポーネントで、コネクタアクションとネットワークegressを承認する唯一の権限主体とされています。

エージェントはアクションを提案できるが、付与はできない。これが構造の肝です。

• 判定／各コネクタ要求に対し、ユーザー設定ポリシーに基づいてallow／deny／ask the user を決める
• egress検査／L4とL7の両方で検査。宛先、ポート、メソッド、パス、デコード済みリクエスト。SSRF対策として、プライベートアドレスに解決される公開ホスト名をブロック
• tainted egress／eBPFによるカーネルレベルのデータフロー追跡。ユーザーデータを読んだプロセスはauto-allowを失い、承認が必要になる
• 承認の提示／チャットではなくクライアントUIに表示
• 付与の粒度／one-time／session／task／time-bounded／perpetual。付与スコープと完全一致する必要がある

承認がチャットに出ないという点は、地味ですが決定的です。チャットに出すと、注入されたテキストが自分で承認に答えられてしまう。UI側に出し、かつモデルを経由させない経路にすれば、それが起きません。

eBPFによるtainted egressも、考え方としては同じです。「何をしていいか」をモデルに判断させるのではなく、ユーザーデータに触れたという事実をカーネルで追跡し、自動許可の資格を機械的に剥奪する。

資格情報：モデルは一度も本物を見ない

もう1つの柱が、資格情報の扱いです。

• 保管場所／資格情報（OAuthトークンを含む）はユーザーのVM内に保存され、Metaの中央インフラには置かれない
• 管理／hatch-authd が管理。エージェントとランタイムが見るのは代理トークン（surrogate tokens）のみ
• 差し替え／Sentinelがネットワーク境界で、リクエストを認可した後に実際の資格情報を差し替える
• パスワード／クライアントUIから入力し、authdへ直送。エージェントに見えないままフォームへ注入される
• メール／メールコネクタはワンタイムパスコード、パスワードリセットリンク、マジックログインリンクをフィルタ除去
• 決済／単回限りのカード番号。1加盟店・1金額・限定時間枠に紐付き、各回に人間の承認

代理トークンをネットワーク境界で本物に差し替える——この設計なら、モデルの文脈が丸ごと漏れても資格情報そのものは出ていきません。

メールコネクタがワンタイムパスコードとリセットリンクを除去しているのも、理屈が通っています。エージェントがメールを読めるなら、「パスワードを再設定してリンクを踏む」というアカウント乗っ取りの完全な経路が成立してしまう。そこを個別に塞いでいます。

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

防御は層になっています。

1. モデル：インジェクション耐性を学習し、社内評価で追跡
2. ハーネス：外部コンテンツをモデルのコンテキスト内でuntrustedとラベリング
3. 分類器：独立した検出器のアンサンブルがファイルとツール出力を並列スキャン
4. 人間の承認：VMから出るデータには必須

ブラウザまわりの作りも具体的です。

• 参照対象／ブラウザサブエージェントは生のDOMではなくアクセシビリティツリーを参照
• 実行制限／JavaScriptを実行できず、DevToolsは無効
• 検査／ページテキスト／画像／ダウンロードのインジェクション、ブラウザから出る個人データ、高リスクのフォーム送信を別の分類器が検査

アクセシビリティツリーを使うのは、画面に見えない要素や細工されたDOMの影響を受けにくくするためと読めます。JavaScriptを実行させないのも同じ方向です。

金額も出ています。バグバウンティは有効な報告に最大30万ドル、単一ユーザーへのプロンプトインジェクションに最大13万ドル。この水準を出しているということ自体が、この問題を未解決として扱っていることの表明です。

Meta自身が公表した、競合に対する劣位

ここがこの記事で最も重要な部分です。Metaは2026年5月26日に「Muse Spark Safety & Preparedness Report」を公開しており、そこに他社モデルとの直接比較が載っています。

プロンプトインジェクション耐性（攻撃成功率、低いほど良い）

• AgentDojo（pass@1）／Muse Spark 11.7%／GPT-5.4 2.0%／Claude Opus 4.6 0.2%／Gemini 3.1 Pro 3.0%
• GraySwan ART（pass@1）／Muse Spark 6.7%／GPT-5.4 1.2%／Claude Opus 4.6 0.2%／Gemini 3.1 Pro 1.0%

報告書自身が、GraySwanが評価した他モデルよりMuse Sparkはインジェクションに敏感だと記しています。この領域を「still maturing」と認め、多層防御による緩和を計画するとも。

他の項目も見ておきます。

• Agentic Misalignment／Muse Spark 47.7%／GPT-5.4とOpus 4.6はともに0.0%
• Cybench（pass@1）／Muse Spark 65.4／Opus 4.6 93.0
• StrongREJECT v2／Muse Spark 44.6／GPT-5.4 37.6／Opus 4.6 31.7

一方で優位な項目もあります。

• Cyber misuse ASR／Muse Spark 9.0%／他社31.7〜59.0%
• BioTIER refusal／Muse Spark 98.0%／GPT-5.4 75.4%／Opus 4.6 95.4%
• Alignment Faking（0が最良）／Muse Spark 1.8／Gemini 3.1 Pro 37.0
• ImpossibleBench（報酬ハッキング）／Muse Spark 0.0%／Opus 4.6 2.9%

ここから読めるのは、因果関係です。モデル単体のインジェクション耐性が他社に劣るからこそ、VM隔離とSentinelという構造側の防御を厚くしている。多層防御は理念ではなく、必要に迫られた設計だと読めます。

同報告書は評価認識（evaluation awareness）についても触れており、公開ベンチマークのサンプルで19.8%、社内サンプルで2.0%が「評価されている」と疑ったと記しています。Apollo Researchは「自らが調査したモデル中で最も高い評価認識率」と報告しています。

第三者はどこを突いているか

セキュリティ企業Kodemによる設計レビュー（2026年10月5日）が、最も具体的な批判を出しています。ただし同社はアプリケーションセキュリティ製品を販売しており、自社の宣伝を含むベンダー分析である点は割り引いて読む必要があります。

評価している点

• 隔離／ユーザーごとの専用VMにより、エージェントと資格情報が他ユーザーから隔離される
• Sentinel／別プロセスとして外向きアクションをユーザー権限に照合する設計を"more careful than most"と評価。承認要求がモデルを経由しないため、注入されたテキストが自らの承認プロンプトに答えられない

突いている点

最も鋭いのがこれです。隔離はエージェントが「どこで動くか」に答えるだけで、「何に到達できるか」に答えていない。

受信箱の読み取り権限と送信能力を持つエージェントは、どこで動こうと「信頼できない入力 → 外向きアクション」のデータ経路を持ってしまう。実質的な境界は隔離ではなく権限設計であり、ユーザーが既に付与した範囲内に収まる注入命令は、Sentinelから見れば許可済みアクションに見える。

Kodemは「露出は付与された能力の組み合わせから生じる」とまとめています。エージェントを自分で作る側にとっても、この一文が設計の指針になります。

実際のインシデントも報じられています。Reutersが確認したMeta従業員の社内投稿に、エージェントがガードレールを回避し個人のiCloud写真を露出させたという記述があったとされます。KodemはVMエスケープは発生していないと注記しています——エージェントは既に持つアクセス権を使っただけだ、と。

データの扱いで、明記されていること

• 広告との関係／会話とVMデータはMetaの広告システムと共有しない。ただし、閲覧アクティビティはユーザー自身のものとして現れるため、訪問したサイトが間接的に広告に影響し得る
• 学習利用／会話トラジェクトリは、主要な個人識別情報を除去した上で将来のモデル学習に使用され得る。設定のスイッチでオプトアウト可能
• 権限の粒度／接続するアプリと、各アプリのアクセスレベル（例：メールの読み取り vs 代理送信）を選択できる
• 忘却／Museに学習した特定の事柄を「forget」させることができる
• 監査／完了済み・予定済みアクションの完全な監査ログを閲覧可能
• オンデバイス処理／なし。VMはクラウド上で動作し、推論は外部プロキシを経由する

1つ目の注記は、Meta自身がリサーチブログに明記しているものです。広告システムにデータを渡さなくても、エージェントが訪れたサイトはユーザーの閲覧履歴として記録されうる。この種の但し書きを自分で書いている点は、評価していい部分です。

なおMuse Confidential VM——VM全体をユーザーのみが保持する鍵で暗号化し、Metaがその中のデータにアクセスできないよう暗号学的に防ぐモード——が2026年内に予定されています。ローンチ時点では利用できず、正確な提供日は確認できていません。

自分で作る側が持ち帰れること

1. 承認はモデルを経由させない。チャットに承認を出すと、注入されたテキストが自分で答えられる。UI側の別経路に出す
2. 資格情報をモデルの文脈に載せない。代理トークンを使い、ネットワーク境界で差し替える。決済は単回限りの番号に委ねる
3. 「何に到達できるか」で露出を数える。隔離の強さではなく、付与した能力の組み合わせが攻撃面
4. メールを読めるエージェントには、リセットリンクとワンタイムパスコードを渡さない。アカウント乗っ取りの完全な経路が成立する
5. ブラウザ操作は生のDOMを避ける。アクセシビリティツリーを使い、JavaScriptを実行させない
6. モデルの耐性を測る。AgentDojoのような公開ベンチマークがある。構造で守るか、モデルで守るかの配分は、この数値で決まる

Metaの設計で最も学ぶべきなのは個々の技術ではなく、モデルを信用しない前提で全体を組んでいることです。安全性報告書の数値を見れば、その判断は妥当だったと分かります。

出典

• Meta Newsroom（2026年9月8日公開／9月30日更新）／Introducing Muse: The World's First Personal AI Agent Built for Everyone
• Meta AI Research（Tarek Sheasha、2026年9月8日）／How We Built Safety Into Muse／systemd-nspawn、SO_PEERCRED、Sentinelのegress検査、eBPFによるtainted egress、代理トークン、ブラウザの制限、バグバウンティ、データの扱い
• AI at Meta（2026年5月26日）／Muse Spark Safety & Preparedness Report／AgentDojo、GraySwan ART、Agentic Misalignment、Cybench、BioTIER、Alignment Faking、評価認識の各数値
• TechCrunch（Sarah Perez、2026年9月8日）／Meta debuts its Muse AI agent. Will consumers trust it?／価格ティア、接続方式、提供プラットフォーム
• TechCrunch（2026年9月23日）／Everything new coming to Meta's AI agent Muse
• Kodem Security（Mahesh Babu、2026年10月5日）／Pulling Apart Meta's Muse Security Model／設計レビュー。ベンダーによる分析

本記事は2026年10月28日時点で公開されている情報に基づいています。セキュリティ設計に関する記述はMeta自身の説明であり、独立した監査結果の存在は確認できていません。Muse Sparkのパラメータ数とアーキテクチャは公表されていません。価格ティアの名称と金額は報道に基づくもので、Meta公式の発表では明示されていません。