MCPへファイル操作を許可する前のフォルダー設計｜権限を狭くする

ファイルを扱うMCPサーバーへ権限を与えるとき、最初からホームフォルダーや作業場所全体を見せる必要はない。

その作業で本当に必要なファイルだけを置く専用フォルダーを作り、そこを境界にする方が安全性を確認しやすい。

MCPのRootsは、クライアント側からサーバーへ意図するファイルシステム上の範囲を伝える仕組みだ。ただし仕様上、Rootsそのものを強制的なアクセス制御として扱うものではない。実際の権限やパス検証は別に必要になる。

必要な操作を先に列挙する

まず、その作業に何が必要かを書く。

読み取り: 必要 / 不要
新規作成: 必要 / 不要
上書き: 必要 / 不要
削除: 必要 / 不要
名前変更・移動: 必要 / 不要

読むだけで足りる作業へ、書き込みや削除まで許可しない。

「将来使うかもしれない」という理由だけで権限を広げず、必要になった操作だけ後から追加する。

作業専用フォルダーを作る

たとえば一つのプロジェクトの資料を読むだけなら、必要な資料の複製だけを専用フォルダーへ置く方法がある。

次のような広い場所を最初の許可範囲にしない方が確認しやすい。

• ユーザーのホーム全体
• Documents全体
• 複数プロジェクトを含むリポジトリの親フォルダー
• SSH鍵や認証情報を含む設定フォルダー
• ブラウザープロファイル

秘密鍵、APIキー、認証情報などを作業用フォルダーと同じ場所へ置かないことも重要だ。

..とシンボリックリンクで外へ出られないか確認する

見かけ上は許可フォルダー内のパスでも、..やシンボリックリンクを使って範囲外へ到達できる実装なら境界が崩れる。

利用するサーバーやクライアントが、

• パスを正規化するか
• 許可範囲外を拒否するか
• シンボリックリンクの参照先をどう扱うか

を確認する。

利用前に「拒否される試験」を行う

正常に読めることだけでなく、意図した範囲外が拒否されることも確認する。

たとえば、

• 許可範囲外のファイルを読む
• 許可範囲外へファイルを書こうとする
• 削除を許可していない状態で削除を要求する
• シンボリックリンク経由で範囲外へ進もうとする

といった試験を行う。

期待どおり拒否されたことをログへ残せれば、設定変更後にも同じ試験を繰り返せる。

ローカルで動いているだけでは隔離にならない

MCPサーバーが自分のPC内で動いていても、それだけで安全な隔離環境になるわけではない。

同じユーザー権限で広いファイルへアクセスできるなら、その範囲は残る。

まず専用フォルダーへ範囲を絞り、読み取りだけから始め、拒否試験を通してから必要な権限だけ増やす。

モデルが出したツール呼び出しを実行前に検証する一般的な方法は、ローカルLLMのツール呼び出しに実行前検証を入れる方法で確認できる。