Meta Museファイルシステムエクスポートにより、6.8 GBの内部ランタイムファイルが明らかに

TL;DR – 何が起きたのか、なぜ重要なのか

MetaのMuseエージェントに、自身が閲覧できるファイルをアーカイブしてGoogle Driveに送信するよう依頼したところ、6.8 GBの展開済みZIPファイルが得られました。このファイルには、Museを実行しているLinuxコンテナの完全なルートファイルシステムが含まれており、内部ドキュメント、統合コード、Spacesアプリフレームワーク、メモリファイル、コンテナ起動スクリプト、実験的なESP32ベースのHome Linkガイドが含まれていました。この暴露は、会話形式のリクエストによって機密のランタイムアーティファクトが漏洩する可能性があることを示しており、Metaが報告を「該当しない」と分類したにもかかわらず、プライバシーとセキュリティ上の懸念を引き起こしています。


エクスポート – 完全なコンテナスナップショット

  • Museは「あなたが閲覧できるファイルをアーカイブして」というリクエストに従い、muse‑full‑root.zipという名前のZIPを提供しました。
  • 圧縮時は約2.7 GB、展開時は約6.8 GBで、チャットメッセージに表示されたサイズと一致しています。
  • 展開されたファイルツリーはコンテナのルート(/)を再現しており、以下を含んでいます:
    • 標準的なUbuntuインストールを含むシステムディレクトリ(/etc、/usr、/var)。
    • Museの内部コード名である/home/hatch、/opt/hatch、/opt/hatch-image配下のアプリケーション固有のパス。
    • 113個のサブエージェントJSONLトレースと複数のMarkdownファイル(SOUL.md、IDENTITY.md、USER.md、MEMORY.md、AGENTS.md、TOOLS.md)を含むagents/ディレクトリ。
    • ブラウザの使用、コネクタ、決済、資格情報、データ処理、音声、目標、スケジューリングに関する説明を含む約20個のMarkdown形式のドキュメントファイル。
    • SSH鍵ファイル(その有効性は確認されていません)。

"私はMuseに、自分のセッションで閲覧可能なファイルシステムをアーカイブしてGoogle Driveに送信するように依頼しました。結果として6.8 GBほど展開されたアーカイブが届きました。中には内部ドキュメント、統合コード、Spacesアプリフレームワーク、メモリ記録、コンテナ起動スクリプト、そしてHome Linkと呼ばれる実験的なESP32ベースの家庭ネットワークブリッジのドキュメントがありました。" — Pete、Mouseブログ投稿

報告された内容 – セキュリティの観点

  • 核心的な懸念:通常の会話 + エクスポート先が内部ランタイムファイル、さらには機密情報の漏洩を引き起こす可能性がある。
  • 研究者はコンテナの脱出を実証したわけではなく、抽出されたSSH鍵が有効であることも確認していない。
  • この報告はMetaのバグバウンティプログラムを通じて提出され、**「該当しない」**とマークされた。
  • Metaの対応では、決定の根拠として可能性のある理由を列挙したが、どの理由が適用されたかは明示されていない。追加の証拠の提示を呼びかけている。

"報告された問題は有効な脆弱性とは認められません…なぜなら、記載された挙動は意図した通りに動作しているためです。" — Metaバグバウンティの返信(投稿内で引用)

ランタイム構成 – 重要なファイルの位置

  • /home/hatch および /opt/hatch* に、Muse固有のアーティファクトの大部分が存在する。
  • エージェントディレクトリ – ユーザーごとのエージェント状態と、多数のJSONLログを保持。
  • ドキュメント – 20個以上のMarkdownファイルが、内部API、決済処理、音声パイプライン、デバイス統合について非常に詳細に記述している。
  • スキル – /opt/hatch/skills/配下には約68のスキルディレクトリがあり、それぞれがSKILL.mdとCLIツールまたはライブラリをペアにしている。例:Google Workspace、Outlook、旅行、ショッピング、健康サービス、ホームオートメーションコネクタなど。
  • 設定ファイル – skill‑scopes.confとbin‑scopes.confには、Slack、Dropbox、Polymarket、Canva、Klaviyo、および内部Facebook CLIなど、リリース前のコネクタがリストアップされている。

コンテナ構築 – VMの構築方法

  • フォルダ /opt/hatch/runtime-cell/ には、ルートファイルシステムの構築用スクリプト、systemd‑nspawnによる起動、およびフック/デーモンの初期化用の18ファイルが含まれている。
  • マニフェストファイル runtime-cell.kdl は、イメージを構成するDebian/Ubuntuパッケージとsystemdユニットを列挙している。
  • これらのファイルはコンテナの構築プロセスを明確に示しているが、Metaの広範なインフラストラクチャを暴露するものではない。

Spacesフレームワーク – アプリ構築エンジン

  • エクスポート内で最大のコードベースはSpacesフレームワークであり、TypeScriptのスターターキットとして以下の機能を含む:
    • Reactクライアント。
    • サーバーサイドアクション。
    • マイグレーション付きのDrizzle SQLiteスキーマ。
    • ビルド用のBun設定。
  • さらに、worker、sdk、cloudflare、cvmなどのサブフォルダには、さまざまなデプロイ先向けのランタイムコードが含まれている。
  • PDF、プレゼンテーション、スプレッドシート、Markdownのビルド用ツールも存在し、magic‑momentスキルではカードや動画を組み立てる機能がある。

Codex CLI – ありながら未使用

  • バイナリ /opt/hatch-image/bin/codex はバージョン 0.149.0 を報告している。
  • MuseがCodexをコーディングエージェントとして呼び出している証拠は見つからず、このバイナリは単にサンドボックスツールであるbubblewrapをバンドルするためだけに存在している。
  • bubblewrapは、ffmpeg/ffprobeのビデオ処理をサンドボックス化するために使用され、nobodyユーザーとして実行され、/inputと/outputのみが公開される。

メモリアーキテクチャ – プレーンテキストのMarkdownとPostgresインデックス

  • Museはユーザーが閲覧可能なメモリをプレーンテキストのMarkdownファイルに保存している:
    • ~/MEMORY.md – 短い事実シート。
    • ~/memory/ – 日付付きの日次ログ。
    • ~/memory/bank/ – 情報、経験、好みなどのカテゴリに整理され、引用が付与されている。
  • バックグラウンドジョブは新しい主張を解析し、PostgreSQLデータベースに保存し、以下を維持している:
    • memory.entries – 行参照付きのテキストチャンク。
    • memory.embeddings – 同一性検索用の384次元ベクトル。
    • memory.claims – 証拠、信頼度、ステータスフィールドを保持し、supersedes_claim_idによる上書きをサポート。
  • 毎晩実行される「夢」ジョブは、最近の会話パターンを合成してガイダンスファイル(~/dreams/、ALIGNMENT_SYNTHESIS.md)を作成する。生成されたプロンプトは直接LLMプロンプトに注入されない(prompt_hoisted: false)。

"Postgresによりこれらのファイルを検索可能にしています。memory.entriesはチャンクと行参照を保存し、memory.embeddingsは384次元ベクトルを保持し、memory.claimsは証拠、信頼度、ステータスを追跡します。" — Mouseブログ投稿

Home Link – 実験的なハードウェア統合

  • docs/devices/home_link.mdドキュメントは、ESP32‑C5ベースのブリッジについて記述しており、Wi‑FiおよびBluetooth LEを介してMuseを家庭ネットワークに接続する。
  • 設定ガイドにはデバイスペアリング、ローカルネットワークの検出、プロキシベースの承認フローが含まれる。
  • Brotherプリンタ(IPP)およびLutronブリッジ用の追加統合ガイドも存在し、より広範なホームオートメーションロードマップを示している。

"Home Linkガイドはこの統合が実験的であると明記しており、初回セットアップにはESP32‑C5ハードウェア、Wi‑Fi、BLEがリストアップされています。" — Mouseブログ投稿

コミュニティの反応 – 情報の深刻度について意見が分かれている

  • 一部のコメントでは、この暴露は当然の結果だと見なされている。なぜなら各ユーザーが専用のVMを実行しているからである:

    "各ユーザーには専用VMが割り当てられます。彼らが自分のサンドボックスの内容を得ただけです。大したことはありません。ここでの興奮はまったく比例していません。" – ostensible

  • 他の人々は、この挙動はバグではなく機能だと主張し、エージェント開発のためのオープン性を強調している:

    "これはバグではなく機能のように見えます。エージェントは、開発者が自分のコンピュータに完全アクセスできるのと同じように、自分のコンピュータに完全アクセスできるのが最適です。" – nzoschke

  • 反復的な批判として、Metaのバグバウンティの判断が挙げられている:

    "本気で、システム全体の内容をエクスポートするという行為に対してバグバウンティが適用されないんですか?" – rwmj

  • 一部は、Home Link統合の実験的性質と、リリース前のスキルスコープの存在に注目している。

AIエージェントセキュリティにおけるこの問題の重要性

  1. チャットによるデータエクスポート – エージェントに、その全ランタイムをパッケージ化・送信するように指示することで、内部コード、ドキュメント、さらには資格情報の漏洩が可能になる。
  2. 内部ドキュメントの可視性 – エクスポートされたMarkdownファイルは、外部者がMetaのエージェントアーキテクチャ、統合ポイント、将来のロードマップを詳細に把握する手がかりを与える。
  3. 権限昇格の可能性 – サンドボックス脱出は実証されていないものの、コンテナ内にSSH鍵やルートレベルのツールが存在するという事実は、攻撃者がコード実行を獲得した場合のリスクを高める。
  4. ポリシーへの影響 – 「意図した通りに動作している」と分類されたことは、Metaが意図的に完全なファイルシステムエクスポートを許容している可能性を示唆しており、マルチテナントAIサービスにおける一般的なセキュリティベストプラクティスと矛盾する。

結論:Museのエクスポートは、ファイルシステムアクセスを持つ会話型エージェントが、意図せず大規模なデータ漏洩の経路になり得ることを示している。コンテナがユーザーごとに隔離されているとしても、追加の保護措置なしに内部ドキュメント、コード、鍵を送信できるという事実は、開発者およびプラットフォーム運用者にとって深く検討すべき重要なプライバシーリスクである。

Sources

関連

  • プロジェクト
  • Dispatch
  • Dispatch
  • Dispatch
  • Dispatch