MetaのMuseにファイルシステムを要求したら6.8GB送られてきた

MetaのMuseにファイルシステムを要求したら6.8GB送られてきた

この記事では

1. エクスポート
2. 報告内容
3. ランタイムとそのマニュアル
4. スキルとインテグレーション
5. コンテナセットアップ
6. スペースとファイルビルダー
7. イメージ内のCodex
8. メモリとスケジューリングされたワーク
9. Home Link
10. 開示と応答

エクスポート

Museに、見えるファイルをアーカイブしてGoogle Driveに送るように依頼しました。それは実行されました。

ダウンロードサイズは約2.7GB（圧縮時）で、展開後は6.8GBでした。これには、セッションに割り当てられたLinux環境のルートファイルシステム、Ubuntuシステムファイル、Museの内部ドキュメント、統合コード、アプリテンプレート、メモリファイル、エージェントログなどが含まれているようでした。SSHキーファイルも含まれていました。

[図: Museは、コード、ドキュメント、メモリ、バイナリの以前のエクスポートについて説明しています。ここでのファイル数とサイズはチャットでの主張であり、その以前のエクスポートを参照しています。画像をクリックすると拡大します。]

[図: Museの配信メッセージはmuse-full-root.zipへのリンクを含み、サイズを2.86GBと呼んでいます。私のメモは約2.7GB（圧縮時）を記録していますが、両方の数値を照合していません。上のメッセージはコンテナエスケープに関する検証されていない主張をしています。私はエスケープを実証しませんでした。画像をクリックすると拡大します。]

報告内容

これらの発見をMetaのバグバウンティプログラムを通じて提出し、数人の従業員に連絡しました。アーカイブ、キー、セッションログは公開しません。これは、私が発見したことと、そこから確立できたことの内訳です。

私が報告した懸念は、内部ランタイムファイルや機密性の高い資料が、通常の会話と接続されたエクスポート先を通じてその環境から流出する可能性があるということでした。SSHキーがアクティブであったかどうか、およびそれらがどのようなアクセスを提供できたかは確立していません。

ランタイムとそのマニュアル

興味深いファイルのほとんどは /home/hatch、/opt/hatch、/opt/hatch-image の下にありました。HatchはMetaがMuseに使用する内部名であり、ランタイムファイル全体で使用されている名前です。

/

`agents/`

agents/ ディレクトリには、JSONLトレースを持つ113個のサブエージェントレコードが含まれていました。

エージェントのホームディレクトリには SOUL.md、IDENTITY.md、USER.md、MEMORY.md、AGENTS.md、TOOLS.md が含まれていました。それらと並んで、ドキュメント、メモリ、ワークスペースプロジェクト、チャネル、フック、サブスクリプション用のディレクトリがありました。agents/ ディレクトリには、JSONLトレースを持つ113個のサブエージェントレコードが含まれていました。

ドキュメントは、システムを理解する上で非常に役立ちました。約20個のMarkdownファイルが、ブラウザの使用、コネクタ、支払い、認証情報、データ処理、生成されたファイル、音声、目標、スケジューリングについて説明していました。WhatsApp、ペアリングされたMac、Tailscale、およびHome Linkと呼ばれるデバイス統合用の個別のガイドがありました。

[図: muse.mdの冒頭は、ユーザーごとの永続的なエージェントコンピュータについて説明し、製品の他のガイドを指しています。これらはエクスポートされたドキュメントの記述です。画像をクリックすると拡大します。]

スキルとインテグレーション

/opt/hatch/skills/ の下で、約68個のスキルディレクトリを数えました。これらは一般的に、SKILL.md 命令ファイルとコマンドラインツールまたはサポートコードをペアにしていました。これらはGoogle Workspace、Metaのソーシャルアプリ、Outlook、旅行、ショッピング、ヘルスサービス、ホームデバイス、メディア生成をカバーしていました。

[図: SKILL.mdファイルの例：share_ideasは、エージェントがいつそれを使用すべきかを指定し、公開ページにパッケージ化されたINSTALL.mdファイルについて説明しています。画像をクリックすると拡大します。]

2つの設定ファイル、skill-scopes.conf と bin-scopes.conf は、Metaがパイプラインに持っている未発表のコネクタを示唆していました。これらには、Slack、Dropbox、Polymarket、Canva、Klaviyoなどの名前と、内部の internal-facebook-cLI が含まれていました。

コンテナセットアップ

コンテナセットアップも含まれていました。/opt/hatch/runtime-cell/ には18個のファイルが含まれており、ルートファイルシステムをビルドし、systemd-nspawn で起動し、スタートアップフックとデーモンを実行するためのスクリプトが含まれていました。別の runtime-cell.kdl マニフェストは、イメージ内のパッケージとsystemdユニットを記述していました。

これらのファイルにより、割り当てられたLinux環境がどのように組み立てられたかをかなり明確に把握できました。しかし、サービス全体を監査したり、その環境外のインフラストラクチャについて何かを証明したりするには十分ではありませんでした。

スペースとファイルビルダー

見つかった最大のコードプロジェクトはSpacesフレームワークで、Museがアプリをビルドおよび提供するために使用しています。そのTypeScriptスターターには、Reactクライアント、サーバーアクション、Drizzle SQLiteスキーマ、SQLマイグレーション、Bun設定が含まれていました。ディレクトリ worker、sdk、cloudflare、cvm には、より小さな静的テンプレートとランタイムコードがありました。

[図: Spacesディレクトリには、テンプレートとTypeScriptランタイムが含まれており、worker、sdk、cloudflare、cvmフォルダが含まれています。ディレクトリリストは構造を示しており、完全な実装ではありません。画像をクリックすると拡大します。]

エクスポートには、ドキュメント、PDF、プレゼンテーション、スプレッドシート、Markdownのビルダーも含まれていました。別の magic-moment スキルには、カードやビデオを作成するためのコード、ブラウザキャプチャスクリプト、フォント、ブランドアセットが含まれていました。

そして、たくさんのアイコンがありました！

[図: エクスポートされたファイルに含まれるWebPアイコンの選択。画像をクリックすると拡大します。]

イメージ内のCodex

Codex CLIは /opt/hatch-image/bin/codex にインストールされており、バージョン 0.149.0 を報告しました。Museがそれをコーディングエージェントとして使用している証拠は見つかりませんでした。

Hatchは、Linuxサンドボックスツールである bubblewrap のバンドルコピーを使用しています。バイナリは codex-resources/bwrap の下にあり、Codexのためにビルドされたbubblewrap として識別されます。

Museは、ビデオ処理、サムネイル生成、ファイル検査のために ffmpeg と ffprobe をサンドボックス化するためにそれを使用します。これらのジョブは、ネットワークアクセスや追加の権限なしに、ユーザー nobody として実行され、サンドボックスに公開された /input および /output ディレクトリを使用します。bubblewrap が欠落している場合、failed to prepare ffmpeg sandbox というエラーで失敗します。

Codex自体を呼び出すコードは見つかりませんでした。一時的なCodexファイルはバージョンチェックから来ており、Hatchバイナリ内の codex および gpt-5.5 文字列はプロバイダーリストのエントリであり、エクスポートにはそれらが選択されていることを示すものは何もありませんでした。

私が確立できた限りでは、MetaはCodex CLIを配布しましたが、バンドルされたサンドボックスのみを使用しています。

メモリとスケジューリングされたワーク

MuseはメモリをプレーンなMarkdownファイルに保存します。~/MEMORY.md は、事実、好み、コミットメントの短いシートです。~/memory/ の下の日付付きファイルは、日々の詳細を記録します。エージェントは会話中にこれらに書き込むことができます。

毎時実行されるバックグラウンドジョブが、新しい主張を元のメッセージと比較してチェックし、引用、メッセージID、主張IDを記録します。これは、キュレートされたシートに何を含めるべきか、何が日次ログに残るかを決定します。memory/bank/ の下のファイルは、その資料を状況、経験、好みに整理し、ソース行への引用を付けます。Postgresはこれらのファイルを検索可能にします。memory.entries はチャンクと行参照を格納し、memory.embeddings は384次元ベクトルを保持し、memory.claims は証拠、信頼度、ステータスを追跡します。新しい主張は supersedes_claim_id を通じて古い主張を置き換えることができます。エージェントは memory_search でストアを検索し、結果の背後にある証拠を memory_explain で検査できます。

他のバックグラウンドジョブは、関係ページを維持し、定期的なワークフローをレビューし、アイデアや目標の概要を準備します。これらの実行は workspace/self_improvement/ の下に領収書を残し、実際の変更は関連するメモリおよびワークスペースファイルに入力されます。

毎晩の「ドリーム」は最近の会話をレビューし、将来のセッションのためのガイダンスを記述します。私のドリームでは、短い返信を好み、繰り返しのフォローアップを嫌い、自発的なNFLスコアを求めていなかったことが拾われました。日付付きのドリームは ~/dreams/ の下にあり、別の ALIGNMENT_SYNTHESIS.md がそれらの観察を定常的なガイダンスに変換します。ドリームファイルには prompt_hoisted: false とあったため、プロンプト自体に文章が注入されていたわけではありません。

[図: 9月21日のドリームエントリは、私のコミュニケーションスタイルと好みを説明しています。スクリーンショットには、そのdream_pathとsynthesisメタデータが含まれています。それは書かれたメモリレコードを示しています。画像をクリックすると拡大します。]

忘却はノートを削除することを超えています。忘却ワークフローは、取り消しのために主張IDをステージングし、リンクされた資料を削除し、インデックスを再構築して、後続のジョブがそれを再構築しないようにします。これがシステムが時間とともに適応する方法です：ファイル、検索可能なレコード、および将来のセッションが読み取れる指示を更新することによって。モデルの重みは変更されません。

Home Link

ハードウェアドキュメントは最大の驚きでした。docs/devices/home_link.md は、Wi-FiとBluetooth LEを備えたESP32-C5を使用した、Meta Home Linkという実験的な統合について説明していました。デバイスペアリング、ローカルネットワーク検出、および個別の承認ステップを持つプロキシを介したエージェントアクセスをカバーしていました。IPP経由のBrotherプリンターやLutronブリッジ用の統合ガイドはすでに存在していました。

[図: Home Linkガイドは、この統合を実験的と呼び、最初のセットアップのためにESP32-C5ハードウェア、Wi-Fi、およびBLEをリストしています。画像をクリックすると拡大します。]

これは、Museがホームネットワーク上のデバイスにアクセスできるようにするための作業を示唆しています。それが内部プロトタイプであったのか、限定的な実験であったのか、それともMetaが出荷を計画しているものであったのかは不明です。

開示と応答

Metaのバグバウンティプログラムを使用してレポートと発見を提出しました。Metaはレポートを「Not Applicable」（該当なし）とマークしました。数人の従業員にも連絡を取り、応答を得ました。

[図: Metaはレポートを「Not Applicable」とマークしました。返信には、その決定のいくつかの可能な根拠がリストされていますが、どれが適用されたかは特定されていません。セキュリティまたはプライバシーへの影響に関する追加証拠を求めています。画像をクリックすると拡大します。]

Museをエスケープさせるためにコンテナ境界を軽くプローブしましたが、私のテストでは保持されているようでした。見つかった80個のソケットに圧力をかけ始めましたが、本番システムの性質と、正直に言ってこの分野での私の経験不足のため、中止しました。

さらに情報が必要な場合は、私に連絡してください。pete at mouse.dev

-Pete

@heypeterjames

[図: スクリーンショット]