AIエージェントにツール呼び出しを任せる仕組みとして、MCP（Model Context Protocol、LLMがデータソースやツールに接続するための標準規格）を本番導入し始めたチームに向けた内容です。エージェントの権限管理をどう設計するか悩んでいる方の参考になれば幸いです。
自動化プラットフォームのn8nは2026年7月1日付の公式ガイドで、MCPサーバーのセキュリティにはコントロールプレーン（制御の中枢となるレイヤー）が必要だと述べています。MCPは便利な反面、LLMに外部システムへの実行権限を与える仕組みでもあります。その境界線をどう引くかが、本番運用の分かれ目になります。
MCPコントロールプレーンとは何か
MCPサーバーは、LLMがツールやデータにアクセスするための「窓口」を定義します。
この窓口を用意しただけでは、本番環境のガバナンス（統制）としては不十分です。
コントロールプレーンは、エージェントと接続先システムの間に挟まる実行制御層です。
n8nはこの位置に自社を置き、ツール呼び出しの範囲を絞り、認証情報を分離し、実行履歴を記録する役割を担わせています。
発想の転換点は、MCP接続を「権限を直接渡すもの」として扱うのではなく、「統制された要求経路」として扱う点にあります。
エージェントがツールを直接叩けるようにするのではなく、必ず制御層を経由させる設計です。
段階的に見る5つの統制ポイント
n8nのガイドでは、コントロールプレーンが担う統制を次の5つに整理しています。
- 認証（Authentication）: 呼び出し元が誰かを検証する
- 認可とツール呼び出しのスコープ制限: 文脈ごとに使えるツールと操作を絞る
- 認証情報の分離: エージェントの動作と接続先の認証情報を切り離す
- 実行ログの記録: 監査や調査のために各操作を記録する
- 最小権限の原則: ワークフローに与えるツールと権限を必要最小限にする
これらが重要なのは、MCPが従来のAPI連携にはなかった種類のリスクを持ち込むからです。
n8nはプロンプトインジェクション（悪意ある指示を紛れ込ませる攻撃）、ツールポイズニング（ツール定義自体を汚染する攻撃）、confused deputy問題（正当な権限を持つ主体が意図せず不正利用される問題）、トークンの横流し、SSRF（サーバー側リクエスト偽造）、過剰な権限付与、セッションハイジャックといった脅威の分類を挙げています。
共通しているのは、エージェントが操作されたり誤設定されたりすることで、正規の連携が想定外の範囲で使われてしまう点です。
認証だけでは足りない理由
n8nはOAuth 2.1（呼び出し元を検証し、トークンを適切なエンドポイントにスコープする標準的な認可の仕組み）を推奨しています。
通信の暗号化などトランスポート層のセキュリティも合わせて求めています。
これらは「誰が要求しているか」「その要求に有効な認可があるか」を確定させる仕組みです。
しかし認証だけでは、その要求が特定のエージェント・ツール・業務プロセスにとって安全かどうかは判断できません。
たとえば、権限範囲が広すぎるトークンは、認証自体は正常でも大きな露出リスクを生みます。
プロンプトインジェクションで操作されたモデルが、技術的には認証済みのツール呼び出しを行っても、業務上は不適切な操作である可能性があります。
そのため認可は複数の層で機能する必要があります。
呼び出し元の身元、呼び出されるツール、要求された操作の範囲、実行に使われる認証情報を、それぞれ確認する必要があります。
これらの制約を一貫して適用できる場所が実行層であり、プロンプトの書き方や個別の連携設計に委ねるべきものではありません。
従来のAPI連携との違いを整理する
| 観点 | コントロールプレーンなしのMCP | コントロールプレーンありのMCP |
|---|---|---|
| ツールアクセス | エージェント連携に直接公開されうる | オーケストレーション層でスコープを制御できる |
| 認証情報 | 制御層による分離がない | エージェントから分離しつつ接続先には到達できる |
| 権限 | 広範なアクセスが過剰権限のリスクを増幅 | 最小権限とツール単位の公開を強制できる |
| 監査性 | 実装依存で追跡が難しい | 各操作をオーケストレーション層で記録できる |
従来のREST API連携では、呼び出す関数や引数がコードとして固定されているため、範囲の逸脱は比較的起きにくい構造でした。
MCP経由のエージェントは、状況に応じて呼び出すツールや引数を自律的に選ぶため、想定外の組み合わせが発生しやすくなります。
この違いが、単なるAPIゲートウェイの設計知識だけではMCPの統制として不十分な理由です。
今日確認できること
自社でMCPサーバーを本番運用している、またはこれから導入する場合、次の点を確認しておくと判断材料になります。
- 使っているMCPクライアント（n8n、Claude Desktop、社内エージェント基盤など）が、ツール呼び出しの前段でスコープ制限をかけられる構成になっているか
- 認証情報がエージェントのプロンプトコンテキストやログに直接露出していないか、接続設定を確認する
- OAuth 2.1など標準的な認可フローに対応したMCPサーバー実装かどうか、サーバーのREADMEや仕様を確認する
- 各ツール呼び出しの実行ログが、誰が・どのツールを・どの権限で呼んだか追跡できる形で残っているか
- 1つのMCPサーバーに複数のツールを無条件で束ねていないか、ワークフローごとに必要なツールだけを公開できているか
特に社内でMCPサーバーを自作している場合、ツール定義に認証情報を埋め込んでいないか、コードレビューの観点に加えることをおすすめします。
n8nのようなワークフロー基盤を使っている場合は、MCP関連のノードや接続設定のドキュメントで、認証情報の分離とスコープ設定がどう扱われているか確認するのが具体的な第一歩です。
まとめ
MCPは、LLMに外部システムへの実行権限を与える強力な仕組みですが、公開範囲をそのまま信頼範囲にしてしまうと本番運用のリスクになります。
整理すると、確認すべきは次の点です。
- ツール呼び出しがスコープ制限された経路を通っているか
- 認証情報がエージェントから分離されているか
- 最小権限でツールが公開されているか
- 実行ログが監査に耐える形で残っているか
これらをMCPサーバー単体ではなく、コントロールプレーンに相当する制御層で担保できているか、手元の構成を一度見直してみてください。