エージェントの権限管理は、一般的なソフトウェアの権限設定と何が違うのか?
一般的なソフトウェアの権限設定は通常静的だ。インストール時にそのアプリが写真にアクセスできるか、ネットワークに接続できるかを決めれば、その後の挙動は固定される。エージェントの権限管理が異なるのは、エージェントが実行中に動的に、どのツールを呼び出すか、あるファイルを読むかどうか、あるコマンドを実行するかどうかを決定する点にある。つまり権限システムが管理しているのは「このプログラムが何をできるか」ではなく、「この自ら判断を下すものが、一歩ごとに下す決定を実行してよいかどうか」なのだ。
これこそが、Claude Codeの権限システムが3つの層に分かれている理由だ。権限規則は「このツールを使ってよいか」を決め、MCPスコープ制御は「この外部システムに接続してよいか」を決め、サンドボックスはオペレーティングシステムのレベルで最後の防衛線を追加する——たとえ最初の2層の判断ロジックが誤っていたとしても、境界を超えた操作は依然としてブロックされる。
なぜ「権限規則」の1層だけに頼ってはいけないのか、なぜサンドボックスを追加する必要があるのか?
権限規則の判断ロジックは、本質的にはClaude自身が実行前に「この操作が許可されているか」を確認するというものだ——しかしこれは、Claude自身の判断ロジック自体を回避できる攻撃手法(例えばプロンプトインジェクションによって、悪意のある指示を正当な依頼だとClaudeに誤認させる)があった場合、権限規則という層も連鎖的に回避される可能性があることを意味する。
サンドボックスはまさにこの問題を解決する。Claude自身の判断に頼るのではなく、オペレーティングシステムのレベルで、Bashコマンドとそのサブプロセスがアクセスできるファイルシステムとネットワークの範囲を直接制限する。前段の判断ロジックが誤っていたとしても、サンドボックスは境界を超えた操作を物理的にブロックできる。これが、セキュリティガイドラインが「サンドボックスが有効になっていなければ、権限システムがClaudeとあなたのファイルシステムの間にある唯一の防衛線になる」と強調する理由でもある——その唯一の防衛線が一度回避されてしまえば、それを補う二段目の層は存在しない。
実際に設定する際、許可リスト(allowlist)はどう書けば、緩すぎたり煩雑すぎたりしないのか?
MCPツールはmcp__サーバー名__ツール名という命名規則に従っており、これにより2段階の粒度を選べる。チームが既に特定のMCPサーバーを信頼している場合(例えば社内でプロジェクト管理に固定的に使っているサービスなど)、そのサーバー全体を許可リストに加えることができる。例えばmcp__linear__*とすれば、そのサーバー配下のすべてのツールについて、Claudeは毎回確認する必要がなくなる。
しかし、機能が多岐にわたるMCPサーバーで、20種類ものツールがあり、実際の利用シーンでは検索機能だけが必要な場合、より保守的なやり方は、その1つのツールだけを許可することだ。例えばmcp__bigserver__searchとし、それ以外のツールは「確認」状態のままにしておく——こうすれば、あるタスクが誤ってClaudeに別のツールを呼び出させようとしても、システムはまず立ち止まってユーザーに確認を求め、直接実行することはない。実務上、「サーバー全体を信頼する」と「単一のツールを信頼する」はどちらも保持する価値のあるパターンであり、その違いは、そのサーバーに対してどれだけの信頼を置いているかによって決まる。
自分はエンタープライズの管理者ではなく個人ユーザーに過ぎないが、これらの権限設定は自分に関係あるのか?
エンタープライズ環境でなくても、Claude CodeでMCPサーバーに接続したり、ローカルファイルの読み書きやコマンド実行をClaudeに任せたりしている場合、権限設定は「一度の判断ミスがどれほどのコストになるか」に直接影響する。デフォルトでは、Claude Codeを実行する誰もが自由に任意のMCPサーバーに接続できる。拒否リストを意図的に設定したり、サンドボックスを有効にしたりしなければ、出所不明または設計の甘いMCPサーバーが、理論上は想定を超えた範囲のデータにアクセスできてしまう可能性がある。
個人ユーザーにとって最も実践的な第一歩は、自分のプロジェクトで実際に使用しているMCPサーバーとツールを確認し、本当に必要な部分にだけ許可リストを設定し、それ以外は「確認」のままにしておくことだ。次に/sandboxコマンドでサンドボックスを有効にし、ファイルシステムとネットワークへのアクセスを明確な範囲内に制限する。どちらも複雑なエンタープライズレベルの設定は不要で、個人ユーザーでもすぐに実行できる最低限の防御策だ。
ファイルの読み書き、コマンドの実行、外部サービスへの接続ができるエージェントをワークフローに組み込むメリットは明白だが、リスクも同様に具体的だ。明確な権限の境界がなければ、エージェントができることは、あなたのパソコンを手に入れた人ができることとほぼ同義になる。権限設定はあってもなくてもいい細部ではなく、エージェントを安全に運用できるかどうかを決める中核的な仕組みなのだ。
Claude Codeのセキュリティは3つの層の上に成り立っており、それぞれが異なる失敗モードをカバーしている。第一層は権限規則で、Claudeがどのツールやコマンドを実行できるかを決める。第二層はMCPアクセス制御で、Claudeがアクセスできる外部システムの範囲を制限する。第三層はサンドボックス化で、オペレーティングシステムのレベルでファイルシステムとネットワークの境界を強制する。3つの層はそれぞれ独立して機能しており、いずれかの層が失敗しても、他の層が引き続き保護を提供する——これが、たとえば権限規則だけを設定してサンドボックスを有効にしないなど、1つの層だけを設定した場合に防御力が明らかに不十分になる理由だ。
権限規則自体は3つの要素で構成されている。許可(allow)、拒否(deny)、確認(ask)のリストをツールのパターンとして記述したもの、セッション全体の運用姿勢を決める権限モード(default / accept-edits / plan / bypass)、そして強制削除、強制プッシュ、公開操作といった破壊的な操作への明確な遮断だ。実際の設定の多くは、「すべての操作で確認を求める」と「完全に信頼し、すべて自動実行する」という2つの極端の中間のどこかに位置し、プロジェクトのリスクレベルに応じてどちらかに傾いている。
MCPツールはmcp__<サーバー名>__<ツール名>という固定の命名規則に従っており、これにより権限規則は「サーバー全体を信頼する」と「単一のツールだけを信頼する」という2つの粒度で運用できる。チームのプロジェクト管理が特定のMCPサーバーを通じて完結しているなら、そのサーバー全体を許可リストに加えるのは合理的だ。しかし、あるMCPサーバーが20種類のツールを提供していて、検索機能だけが必要な場合は、その1つのツールだけを正確に許可し、残りは「確認」状態のままにしておく方が、より保守的で監査もしやすい。
組織の管理者にとっては、さらにもう一段階の制御がある。managed-mcp.jsonを通じて固定の承認済みサーバー一覧を展開し、allowedMcpServersのような設定と組み合わせることで、開発者が接続できるMCPサーバーを制限できる——例えばcompany-*のような社内で管理されているサーバーの命名パターンのみを許可する、といった具合だ。注意すべき点として、許可リストと拒否リストはそれ自体が「登録システム」ではなく、サーバーがユーザー、プラグイン、または設定ファイルによって先に追加されていなければ、リストのルールは実際には適用されない。
権限規則は、Claudeが制限されたリソースに接触を試みることさえ阻止する。サンドボックスは、たとえプロンプトインジェクション攻撃がClaude自身の判断ロジックを回避したとしても、境界を超えた操作をオペレーティングシステムのレベルで依然としてブロックする。この2つの層は互いを代替するものではなく、補完し合う関係にある——サンドボックスはBashコマンドとその子プロセスにのみ適用され、ファイルシステムの制限は実際にはRead/Editの拒否ルールを通じて実装され、ネットワーク制限はサンドボックスの許可ドメインリストとWebFetch権限ルールを組み合わせる必要がある。権限規則だけに頼る場合、理論上は依然として回避される可能性が残る。サンドボックスだけに頼る場合は、そもそもどのツールを選ぶかという判断層そのものを管理できない。この2つを重ねて使うことが、現時点で推奨される最低限実行可能なセキュリティ構成だ。