「このファイルを参照して」と言ったつもりが、エージェントがルートファイルシステム全体を圧縮して返してきた——MetaのMuseで実際に起きたことだ。
何が起きたか：スコープを明示しないと上限まで使われる
MetaのAIエージェント「Muse」をめぐって、二人の開発者が独立に同じ挙動を確認した。ほとんどプロンプトを加えずに、エージェントが動作しているLinux環境のルートファイルシステムをzip圧縮してダウンロードできてしまう。Ubuntuのシステムファイルからアプリのテンプレートまで、まるごと手に入る状態だ。
技術的な根拠はシンプルだ。Museは通常のLinuxプロセスとして動いており、ファイルシステムへのアクセスを明示的に制限するサンドボックスが機能していなかった。「エージェントの指示に従う」という設計が、そのまま「/から全部zip圧縮する」に翻訳された形だ。
flowchart LR
U[ユーザーの指示] --> A[Museエージェント]
A -->|理想：スコープ制限| R[許可ディレクトリのみ]
A -->|実際の挙動| F[ルートFS全体]
F -->|zip圧縮して返す| U
style R fill:#2980b9,color:#fff
style F fill:#e67e22,color:#fff
style U fill:#7f8c8d,color:#fff
style A fill:#7f8c8d,color:#fff
で、自分のエージェント実装で何が変わるか
LLMにtool callでファイル操作を渡す設計は今や珍しくない。「ディレクトリを渡してコードを読ませる」「ログを解析させる」——この手の実装でファイルアクセスのスコープをどこで切るかは後回しにされやすい。今回が示すのは「LLMが悪意を持つ」という話ではなく、「スコープを明示しないと権限の上限まで使われる」という設計上の現実だ。制限はモデルの判断に任せるのではなく、インフラ側で設ける必要がある。
完全サンドボックスは答えではない
コンテナで完全に隔離すれば解決——とはいかない。エージェントを完全にオフラインにすると「外部API呼び出し」「検索」「メール代行」といった有用性の中心部が失われる。機能のために権限が必要で、権限があれば漏洩リスクがある、という構図は解消しない。現実的な落とし所は、chroot/namespaceでファイルシステムを切り、ネットワーク許可は許可リスト制、tool callの引数はパストラバーサルを弾く——という層の組み合わせになる。ただし「どこまでやるか」はユースケースによる。内部ツールと公開エージェントではリスク許容度が異なる。
一つ問いかけるとすれば
自分のAIエージェント実装で、ファイルアクセスのスコープを「インフラ側で」制限しているか確認したことはあるか？プロンプトに「関係ないファイルは読まないで」と書くのと、mount namespaceで物理的に切るのはまったく別の話だ。今のエージェント設計、どちらに依存している？
参考: Muse will apparently let you download its entire filesystem (The Verge) / Why can’t we just keep rogue AIs off the internet? (The Verge)