Meta Museのファイルシステムエクスポートが露呈させた、隔離と制御の隔たり
ユーザーが閲覧可能なすべてをアーカイブするよう依頼した後、Meta Museが6.8 GBのランタイムファイルをエクスポートしたと報じられている。開発者Peter Jamesによると、Meta Museのファイルシステムエクスポートには、システムファイル、内部文書、アプリテンプレート、メモリ記録、エージェントログが含まれていた。これは、MetaがMuseを安全なパーソナルエージェントとして発表してからおよそ2週間後に起きたという。
この主張は、JamesがMetaのホストインフラや他顧客のデータに到達したことを示すものではない。Metaは、Museの各ユーザーに隔離された仮想マシンが割り当てられており、そのファイルシステムは個人用ノートPC上のファイルと同等だとしている。しかし、この説明には、より難しい問いが残る。これらのファイルが割り当て環境内に置かれているというだけで、消費者向けエージェントが内部ランタイムの資料を配布してよいのだろうか。
この対立は、AIエージェントのファイルをダウンロードできるという目新しさ以上に重要だ。Metaは、隔離、権限チェック、そして独立したセキュリティコントローラーをMuseの中核的な保護策として提示している。報じられたエクスポートは、隔離が維持されていても、情報制御ポリシーが製品境界でなお破綻しうることを示唆している。
Meta Museのファイルシステムエクスポートに含まれていたもの
最も明確に検証された主張は限定的だが重大である。Museは、自身に割り当てられたランタイム内のファイルをパッケージ化し、接続済みのGoogle Driveへ転送したと報じられている。
Jamesは2026年9月22日に自身の説明を公開した。Museに対し、アクセス可能なファイルをアーカイブして自身のDriveへ送るよう依頼したという。結果として得られたダウンロードは圧縮時で約2.7 GB、展開後で6.8 GBだった。
Museの配信メッセージでは、アーカイブは2.86 GBと説明されていたとされ、Jamesの記録との間には小さな差異がある。Jamesは両方の測定値を同一として扱うのではなく、この違いを開示した。アーカイブ自体は公開されておらず、独立した検証には限界がある。
Jamesの詳細なruntime exportによると、ファイルは彼のMuseセッションに割り当てられたルートファイルシステムを表しているように見えた。そこにはUbuntuのシステムファイル、統合コード、アプリケーションテンプレート、内部文書、メモリファイル、エージェント活動のログが含まれていた。
アーカイブにはSSH鍵ファイルも含まれていた。ただしJamesは、それらの鍵が有効なままか、どのシステムにアクセスできるのかを確認していない。そのため、存在自体は調査に値するが、それだけで不正アクセスを立証するものではない。
複数のディレクトリは、報じられた環境の詳細な姿を示していた。エージェントのホームディレクトリには、SOUL.md、IDENTITY.md、USER.md、MEMORY.md、AGENTS.md、TOOLS.mdなどの名前を持つ指示・アイデンティティファイルが含まれていた。
Jamesは、JSONLトレースとして保存された113件のサブエージェント記録を数えた。また、ブラウザの挙動、コネクター、認証情報、支払い、スケジューリング、生成ファイル、音声機能、データ処理を扱うMarkdown文書を約20件見つけた。
別のディレクトリには、約68個のスキルフォルダがあったとされる。これらは、メール、カレンダー、旅行、ショッピング、健康、メディア、接続デバイスにまたがるサービス向けに、文書化された指示とコマンドラインユーティリティ、または補助コードを組み合わせていた。
ファイルは、Museがどのようにランタイムを組み立てていたかも示していたようだ。Jamesは、プロセスに隔離されたファイルシステムと限定的な権限を与えるLinuxの隔離環境であるsystemd-nspawnコンテナの構築・起動に関連する18個のファイルについて説明した。
この詳細は、Meta自身が公開しているアーキテクチャとおおむね一致する。Metaによると、Museは、分離されたランタイムセル、認証情報サービス、データベース、セキュリティコンポーネントを含む専用仮想マシンを使用する。また、HatchがMuseの内部コードネームであることも確認している。
開発者Jonny L. Saundersは、この大まかな結果を独自に再現したと述べた。プロセスは極めて容易だったと説明し、Museはプロンプトインジェクションにほとんど抵抗を示さなかったと主張した。
最も強力な独立検証はThe Vergeによるものだった。同誌の記者によると、Museは当初、完全なファイルシステムを求める要求を拒否した。しかし新しいセッションで異なる表現を用いたところ、Museは/opt/hatchと/home/hatchのサニタイズ済みコピー、およびディレクトリツリーを提供したとされる。
この試みでは、Jamesのアーカイブに含まれるすべての要素は再現されなかった。MuseはSSH鍵などの項目を削除したと報じられている。それでも、返されたファイルはJamesとSaundersが説明した資料と整合しているように見えたと、元のfilesystem reportは伝えている。
これらの説明は、限定的な結論を支持する。少なくとも報告されたテスト時点では、Museは通常の会話を通じて、割り当てられたランタイムの相当部分を露出させることができた。これらはコンテナエスケープ、アカウント間アクセス、またはMetaの基盤クラウドホストの侵害を立証するものではない。
Jamesは、コンテナからの脱出を実証していないと明言した。境界を短時間テストし、維持されているように見えることを確認したうえで、本番システムのより深い検証を試みる前に停止した。
この区別は、インシデントのあらゆる解釈を左右すべきだ。結果をMetaのインフラ全体に対する完全な侵害と呼ぶのは、利用可能な証拠を超えている。一方で、意味がないと片付けることも、エクスポートされたファイルに含まれていたと報じられる内容を無視している。
Metaはファイルがユーザーの仮想マシンに属すると説明
Metaの擁護は、所有権と隔離に基づく。ユーザーは、Metaの特権システムや他ユーザーにアクセスすることなく、自分に割り当てられたコンピューターを確認できるという。
Metaの広報担当者はThe Vergeに対し、このインシデントはセキュリティ侵害ではないと述べた。同社はこの挙動を、ユーザーの目の前にあるノートPC上のファイルを閲覧することになぞらえた。
広報担当のDaniel Robertsは「もちろんファイルは見られます」と語った。また、仮想マシンのデータをエクスポートしても、Metaのインフラや他者の情報への特権アクセスは得られないと付け加えた。
この主張は技術的には筋が通っている。隔離コンテナ内のルートディレクトリは、必ずしもそのホストのルートディレクトリではない。「root」という語はファイルシステム内の位置を示すものであり、普遍的なアクセス権があるという誤解を招きうる。
Metaが公開したsecurity architectureによると、各ユーザーとそのMuseは専用のLinux仮想マシンを共有する。その内部では、主要なHatchランタイムがsystemd-nspawnコンテナ内で動作する。
Metaによると、そのコンテナ内のrootはホスト上の非特権ユーザーにマッピングされる。コンテナには独自のDebianファイルシステム、フィルタリングされたシステムコール、仮想ネットワークインターフェース、縮小されたLinux capabilitiesが与えられる。
機密サービスはランタイムセルの外部に置かれている。これには認証情報ストア、コネクターワーカー、永続的なアプリケーションデータベース、推論プロキシ、そしてMetaの独立した権限機関であるSentinelが含まれる。
Metaによると、Sentinelはコネクターのアクションとネットワークアクセスを制御する。Museがアクションを提案し、Sentinelが許可、拒否、またはユーザー承認の要求を判断する。
この設計は複数の深刻な脅威に対処する。プロンプトがモデルを操作したとしても、モデルが自動的にパスワード、決済認証情報、ホストレベルの権限、無制限のネットワークアクセスを得るべきではない。
Metaは、コネクターの認証情報はエージェントが直接取得できない範囲に保持されるとしている。ランタイムが見るのは一時的な代理トークンであり、Sentinelは承認済みネットワーク境界においてのみ、それを実際の認証情報に置き換える。
この分離は、Metaが侵害という呼び方を退ける理由の説明にもなる。エクスポートされたファイルシステムに他顧客のデータ、中央の認証情報ストア、または共有Metaインフラへの直接アクセスが含まれていたことを示す公的証拠はない。
James自身の観察も、Metaの立場の一部を裏付ける。彼はコンテナ作成を説明するスクリプトを確認できたが、割り当て環境を超えるアクセスは証明していない。彼の報告書も、アーカイブだけではMetaのサービス全体を監査するには不十分だったと述べている。
しかし、MetaのノートPCというたとえは、異なる複数の問題を一つに圧縮している。通常、個人用ノートPCはOSやローカルにインストールされた大半のファイルを含め、所有者に帰属する。MuseはMetaが管理するクラウド内で動作し、独自の指示、テンプレート、バイナリ、未公開と思われる参照情報を含んでいる。
ユーザーはまた、従来のシステム管理コンソールではなく、会話型インターフェースを介してMuseを利用する。このインターフェースは、一部の要求を拒否する一方、異なる言い回しによる類似の要求は実行したと報じられている。このような不整合は、製品の少なくとも一部がこれらのファイルを制限対象として扱っていたことを示唆する。
Metaは、セキュリティとプライバシーを目立つ訴求点としてMuseを発表した。launch announcementでは、ユーザーが主導権を維持し、機密性の高い操作には承認が必要であり、Sentinelが外部アクセスを統制するとしている。
同じ発表では、エージェントがWebサイトを閲覧し、メッセージを送信し、フォームを入力し、購入を行い、個人向けサービスに接続できるとしている。こうした能力により、認可境界は、隔離されたコーディングデモの場合よりも重要になる。
Metaはまた、Museがユーザーのデータを専用仮想マシン内に保存すると説明している。そのため、「すべて」をエクスポートする要求には、ユーザー所有のファイル、エージェントメモリ、システムコンポーネント、独自の指示、運用ログ、鍵素材の可能性といった複数のカテゴリーが混在しうる。
このコレクション全体を通常のユーザー可視データとして扱えば、製品ポリシーは単純化される。しかし、含まれるすべてのファイルが意図的にエクスポート可能にされたかどうかは決着しない。
MetaはThe Vergeに対し、製品の更新を継続すると述べた。したがって、ユーザーが仮想マシンについて利用できる情報量は変わる可能性がある。この回答は、現在の境界がなお洗練途上であることを示唆している。
隔離は機能したが、情報制御はなお不完全に見える
核心となる逆説は、Museのサンドボックスがエージェントを封じ込めることには成功していた可能性がある一方で、Metaが会話を通じて表出させる意図はおそらくなかったファイルの開示を許していた点にある。
サンドボックスはプログラムがどこで動作できるかを制限する。どの読み取り可能なファイルをプログラムが要約、アーカイブ、または外部送信すべきかを自動的に決めるわけではない。
この違いは見落としやすい。Museが通常の作業中に内部文書を読めるなら、モデルはその文書を出力に含められる可能性がある。承認済みのコネクターがファイルアップロードを許可している場合、同じコンテンツはコンテナエスケープなしにランタイム外へ出ていくことができる。
したがって、報じられたMeta Museのファイルシステムエクスポートは、仮想化境界だけでなく、情報フローの境界を試している。重要なのは、Museが広範な読み取りアクセスと、得られたデータをパッケージ化してエクスポートする権限を組み合わせるべきかどうかだ。
Metaのアーキテクチャには、tainted egressという概念が含まれる。簡単に言えば、プロセスはユーザーデータを読み取った後にマークされ、情報が仮想マシンを出る前にSentinelがより厳格な制御を適用できるようになる。
公開文書は、ユーザー情報と認証情報の保護に大きく焦点を当てている。Sentinelが宛先、ネットワーク方式、リクエストパス、そしてプロセスが機密情報を扱ったかどうかを評価すると説明している。
このファイルシステムの事例は、内部ランタイムファイルにも同等の分類が適用されるのかを問うものだ。Museが指示ファイル、アプリケーションテンプレート、またはエージェントトレースを読み取るなら、送信されるアーカイブには、その内容を反映したポリシーラベルが付与されるべきだろう。
Google Drive への包括的な書き込み承認が、あらゆる可能性のあるファイルに対する有意な同意を意味するとは限らない。ユーザーは、生成されたドキュメントを承認したのであって、エージェントの実行環境のイメージを承認したわけではないと考えるかもしれない。
ここで、Meta の所有権に関する主張と製品の挙動は乖離する。法的または運用上、ファイルがユーザーに割り当てられたマシンに属していたとしても、エージェントにはそれらを公開するための予測可能なルールが依然として必要だ。
The Verge が報じた不整合は、その隔たりを可視化している。あるセッションでは、完全なエクスポートをセキュリティリスクとして拒否した。一方、別のセッションでは、お世辞や好奇心の表明を受けた後、サニタイズ済みのサブディレクトリを提供したとされる。
この挙動は、信頼できるシステムポリシーというより、プロンプトレベルの制限に近い。プロンプトレベルの制限は、言語モデルが意図を正しく解釈することに依存しており、その解釈はセッションや表現によって変わり得る。
より強力な制御では、モデルの外部でファイルを分類し、その分類をツール層で強制するべきだ。そうすれば、ユーザーがどれほど説得力のある表現で要求しても、アーカイブコマンドは保護対象のパスを除外できる。
同じ原則は接続済みサービスにも当てはまる。広範なユーザー要求が、ログ、認証情報、内部ファイル、個人のメモリを一つの外部アーカイブへ移すことを承認しているかどうかを、モデルだけで判断すべきではない。
これらはいずれも、Sentinel が文書化された役割を果たせなかったことを証明するものではない。James は意図的にエクスポートを要求し、自ら管理する保存先を指定した。Sentinel はその操作をユーザー承認済みとして扱った可能性がある。
この可能性は、注目をバイパスからポリシー設計へと移す。システムは文書化された承認ルールに従っていても、そのルールが広すぎるために、意外または安全でない結果を生むことがある。
Meta は、ユーザーが Muse にアクセスを許可する対象を選び、機密性の高い操作を承認するとしている。しかし、一見単純な一つの操作の背後で、エージェントが多くのファイル分類を黙って集約できるなら、同意の情報価値は低下する。
この問題は、よくあるマーケティング上の近道にも疑問を投げかける。ベンダーはしばしば、隔離されたエージェント用コンピューターがあればセキュリティ問題全体が解決するかのように説明する。実際には、エージェントはそのコンピューター内部でも最小権限を強制しなければならない。
最小権限とは、タスクに必要なファイル、コマンド、ネットワーク、認証情報だけを付与することを意味する。内部ツールで満たされた実行環境には広範なローカルアクセスが必要な場合もあるが、そのアクセスが無制限の開示を意味してはならない。
エンタープライズ購入者にとって、この区別はリスクレビューに影響する。セキュリティチームは、エージェントが何を読めるか、コンテンツがどう分類されるか、どの操作が再承認を引き起こすか、一括エクスポートが特別に扱われるかを問う必要がある。
専門のセキュリティ担当者がいない消費者も、同様の問題に直面する。Muse は、人々にメール、カレンダー、メッセージ、ショッピングアカウント、長期的な個人メモリの接続を促している。一括エクスポート機能は、その情報を持ち運び可能なオブジェクトに集約できる。
この事案は、James のアーカイブに他者の情報が含まれていたことを示すものではない。個人データ、エージェントデータ、プラットフォームデータの境界が、会話的な解釈ではなく明示的な強制を必要とする理由を示している。
最も重大な主張は依然として未検証
報告されたアーカイブは正当なセキュリティ上の疑問を生むが、この件を巡って広がるあらゆる劇的な結論を裏付けるものではない。
まず、独立した第三者は James の完全なアーカイブを公に監査していない。彼は、潜在的に機密性の高い資料を公開しないため、アーカイブ、SSH キー、セッションログを非公開にした。
この判断は責任あるものだが、検証には限界がある。外部の人々は、スクリーンショット、ファイル一覧、James の説明、Saunders の証言、The Verge による部分的な再現に頼る必要がある。
次に、SSH キーの存在だけでは、その価値は分からない。キーは期限切れ、制限付き、内部テスト用に生成されたもの、隔離された仮想マシンに限定されたもの、あるいは追加の制御なしには利用できないものである可能性がある。
James もこの不確実性を明確に認めている。彼はキーが Meta のシステムを解錠すると主張しておらず、それを示す公開済みの証拠もない。
第三に、未発表の統合に関する言及は、将来の製品を確立するものではない。設定ファイルには Slack や Dropbox を含むサービスへの言及があったとされ、別の文書では実験的な Meta Home Link デバイス統合が説明されていた。
このようなファイルは、プロトタイプ、中止されたテスト、足場となる実装、または計画中の機能を表している可能性がある。James は、Home Link が出荷されるかどうかを判断できなかったと述べた。
第四に、システムファイルはホストの侵害を証明しない。アプリケーションには標準ライブラリ、ユーティリティ、パッケージメタデータが必要なため、コンテナには完全なオペレーティングシステムイメージが含まれることが多い。
ユーザーはコンテナ内で root アクセスを持っているように見えても、その外部では非特権のままであり得る。Meta は Muse が明示的にその構成を使用すると説明している。
第五に、「プロンプトインジェクション」という呼称には注意が必要だ。通常、プロンプトインジェクションとは、外部コンテンツに埋め込まれた信頼できない指示が、ユーザーの十分な意図なしにエージェントを操作することを指す。
ここでは、開発者が自らのエージェントに直接ファイルのエクスポートを求めた。これは、古典的な間接インジェクション攻撃というより、ポリシー回避や一貫しない指示追従に近い。
それでも Saunders の批判は重要な弱点を示している。わずかな表現の変更で拒否を覆せるなら、その拒否は信頼できるセキュリティ境界ではない。ただし、用語が実証された挙動を先走るべきではない。
透明性と脆弱性にも違いがある。ユーザーが割り当てられた実行環境を検査できることは、監査、可搬性、信頼を支援し得る。開発者は、自身の指示や実行環境を明らかにするツールを重視することが多い。
リスクは、構造化されていない開示にある。内部文書、運用上の痕跡、キーファイル、個人のメモリが、明確な警告やフィルタリングなしに一つの未分類アーカイブになるべきではない。
Meta のバグ報奨金プログラムは、James の報告を「Not Applicable」と判定したとされる。James によれば、回答では考え得る理由が列挙され、セキュリティまたはプライバシーへの影響を示す証拠の提出が求められた。
この分類は、ユーザーが自分自身の隔離環境にしかアクセスしていなかったという Meta の主張と整合する。ただし、それは報奨金プログラムの外で製品変更に値する挙動かどうかを決めるものではない。
セキュリティプログラムでは、悪用可能な境界横断アクセスと、堅牢化の機会を分けることが多い。ある発見が報奨金の対象外であっても、分かりにくい承認モデルや不要な情報露出面を明らかにすることはある。
この出来事は、Muse がまだ新しい時期に起きた。Meta は9月8日、米国でモバイルデバイス、ウェブ、WhatsApp ベースのやり取りを通じてこのエージェントを導入した。
独立したローンチレポートは、Meta のセキュリティおよびプライバシーに関する位置づけを強調している。また、Muse をメール送信、旅行予約、より長期的なプロジェクト管理ができるエージェントとして説明した。
この文脈は、侵害を証明することなく事態の重要性を高める。Muse は、使い捨てのチャット内で質問に答えるだけのものではない。価値のある個人情報を含むサービス全体で、持続的に行動するよう設計されている。
したがって、ユーザーはこの事案を、すべての Muse アカウントが公開されている証拠として扱うべきではない。同時に、隔離だけでエージェントが読み取り可能な情報を承認済みの保存先へ移すことを防げると考えるべきでもない。
証拠は中間的な見方を支持している。公開されたテストでは封じ込め境界は維持されたように見える一方、開示境界は一貫性なく振る舞い、多くのユーザーが予想する以上の内部資料を露出させた。
Meta Muse ユーザーが次に注視すべきこと
次の段階は、Meta またはその批判者が「侵害」という言葉を巡る議論に勝つかどうかではなく、具体的な製品の挙動で判断すべきだ。
最初の兆候は、ファイルシステムアクセスにおける再現可能な変更だ。Meta は、利用可能な仮想マシン情報の量に調整が加えられる可能性があるとしている。研究者は、新しいセッションで保護ディレクトリに一貫したツール強制の制限が適用されるかを検証すべきだ。
強力な更新では、アーカイブする前にファイル分類を特定する。モデルの会話的判断に依存せず、認証情報、プラットフォームの指示、運用ログ、内部コードをブロックまたはマスキングするべきだ。
第二の兆候は、一括外部送信に対する Meta の扱いだ。Sentinel はすでにネットワークリクエストとコネクター操作を評価している。Meta は、アーカイブ作成と大容量ファイル転送が、内容、量、送信先、機密性に基づいて追加レビューを受けるかを明確にすべきだ。
有意義な承認では、何が仮想マシンから出るのかを説明する必要がある。そのファイルがシステムコンポーネント、個人メモリ、実行痕跡、キー素材の可能性を組み合わせている場合、「ファイルをアップロード」という表示では曖昧すぎる。
第三の兆候は、隔離に関する独立した検証だ。研究者には、エクスポートされた SSH キー、ソケット、実行時スクリプトが、割り当てられた環境を超えて何かに到達できるかを示す証拠が必要となる。
これらの成果物が一人のユーザーの仮想マシン内に閉じ込められたままであれば、Meta の限定的な反論はより強まる。いずれかの成果物がアカウントまたはインフラの境界を越えるなら、深刻度は大きく変わる。
Meta は所有権モデルもより明確にすべきだ。ユーザーは Muse の仮想マシンのどの部分を検査、エクスポート、削除、移行できるのかを知る必要がある。
このポリシーでは、ユーザードキュメントと Meta の専有的な実行環境資料を区別すべきだ。また、メモリ記録、会話トレース、生成されたアプリケーション、エージェント指示が、それらの分類にどう位置づくかも説明する必要がある。
開発者とエンタープライズ購入者も、すべてのパーソナルエージェントに同じ問いを適用すべきだ。モデルは何を読めるのか、そのツールは何をエクスポートできるのか、そしてどの制御がモデルから独立して機能するのか。
チャットボットの拒否を、その操作が不可能である証拠として頼るべきではない。拒否は、ある条件下で一つの応答が要求を断ったことを示すにすぎない。
機密性の高い導入では、コネクターには実用上もっとも狭い権限を付与する。読み取りと書き込みのアクセスを分離し、監査証跡を確認し、エクスポートの挙動が予測可能になるまで高価値アカウントの接続を避けるべきだ。
Meta Muse のファイルシステムエクスポートは、隔離が失敗した証拠ではない。これは、隔離がエージェントセキュリティの問題の一部にしか答えないことを示す証拠だ。
より重要な試験は、Meta が文書化したアーキテクチャを、通常の会話でも一貫性を保つ制御へ変換できるかどうかである。ユーザーは、より広範な個人またはビジネス上のアクセスを Muse に委ねる前に、その制御を注視すべきだ。
