Meta Museのファイルシステムアクセス、従来の警告にもかかわらず機能として提供へ

Metaは、およそ1日のうちにMeta Museのファイルシステムアクセスを、明らかなセキュリティ上の懸念から明示的にサポートされる機能へと転換した。ユーザーは現在、エージェントのクラウドコンピューターを閲覧し、ルートレベルのディレクトリを確認し、Museにファイルをダウンロード用にパッケージ化するよう依頼できる。

この方針転換は、Museが内部ランタイム、メモリーシステム、統合機能、未公開の実験を記録しているように見えるファイルをエクスポートしたとの報告を受けて起きた。Museは当初、一部のユーザーに対し、完全なコピーを提供すればセキュリティリスクになると伝えていた。その後Meta幹部は、各ユーザーの仮想マシンはそのユーザーに帰属するため、このアクセスは意図的なものだと述べた。

この区別は重要だ。Museは単なるチャットインターフェースではない。ブラウザー、ストレージ、コネクター、スケジュールされた作業、ユーザー固有のメモリーを備えたクラウドコンピューター内で動作する永続的なエージェントである。Metaは、そのコンピューターを利用しやすく感じさせつつ、周辺インフラへのアクセスは可能にしないことを目指している。

その結果、これはAIエージェント市場全体にとって有用な試金石となる。エージェントがファイルや接続済みサービスを操作する場合、ユーザー所有権には実質的なアクセスが必要だ。しかし同じアクセスにより、製品の内部情報、機密記録、あるいは攻撃者が研究できる経路が露出する可能性もある。

Meta Museのファイルシステムアクセスは一夜で容易になった

直近の変化はファイルシステムの存在そのものではなく、Metaがそれを製品の通常の一部として公開する決定をしたことにある。

9月24日、開発者のPeter JamesとJonny L. Saundersは、それぞれ独立してMuseから広範なファイルシステム資料を取得したと説明した。Jamesは、Museが閲覧できるすべてのファイルをアーカイブし、Google Drive経由で送るようエージェントに依頼した。

Museはこれに応じた。Jamesによれば、ダウンロード容量は圧縮時で約2.7GB、展開後で6.8GBだった。彼のランタイムエクスポートには、OSファイル、内部文書、アプリケーションテンプレート、メモリー記録、統合コード、ログ、SSH鍵ファイルが含まれていたようだ。

Jamesはアーカイブ、セッションログ、鍵を公開していない。また、コンテナエスケープや他ユーザーのデータへのアクセスを実証したわけではないことも強調した。SSH鍵が有効なままか、何にアクセスできるかについても確認できなかった。

こうした留保は、異例の情報開示と確認済みのインフラ侵害を区別するものだ。エクスポートされた資料はJamesに割り当てられたLinux環境から来ている。別の顧客のワークスペースが含まれていた、あるいはMetaのホストシステムを制御できたことを示す公的証拠はない。

それでも、Museの応答は混乱を招いた。報道によれば、エージェントは完全なファイルシステムの提供を求める一部の要求を拒否し、そのようなエクスポートは危険だと説明した。過去のエクスポートの例を受け取った後も、完全なルートコピーを提供すべきではないと述べ続けた。

翌日、インターフェースは異なる挙動を示した。ファイルシステム更新によると、Museはルートレベルのディレクトリにアクセスできるクリック可能なファイルブラウザーを提供し始めた。また、求められればファイルシステムをパッケージ化するようにもなった。

Meta Superintelligence Labsの責任者Nat Friedmanは、これを「意図された挙動」と呼んだ。Meta幹部のDavid Singletonは、ユーザーはMuseをクラウド上の自分自身のLinuxコンピューターとして見るべきだと述べた。

この説明はMetaが公開したアーキテクチャと整合する。各Museユーザーには、会話の間も維持される専用仮想マシン、すなわちVMが割り当てられる。エージェントはそこでコードを書き、ツールを構築し、スケジュールされたタスクを実行し、ファイルを維持できる。

Metaは以前から、ユーザーがVMに保存されたファイルを検査、編集、ダウンロードできるとしていた。この約束には、Museがユーザーについて保持するメモリーも含まれる。その意味では、エクスポートが注目を集める前からファイルアクセスは文書化されていた。

それでもこの変化は重要だ。実装こそが、ユーザーが実際に何を制御できるかを決めるからである。ユーザーが自分のファイルを所有するという方針は、製品が通常のアクセス要求を拒む場合には弱い。新しいブラウザーは、その所有権を可視化し、実用的なものにする。

この出来事は、エージェントの表現とMetaの意図した方針との不一致も示している。Museは許可された行為を、禁止されたセキュリティリスクとして説明した。その後、同社は同じ行為を意図的な設計判断として公に位置付けた。

この食い違いは、セキュリティ上の失敗を証明するものではない。ただし、AIエージェントが運営者の立場と矛盾する権威的な説明を提示しうることは示している。ユーザーにとって、実際にはそうでなくても、製品による拒否は方針のように聞こえた。

したがって、Meta Museのファイルシステムアクセスをめぐる話は、立証済みの侵害ではなく、製品修正から始まる。Metaはインターフェースを、自らの所有権に関する主張により近づけた。その結果、エージェントコンピューターの内容ははるかに調べやすくなった。

Museの最初の回答が機能を漏えいのように見せた理由

Metaの所有権に関する主張には一貫性があるが、Museの矛盾した挙動により、意図された機能が偶発的なものに見えた。

Metaは9月8日、成人向けの個人AIエージェントとして米国でMuseを公開した。同社はMuseを、単に質問に答えるのではなく、ウェブサイトや接続済みサービスをまたいで行動できるソフトウェアとして位置付けた。

そのローンチ詳細では、ブラウザーを備えた永続的な仮想コンピューターが説明されている。Museはフォーム入力、メール送信、旅行予約、文書作成、購入を行い、ユーザーがアプリケーションを閉じた後も作業を続けられる。

この設計にはストレージが必要だ。長期にわたるタスクには、ファイル、計画、ログ、作業文書、生成されたコード、記憶されたコンテキストが必要になる。同等の情報を別の場所に保存せずに、ステートレスなチャットウィンドウが同じ継続性を提供することはできない。

Metaは仮想コンピューターをMuseの製品アイデンティティの一部にすることを選んだ。ユーザーはそのワークスペースを、目に見えないバックエンドデータベースとして扱うべきではない。自分のコンピューターとして扱うことが想定されている。

当初のエクスポートは、個人的な文書以上のものを含むように見えたため、この説明に疑問を投げかけた。Jamesは、内部指示、統合コード、ランタイムスクリプト、システムバイナリー、製品マニュアル、未発表実験への参照が含まれていたと報告した。

彼の報告では、約68のパッケージ化されたスキルと、約20の内部Markdownガイドを含むディレクトリが特定された。あるディレクトリには、彼の環境からの113件のサブエージェントトレース記録が格納されていた。別のディレクトリには、ランタイムの構築と起動に関連する18ファイルが含まれていた。

これらの数字は、すべてのMuseインスタンスを独立して監査した結果ではなく、1人の研究者による検査に基づくものだ。Metaは、すべてのユーザーが同一のイメージやディレクトリ内容を受け取るかどうかを公に確認していない。

エージェントの拒否は、これらの発見をより機密性の高いものに感じさせた。ユーザーが常に環境を検査できることが想定されていたなら、Museは完全なコピーを禁止されていると説明すべきではなかった。インターフェースも、ローンチ時からファイルアクセスを明確に示すべきだった。

ところが当初、この経路には会話を通じた説得が必要だった。そのため、境界自体は開かれるべきものだったとしても、通常のアクセスがプロンプトを用いた回避のように見えた。

Metaの回答は、この見方を変えた。ユーザーが自分に割り当てられたランタイムをダウンロードすることは、借りたクラウドコンピューター上のファイルを検査することに相当する。意味のあるセキュリティ境界は、そのランタイムと保護されたホスト側サービスの間にある。

この立場は、MetaがJamesのバグ報奨金レポートを対象外とした理由を説明する。彼のレポートは、Metaが保護しているとする境界をエクスポートが越えたことを示していない。Museがユーザー自身の環境からファイルを移動できたことを示したにとどまる。

ただし、「意図されたもの」という説明だけですべての懸念が解消するわけではない。製品の意図と安全な実装は別の問題だ。Metaはユーザーがランタイムを制御することを意図しつつも、不適切な資料を誤ってその中に置く可能性がある。

クラウドプロバイダーは、顧客にインスタンスに対する管理者権限を与える場合がある。だからといって、機密性の高い本番認証情報、独自のインフラ秘密情報、再利用可能な鍵を、そのインスタンス内にパッケージすべきということにはならない。

JamesはSSH鍵ファイルを発見したが、それらが機能するかどうかは確認していない。内部文書も見つけたが、文書だけで特権アクセスが得られるわけではない。これらの詳細は、侵害の証拠として提示することなく、調査に値する。

もう一つ混乱の要因がある。JamesはUbuntuのシステムファイルについて説明した一方、Metaの技術文書ではランタイムは完全なDebianイメージを備えるとされている。この違いは、レイヤー、用語、あるいはエクスポートからの誤った推論を反映している可能性がある。

これは、ファイルシステムの観察には慎重な解釈が必要であることを示している。ディレクトリ名、バイナリー、設定ファイルは、コンポーネントの存在を示す場合がある。しかし、それらが本番サービスでどのように使われているかを証明することは、ほとんどない。

そのためMetaは、二つの異なる問いに答える必要がある。第一に、ユーザーは割り当てられたランタイム内のすべてを安全に検査・エクスポートできるのか。第二に、Metaはエクスポート時にリスクを生むものがランタイムに含まれないようにしているのか。

新しいブラウザーは、製品設計を通じて最初の問いに答えている。二つ目には、継続的な技術テスト、より明確な文書化、そして隔離境界が維持されていることを示す証拠が必要だ。

ユーザー所有権とエージェントのセキュリティは相反する方向に引っ張られる

中心的な対立は公開性と秘密性ではなく、ユーザーの制御と自律エージェントに求められる封じ込めの間にある。

個人向けエージェントはコンテキストを蓄積することで有用になる。好みを学び、約束を追跡し、ファイルにアクセスし、サービスを横断して作業する。こうした機能により、そのワークスペースは個人のデジタル生活に関する詳細な記録となる。

Metaによると、Museはユーザーファイルと生成された資料を専用VM内に保存する。また、認証情報と認可トークンは、メインエージェントが直接読み取れない別の隔離領域で管理する。

同社のセキュリティアーキテクチャは、VMを二つのセキュリティドメインに分割している。Museのランタイムは、制限されたOS環境を実行するためのLinux隔離機構であるsystemd-nspawnコンテナ内で動作する。

そのランタイム内のルートアクセスは、ホストのroot権限と同じではない。Metaによると、コンテナのrootユーザーは非特権のホストアカウントにマッピングされる。ランタイムには限定的なカーネル機能と、フィルタリングされたシステムコールも付与される。

セキュリティに敏感なコンポーネントはランタイムの外部で動作する。これには、認証情報サービス、コネクターワーカー、安全性分類器、永続的なアプリケーション状態、Sentinelと呼ばれる別個の権限システムが含まれる。

Sentinelはコネクターのアクションとネットワーク要求を評価する。Museはアクションを提案できるが、許可、ブロック、またはユーザー承認の要求を決めるのはSentinelだ。

Metaはまた、実際の認証情報はネットワーク境界でのみ挿入されるとしている。ランタイム内のコードは、基盤となる秘密情報の代わりに代理トークンを受け取る。正しく実装されていれば、エクスポートされたファイルから再利用可能なコネクター認証情報が明らかになるべきではない。

このアーキテクチャは、ランタイム自体が信頼できない資料を処理することを前提としている。ウェブサイト、メール、文書、メッセージには、エージェントを操作する目的で設計されたテキストが含まれる可能性がある。セキュリティエンジニアは、このリスクをプロンプトインジェクションと呼ぶ。

したがって、保護された境界は、エージェントが誤った挙動をした場合でも維持されなければならない。Museにファイルを公開しないよう伝えることは、そのファイルにホストの秘密情報が含まれない、あるいは禁止された宛先に到達できないことを保証するよりも弱い。

ファイルシステムの可視性は、そのようなアーキテクチャを支えうる。研究者はエージェントが保存する情報を調査でき、ユーザーはエージェントが何を記憶しているかを確認できる。透明性によって、過剰な保持、意外な指示、説明のないバックグラウンドプロセスが明らかになる可能性がある。

ユーザーには削除や修正の仕組みも必要だ。パーソナルエージェントは、不正確な発言を永続的な記憶に変えてしまうおそれがある。直接アクセスがあれば、ユーザーはその記録を見つけ、編集し、削除できる。

これは知識システムにとって特に重要である。信頼できるパーソナルナレッジベースは、どの情報が保存され、後の回答にどのような影響を与えるのかを人々が理解できるようにすべきだ。

一方で、アクセス範囲が広がるほど、アカウント侵害の影響も大きくなる。Museのセッションを乗っ取った攻撃者は、ファイル、ログ、メモリ、生成物を含む便利なアーカイブを要求できるかもしれない。使いやすいエクスポート機能が、その窃取を加速させる可能性がある。

悪意あるウェブページも別の懸念をもたらす。プロンプトインジェクションによってMuseがローカルデータを収集し外部へ送信するよう誘導された場合、Sentinelはそのデータフローを認識し、適切な承認を求める必要がある。

Metaによれば、プロセスがユーザーデータを読み取ったかどうかを追跡している。そのようなプロセスは汚染済みと見なされ、簡略化されたネットワーク承認へのアクセスを失う。より厳格な権限フローに戻らなければならない。

これは意味のある制御策だが、Metaはプロンプトインジェクションが依然として業界全体の未解決問題であることを認めている。同社はMuseが誤りを犯すとも述べている。ファイルシステムへのアクセスは、周辺の制御策の重要性を高める。

権限インターフェースは、何がVMから出ていくのか、どこへ送られるのか、なぜ必要なのかを説明しなければならない。アーカイブにエージェントとの完全な履歴が含まれることを理解していないユーザーを、一般的な承認リクエストで守ることはできない。

規模の問題もある。ユーザーは繰り返されるプロンプトを反射的に承認しがちだ。継続的に動作するよう設計されたエージェントが、低リスクな操作のたびに確認を求めれば、すぐに煩わしいものになる。

Metaは、スコープを限定した権限とリスク分類によってこの問題の解決を試みている。ファイルシステムをめぐる今回の出来事は、そうした判断が可視のままでなければならない理由を示している。ユーザーは、無害なファイル閲覧と一括エクスポートを区別できる必要がある。

同じ緊張関係は、OpenAI、Google、Anthropic、そして小規模なエージェント開発企業にも影響する。コンピューターを操作するエージェントには、いずれもワークスペースが必要になる。そのワークスペースはエージェントにとって有用で、ユーザーが管理でき、提供事業者から隔離されていなければならない。

隠せば説明責任の問題が生じる。公開すれば新たな攻撃経路が生まれる。勝つための設計には、透明性と強制可能な境界の両方が必要となる。

エクスポートが明らかにすること、証明しないこと

エクスポートされたファイルは貴重なプロダクトマップを提供するが、MuseやMetaのインフラを完全に監査したものではない。

Jamesによれば、MuseのホームディレクトリにはSOUL.md、IDENTITY.md、USER.md、MEMORY.md、AGENTS.md、TOOLS.mdという名前のファイルが含まれていた。これらのファイルは、動作、ユーザーコンテキスト、運用指示、利用可能な機能を定義しているように見える。

この構造は、Museが単一のモデルというより、組み合わされたソフトウェアシステムであることを示している。言語モデルは、スクリプト、データベース、スケジュールされたジョブ、コネクター、権限サービス、従来型のアプリケーションコードと連携して動作する。

これは現代のAIエージェントでは一般的だ。モデルが判断やテキストを生成する一方、決定論的なソフトウェアが認証、ストレージ、ネットワーキング、ユーザーインターフェース、専門的なタスクを担う。

Museは重要な記憶をプレーンなMarkdownで保存していると報じられている。短いメモリファイルには事実、好み、約束事が含まれ、日付付きのファイルにはより詳細な活動記録が保存される。データベースにより、これらの記録は検索可能になる。

Jamesは、主張を元のメッセージと照合する毎時プロセスについても説明した。このシステムは証拠への参照、信頼度、ステータスを保存する。新しい主張は、履歴を黙って上書きするのではなく、古い主張を置き換えられる。

「dream」とラベル付けされた夜間プロセスは、最近の会話をレビューし、将来のセッション向けのガイダンスを生成する。Jamesのワークスペースでは、回答の長さ、追加質問、求められていないスポーツ更新に関する好みが記録されていた。

その名称は冗談を誘うが、根本的な仕組みは単純だ。システムは対話履歴を要約し、後のエージェントセッションが参照できる指示を書き出す。

ユーザーにとって重要なのは、ファイルがdreamと呼ばれているかどうかではない。その要約が正確で、可視で、修正可能で、削除可能な状態に保たれるかどうかだ。

Jamesは、アプリケーション作成、ドキュメントビルダー、メディア処理ツール、多数のスキルのためのフレームワークも発見した。これらのコンポーネントは、Museが幅広いリクエストをより小さな操作へ変換する仕組みを示している。

一部の機能は、部分的にハードコードされているように見えた。この観察は、Museのすべての行動がモデルの推論から自発的に生まれるという考えに疑問を投げかける。ただし、エージェントが偽物、あるいは完全にスクリプト化されていることを意味するわけではない。

信頼性の高いエージェントには、あらかじめ定義されたツールが必要だ。サブスクリプション解約のワークフローでは、テスト済みのコネクターと明確な権限ルールを使用すべきである。モデルにあらゆる手順を発明させれば、予測不可能性が増す。

興味深い問いは、Museがそれらのツールからどのように選択するのかという点だ。内部指示ファイルは期待される動作を示せるが、モデルの意思決定プロセスやホスト側の強制措置を完全に明らかにするものではない。

Jamesは、ESP32-C5デバイス、Wi-Fi、Bluetooth、ローカルネットワーク探索を含む実験的統合であるMeta Home Linkへの参照も見つけた。Metaはその製品を公表していない。

ファイルシステム上の参照が、リリースを保証するわけではない。企業は開発イメージ内に、休眠コード、放棄されたプロトタイプ、テスト設定、将来を見据えたドキュメントを日常的に含めている。

同じ注意は、列挙されたコネクターにも当てはまる。設定ファイルには、当時Museが公にサポートしていなかったサービスが含まれていたと報じられている。これらの項目は、進行中の計画、内部テスト、未使用の足場を表している可能性がある。

エクスポートにはCodexのコマンドラインインストールが含まれていたが、JamesはMuseがそれをコーディングエージェントとして呼び出した証拠を見つけなかった。同梱のサンドボックスコンポーネントは、制限されたメディア処理ジョブを支えるものと見られた。

これは、インストール済みソフトウェアだけに基づく結論への有用な警告となる。バイナリの存在は利用可能性を示すにすぎず、実際の使用を示すものではない。本番環境での動作を確認するには、ログ、呼び出し、または再現可能なテストが必要だ。

エクスポートはまた、Sentinelの完全な動作を明らかにするものでもない。MetaはSentinelをランタイムコンテナの外部に配置しているため、ユーザーレベルのアーカイブには、その完全な保護実装や秘密情報は含まれないはずだ。

また、このアーカイブはMetaがVMにアクセスできないことを立証するものでもない。Metaによれば、現在の隔離は運用ポリシーを通じて従業員のアクセスを制限している。提供事業者のアクセスを暗号学的に防止するものではまだない。

Metaは、Meta自身であってもユーザー環境にアクセスできないようにする機密VMオプションを計画している。同社によれば、このモードは外部レビュー中で、2026年後半の提供が予定されている。

それまでは、ユーザーは隔離と提供事業者からの不可視性を区別しなければならない。専用VMは顧客同士を分離できる一方で、定められた状況下ではサービス運営者のアクセスを許容しうる。

この区別は、印象的なファイル名よりも重要だ。プライバシーに関する中心的な問いは、誰が、どの条件で、どのような監査証跡を伴い、どの強制可能な制御を通じて個人データにアクセスできるのかという点にある。

Metaの競合他社はいま透明性を問われている

Museは競合するエージェントに対し、ユーザーがワークスペースを管理できるのか、それとも提供事業者が管理するブラックボックスとやり取りしているだけなのかを説明するよう迫っている。

消費者向けAI製品は、プロンプトに答える段階から、徐々にコンピューターを操作する段階へ移行してきた。ウェブサイトを閲覧し、ファイルを生成し、コードを実行し、アカウントに接続し、バックグラウンドでタスクを継続する。

Museは、これらの機能を永続的なパーソナルコンピューターとして提供する。Metaの製品訴求は、一度の会話のために作られる一時的なサンドボックスではなく、継続性を重視している。

このアプローチには利点がある。ファイルはタスク間で利用可能な状態に保たれる。エージェントはプロジェクトを維持し、ツールをインストールし、作業成果物を保存できる。ユーザーは、整えられたチャットの回答だけを受け取るのではなく、環境を調査できる。

同時に、これは大きな信頼要件も生み出す。エージェントはメール、カレンダー、連絡先、購入履歴、文書、接続されたソーシャルアカウントを閲覧する可能性がある。有用性が高まるほど、そのファイルシステムはより機密性の高いものになる。

消費者導入に関する報道によれば、Museはリリースから10日以内に、米国のiPhone向け無料アプリで首位に到達した。この早期の関心は、設計上の弱点がもたらす影響を大きくする。

Metaはまた、ショッピング、旅行、生産性、小売、スマートグラスにまたがる統合を発表した。同社のエージェント拡張により、Museはより多くのデバイスや取引に入り込む。

接続が追加されるたびに、権限グラフは拡大する。ユーザーが承認しているのは、もはや単一のチャットボット会話ではない。サービス横断で情報を組み合わせられるアクティブなシステムを承認しているのだ。

アーキテクチャが異なる場合でも、競合他社はすでに同様の問題に直面している。クラウドエージェントにも、モデル、ワークスペース、認証情報、外部サービス、提供事業者のインフラの間に境界が必要だ。

Metaの公開アーキテクチャは、研究者に検証可能な具体的モデルを与えている。Sentinel、認証情報の代理、汚染データの追跡、コンテナ隔離、ダウンロード可能なメモリはいずれも、観測可能な動作に照らして検証できる。

制御策が機能するなら、この開放性はMetaに利益をもたらしうる。研究者は欠陥をより早く見つけられ、ユーザーは不透明なサービスよりも環境をよく理解できる。

一方で、恥ずかしい実装上の詳細が露呈する可能性もある。内部プロンプト、従来型のスクリプト、休眠中の統合、粗い製品の足場は、マーケティングで用いられる洗練されたイメージと一致することはほとんどない。

企業は、その恥ずかしさを許容できるかを決めなければならない。Metaの答えは、どうやら肯定的だ。同社の幹部は現在、ランタイムアクセスを隠そうとするのではなく、所有権の機能として説明している。

この決定は他の提供事業者にも圧力をかける。ユーザーがエージェント内部で文書、コード、ワークフロー、記憶を作成するなら、可搬性を求めるようになるだろう。エージェントが何を知っているかについて、読める記録を期待するようにもなるかもしれない。

可搬性だけでは十分ではない。エクスポートは個人の素材とプラットフォームのコンポーネントを分離し、認証情報の扱いを説明し、有効な秘密情報を含めないようにしなければならない。

エージェントには、エクスポートのリスクを考慮したアカウント復旧モデルも必要だ。侵害されたセッションによって、完全なアーカイブがより強い検証なしに簡単に利用可能になってはならない。

企業の購入者はさらに厳しい質問をする。データ保持、管理者アクセス、従業員の退職、リーガルホールド、監査ログ、地域別ストレージ、接続サービスの権限に対する制御が必要になる。

消費者向けのファイルブラウザは、こうした問いへの答えにはならない。しかし、ひとつの原則は打ち立てる。エージェントの作業状態は、それを生成した本人から完全に隠されたままであってはならない。

そのため、競争への影響はMuse固有のファイルを超えて広がる可能性がある。Metaは、パーソナルエージェントがその基盤となるコンピューターを製品の一部として提示できるかを試している。

ユーザーがその制御を重視するなら、競合他社にはより優れたエクスポートおよび調査ツールが必要になる。セキュリティインシデントが続けば、市場はより限定的なワークスペースと、より厳格な分離へ向かうかもしれない。

Metaの選択が機能するかを示す3つの兆候

次の試金石は、Metaがアカウント間の露出、秘密情報の漏えい、混乱を招く権限エラーを生じさせずに、ユーザーのオープンなアクセスを維持できるかどうかだ。

最初の兆候は、Metaがランタイムの内容をどう扱うかである。今後のMuseイメージには、有効な提供事業者の認証情報、再利用可能な内部キー、不必要な本番環境の秘密情報が一切含まれていてはならない。

研究者は今後も、セッションやアカウントをまたいでエクスポートされたファイルを比較し続けるだろう。アーカイブに含まれるのがユーザーデータ、公開コンポーネント、非機密のランタイム素材だけであれば、Metaの所有権に関する主張はより強まる。

パッケージ化されたキーが保護対象のインフラにアクセスできると誰かが示せば、状況は直ちに変わる。それは異例の製品設計を、具体的なセキュリティ障害へと変えることになる。

2つ目のシグナルは、一括エクスポート時のSentinelの挙動だ。Museは個人ファイルがVM外へ持ち出されるタイミングを明確に示し、転送範囲に見合った承認を求めるべきである。

生成した1つの文書を保存する操作と、ワークスペース全体をエクスポートする操作は異なる。インターフェースは、両者を通常のファイル操作として同列に扱うのではなく、区別すべきだ。

セキュリティテストでは、間接的な要求も検証する必要がある。ウェブページ、メール、共有文書、接続済みアプリケーションが、ユーザーの十分な意図確認なしにMuseへファイルの収集・送信を指示する可能性がある。

Metaのtaint trackingは、この状況に対処するために設計されている。再現可能なテストによって、この保護がブラウザー操作、スクリプト、サブエージェント、スケジュールされたジョブ、コネクターにまたがって機能するかが明らかになる。

3つ目のシグナルは、Muse Confidential VMの提供開始と独立した検証だ。Metaによれば、このモードでは暗号技術により、同社がユーザー環境へアクセスできないようにするという。

これはポリシーに基づくアクセス制限よりも強い主張である。公開された技術文書、信頼できる外部分析、そしてアップデートが保証を密かに弱められないことを示す証拠が必要だ。

監査担当者は、復旧およびサポートのワークフローも検証すべきである。管理者、バックアッププロセス、アカウント復旧経路が保護された環境を迂回できるなら、プライバシー設計は破綻し得る。

この3つのシグナルは明確な基準を示している。ランタイムには適切な素材だけが含まれ、外部への転送には実効性のある制御が必要であり、プロバイダーのアクセスはMetaが掲げるプライバシーモデルと一致しなければならない。

現時点では、Meta Museのファイルシステムアクセスは、分かりにくい展開を通じて明らかになった意図的な機能と理解するのが最も妥当だ。入手可能な証拠は、Metaのホストシステムや別の顧客のファイルへのアクセスを裏付けていない。

一方で、個人向けエージェントがどれほど多くの状態を蓄積するかは示している。メモリ、スクリプト、トレース、ツール、計画、文書、統合に関する指示はいずれも、ユーザーのセキュリティ境界の一部となる。

その境界は、チャットボットがユーモラスな名前のMarkdownファイルを公開したかどうかよりも、はるかに注意を払う価値がある。重要なのは、他者に自分のエージェントコンピューターを操作されやすくすることなく、ユーザーがそれを制御できるかどうかだ。

開発者とセキュリティチームは、次に行われる独立テストを注意深く見守るべきである。ユーザーはMuseに機密性の高い作業を任せる前に、保存されているメモリとコネクターの権限を確認すべきだ。

Metaは、閉ざされたワークスペースではなく、可視性のある所有権を選んだ。今後は、その開放性が他のユーザー、保護されたサービス、あるいはMetaのインフラとの境界で正確に止まることを証明しなければならない。