本番で動いている Model Context Protocol（MCP）（AI エージェントが社内外のデータやツールにつながるための共通プロトコル）サーバーの多くは、設定済みの認証情報（クレデンシャル）で一度だけ認証し、あとは届いたリクエストをすべて処理しています。接続してきた相手は最初に確かめても、その後「いま誰が頼んでいるのか」「その人はどのデータまで見てよいのか」は確かめていない、という構成です。

しかも MCP の仕様では、認可（authorization）は「OPTIONAL（任意）」と定められ、対象も HTTP ベースのトランスポートに限られます。つまり、認可をまったく実装していなくても、MCP サーバーとしては仕様に準拠していることになります。「仕様どおりに作った」と「安全に使える」は別の話で、誰に何を許すかのチェックは、サーバーを運用するチームが自分で用意するものです。

では、そのチェックを AI エージェントに任せればよいかというと、そうはいきません。エージェントには、リクエストを送ったのが誰かを証明する手段がありません。また、本来より多くのデータを読みにいったときに、それを止める仕組みもエージェント自身は持っていません。この2つの穴を埋める制御は、エージェントの外、リクエストがサーバーに届く手前の独立したレイヤーに置くべきです。この記事では、AI エージェントへの社内データ接続を審査する立場から、その設計の考え方と確認ポイントを整理します。

MCPの「認証」と「認可」はどう違う？

認証（authentication）は「相手が誰か」を確かめる仕組みです。認可（authorization）は「その相手に何を許すか」、つまりどのデータやツールにどこまで触れてよいかを決める仕組みです。ログインできたことと、すべてのデータを見てよいことは同じではありません。

先に触れたとおり、MCP の仕様は認可を任意の扱いにしています。HTTP 経由で接続するサーバーで認可を実装する場合の手順は定めていますが、実装そのものは求めていません。そのため、社内で MCP サーバーを使うなら、「認可はどこで、誰の権限にもとづいて判断されるのか」を、利用を承認する側が必ず確かめておきましょう。

MCPの認可フローはどう動く？

HTTP 経由で接続する MCP サーバーが認可を実装する場合、仕様は OAuth 2.1 にもとづく次の流れを定めています。

1. MCP サーバーは OAuth のリソースサーバーとして振る舞い、どの認可サーバーを使うかをメタデータ（RFC 9728）で公開します。

2. クライアントは認可サーバーで、PKCE を使った認可コードフローによりアクセストークンを取得します。このとき、トークンを使う先のサーバーを resource パラメーター（RFC 8707）で指定します。

3. クライアントは、リクエストのたびにアクセストークンを付けて MCP サーバーを呼び出します。

4. MCP サーバーは、トークンが自分宛てに発行されたものかを検証し、そうでなければ拒否します。

ここで押さえておきたいのは、このフローが決めるのは「誰がこのサーバーを呼べるか」までだという点です。サーバーの先にあるデータソースで、その人がどのレコードやファイルまで見てよいかは、別に判断しなければなりません。この記事で扱うのは、その判断をどこに置くかです。

「エージェントの外で強制する」とはどういうこと？

エージェントの外で強制するとは、認可、最小権限のスコープ設定、監査ログを、エージェントや MCP サーバーの中ではなく、独立したコントロールプレーン（統制基盤）に置くことです。コントロールプレーンは、リクエストがサーバーに届く前に、1件ずつ中身を確かめます。制限をかけているのはエージェントではないので、エージェントが本来より広い範囲を要求しても、その制限は崩れません。

中央でアクセスを制御していないと、強い権限を持つ認証情報でサーバーがリクエストを処理し、依頼したユーザーにそのデータを見る権限があるかは確かめない、という状態になります。セキュリティの分野では「confused deputy（混乱した代理人）問題」と呼ばれる構図です。依頼主の代わりに強い権限で動くエージェントとサーバーが、ここでいう「代理人」です。

ここで大事なのは、エージェントにはこれを検知できないという点です。エージェントの能力が足りないからではありません。だまされている当事者がエージェントそのものだからです。だまされている側の内部にチェックを置いても、チェックとしては働きません。この構図から生まれるリスクの分類は、MCPサーバーの代表的な脆弱性と対策が参考になります。MCP 全般のセキュリティリスクを整理したい場合は、MCPのセキュリティガイドもあわせてご覧ください。

エージェント内のロジックはなぜ破綻する？

AI エージェントは、タスクに必要な範囲より広い権限のアクセストークンを使っていることがよくあります。エージェントやサーバーごとに個別にアクセスを管理すると、設定が散らばり、ルールの適用もばらつきます。全体のポリシーを判断する場所が、どこにもない状態です。

OWASP（Open Worldwide Application Security Project）は、LLM アプリケーションの主要なリスクの一つとして「過剰なエージェンシー（excessive agency）」を挙げています。これは、タスクに必要な範囲を超えた権限をエージェントに与えることです。そして、認可の判断はモデルに委ねず、外部のシステムで行うよう勧めています。プロンプトインジェクションは完全には防げません。だからこそ、エージェントに与える権限を必要な範囲に絞り、乗っ取られた場合の被害を小さくしておく必要があります。

エージェント内のロジックで運用したときに起きる問題は、大きく3つあります。順に見ていきましょう。

認証情報が広がり、サービスアカウントが増える

多くのエージェントは、広いスコープを持つ OAuth 2.0 のアクセストークン1つを、複数のサービスで使い回しています。1つのサーバーが侵害されると、そのトークンを通じてほかのサービスまで危険にさらされかねません。サーバーごとに認証を分ければ共有は減りますが、接続や認証情報、環境が増えるほど管理は複雑になります。

パススルー認証を使うと、コントロールプレーンは共有のサービスアカウントを持ちません。リクエストのたびに、ユーザー本人の OAuth または SAML（Security Assertion Markup Language）のアイデンティティを引き継ぎます。各リクエストは実際の利用者の権限で実行され、認証をゲートウェイで一度強制すれば、サーバーごとに独自の認証ロジックを書く必要もなくなります。CData Connect AI は、エージェントがツールを呼び出す時点でユーザー単位と接続単位の権限を適用します。詳しくはエージェント認可のアプローチ（英語）をご覧ください。

審査で確認したいこと：そのエージェントは、どのアカウントの権限でデータにアクセスしていますか。複数の利用者で同じトークンを共有していませんか。

ログから「誰がやったか」をたどれない

複数のエージェントが1つのサービスアカウントを共有していると、ログに残るのはそのアカウント名だけです。実際に操作した個人はわかりません。記録自体もエージェント、サーバー、SDK、API に分散するため、問題が起きたときの調査に時間がかかります。アクセスの入口を一か所にまとめれば、記録もそこに集まり、リクエストを発信元までたどりやすくなります。

審査で確認したいこと：インシデントが起きたとき、どのユーザーの依頼でどのデータが読まれたかを、ログから特定できますか。

異動しても権限が残り続ける

利用者が異動や役割変更をしても、その人のエージェントには不要になった権限が残ることがあります。OWASP は、アクセスをタスクごとに絞り、エージェントをユーザー本人の権限で動かすよう勧めています。ID プロバイダー（IdP）で管理すれば、エージェントの権限を、いまの役割やアクセスポリシーに合わせ続けられます。エージェントや MCP サーバーが増えるほど、この管理は難しくなります。複数の MCP サーバーを運用する場合の考え方は、マルチMCPデプロイの設計図（英語）で詳しく扱っています。

審査で確認したいこと：人事異動や退職でユーザーの権限が変わったとき、エージェント経由のアクセスにも自動で反映されますか。

ポリシーを独立させるコントロールプレーンとは？

ガバナンスの効いたコントロールプレーンは、複数の MCP サーバーへの、安全な単一の入口です。認証、ルーティング、ポリシーの適用をここで引き受けるため、クライアントがバックエンドのサーバーに直接つながることはありません。リバースプロキシのように内部のサーバーを外から隠し、攻撃される面を1つのエンドポイントに絞り込めます。

役割分担もはっきりさせておきます。アクセスポリシーを書いて見直すのは、セキュリティチームが管理する IdP です。そのポリシーを毎回のリクエストに適用するのが、中央のコントロールプレーンです。「ポリシーを書く場所」と「強制する場所」を分けておけば、ルールの変更は IdP 側だけで済みます。この考え方は企業向けMCPセキュリティのプレイブックにまとめられています。

MCPゲートウェイとは？

MCPゲートウェイは、このコントロールプレーンの考え方を実装したものの一つです。AI クライアントと複数の MCP サーバーの間に入り、認証、ルーティング、ポリシー適用、ログ記録を一か所で担います。CData の MCP Gateway も、このパターンにもとづく実装です。一般的な API Gateway との役割の違いは、API GatewayとMCP Gateway：特徴と選定基準をご覧ください。

ガバナンスのどこをカバーできる？

社内で AI エージェントのガバナンスを考えるときは、「棚卸し」「責任者」「ポリシー」「監査」の4つの観点に、入口を通らない「シャドーMCP」を加えて整理すると抜けを見つけやすくなります。コントロールプレーンがそのすべてを解決するわけではありません。どこまでを担い、どこが組織側の宿題として残るのかを整理すると、次のようになります。

実行時の強制はどう動く？パススルー権限とRBAC

実行時の強制とは、認可の判断をリクエストのたびに、呼び出しの時点で行うことです。基準になるのは、エージェントの設定に書き込まれた固定の権限ではなく、依頼している本人のいまのアイデンティティです。コントロールプレーンは、そのアイデンティティに対する現在のポリシーで、ロールベースアクセス制御（RBAC）の権限を1件ずつ確かめます。

OAuth/SAMLのアイデンティティはどう引き継がれる？

IdP は、ユーザーのいまの役割、所属グループ、条件付きアクセスのポリシーをもとに、アクセスの可否を決めます。コントロールプレーンは、エージェントのツール呼び出しがサーバーに届く前に、その判断を適用します。

MCP には、この流れを標準化する Enterprise-Managed Authorization（EMA）という拡張もあります。シングルサインオン（SSO）でサインインしたあと、クライアントが IdP から ID-JAG（Identity Assertion JWT Authorization Grant）を受け取り、特定のサーバーだけに使えるアクセストークンと交換する方式です。ただし、対応した最初の IdP は Okta で、ID-JAG はまだ IETF のドラフト段階です。採用を検討する場合は、自社の IdP が対応しているかを先に確認してください。

Connect AI は EMA とは別のアプローチをとっています。OAuth と SAML にもとづくアイデンティティと接続ごとの権限で、データへのアクセスを制御します。CData ではこれを、パススルー権限によるアイデンティティファーストのセキュリティと呼んでいます。

データソースごとに、誰の権限が効く？

パススルー権限で大切なのは、「AI 経由でも、その人が普段のアプリで見られる範囲しか見られない」状態になっているかどうかです。データソースごとの確認ポイントは次のとおりです。

データベースの場合は、MySQLをAIに安全につなぐには？MCPで固める権限設計でMySQLを例にした権限設計を紹介しています。

最小権限とワークスペース分離はどう効く？

最小権限とは、エージェントが触れられる範囲を、タスクに必要なデータオブジェクトと操作だけに絞ることです。権限はリクエストのたびに確かめます。

ワークスペース分離は、接続、認証情報、データアクセスをワークスペースごとに切り分ける仕組みです。エージェントは、割り当てられたワークスペースの外にあるリソースにはアクセスできません。さらにツール単位の権限で、明示的に許可したツール以外は使えないようにし、使えないツールはエージェントからも見えなくします。こうしたきめ細かい AI コントロールの詳細は、AIエージェントのフィールドレベルセキュリティ（英語）とマルチエージェント環境でのMCPサーバー保護（英語）で解説しています。

監査ログには何を残すべき？

AI によるデータ操作の1件1件を、認証済みの実在ユーザーにひも付けた監査ログは、エージェントの外にあるコントロールプレーンで記録してはじめて残せます。誰が頼んだのかを証明できず、どこまで読むかを止められないエージェントには、証拠を残すこともできません。実行時の制御は不正な操作を防ぎ、監査ログはプロンプトインジェクションの試みや不審なエージェントの動きを調べるための証拠になります。

監査ログは、セキュリティチームがすでに運用している SIEM（Security Information and Event Management）に取り込めてはじめて役に立ちます。NSAのMCPに関するガイダンス（英語）も、SIEM と連携した監査ログを求めています。審査では、各記録に次の5つが含まれているかを確認してください。

• 認証済みユーザーのアイデンティティ：サービスアカウントではなく、実際の利用者

• エージェントまたはクライアント：どのアプリケーションが呼び出したか

• 呼び出されたツール：実際に使われた機能

• 対象リソース：アクセスした接続とオブジェクト

• タイムスタンプと判定結果：いつ発生し、許可されたか拒否されたか

自作か導入か、どう判断する？

基本的な MCP サーバーを作ること自体は、それほど難しくありません。負担が大きいのは、その後の認証、ガバナンス、監視、アップデートを続けることです。

MCP をセルフホストするということは、認証、認証情報の保管、監査ログ、アクセス制御をすべて社内で抱え続けるということです。マネージドの基盤を使えば、これらの責任をベンダーに任せ、社内チームの運用とセキュリティの負担を減らせます。比較の詳細は、マネージドMCPとセルフホストの比較とMCPを自作するか導入するかをご覧ください。

実際に、ヘルスケア領域のある専門商社では、社内データを AI で分析するために MCP サーバーを選ぶ際、コミュニティ版ではなく、SOC 2 Type II などのセキュリティ基準を満たす提供元の製品であることを決め手の1つにしました。データにつなぐ入口を誰が保守し、誰が責任を持つのかは、導入判断の段階で問われるポイントです。

エージェントの外で認可を一元化するには

CData Connect AI は、AI エージェントと社内のデータソースの間に入る、中央のコントロールプレーンです。データソース側の認証をそのまま使うパススルー権限、接続単位とフィールド単位の権限設定、一元化された監査ログによって、この記事で見てきた3つの論点（誰の権限で動くか、どこまで許すか、何を記録するか）をエージェントの外で担います。セキュリティチームは、エージェントのリクエストがどう認可され、どう記録されるかを自分たちで確認できます。

EMA の登場が示すように、MCP のアクセス管理は中央で一元化する方向に進んでいます。この仕組みを社内で作り続けるか、基盤に任せるかは、運用体制と監査要件しだいです。まずは自社のデータで、認可と記録がどう見えるかを確かめてみてください。

無料トライアルを始めると、自社のデータソースをつないで動きを確かめられます。

よくある質問