認可だけでは守れない MCP 通信：Okta・Netskope・CrowdStrike のアプローチと提供状況を比較する

» Okta » Netskope » CrowdStrike » 生成AIセキュリティ対策シリーズ » AI
yuki yuki

 

はじめに

こんにちは、ネクストモードのゆきなわです。

AI エージェントは MCP (Model Context Protocol) を通じて外部のツールやデータソースに接続します。MCP を利用した外部ツールとの接続が増える一方、どのエージェントがどの MCP サーバーと通信しどのようなデータをやり取りしたかを、組織が把握できていないケースが少なくありません。IT 部門の承認を経ず、組織の管理外で稼働するシャドー MCP サーバーも問題になっています。

弊社の連載「【Okta for AI Agents】AIエージェントの認証・認可をID基盤に集約する 第1回」では、エージェントが誰の権限で動くかという認可の視点を扱いました。本記事では、MCP の通信経路そのものを制御するゲートウェイを取り上げ、ネクストモードで取り扱う Okta・Netskope・CrowdStrike のアプローチと提供状況を比較します。

本記事のポイント

  • 認可が決めるのは「誰がどこに接続できるか」まで。通信の中身の統制は、経路上にチェックポイントを設けるゲートウェイの役割です。
  • ゲートウェイの実装は、経路上に置く集中ゲートウェイ型と、クライアントと同じホストで動くクライアント側プロキシ型の2パターンに分けられます。
  • Okta の Agent Gateway はロードマップ段階、Netskope の Agentic Broker と AI Gateway は一般提供済み、CrowdStrike の MCP proxy は OSS として公開されています。

認可とゲートウェイの役割の違い

前提として押さえておきたいのは、MCP の公式仕様が認可 (authorization) を必須にしていない点です。現行の仕様書には “Authorization is OPTIONAL for MCP implementations” と明記されており、実装するかどうかは MCP 実装側の判断に委ねられています。

そして認可を整えても守れる範囲には限りがあります。認可が担うのは、誰がどの MCP サーバーにどの権限で接続できるかというアクセス判断です。ツールの引数や応答に含まれる機密情報、悪意ある命令といった内容までは検査しません。この通信の中身を検査・制御するチェックポイントを経路上に設けるのがゲートウェイです。チェックポイントで何を行うか (ツールの集約や監査までか、内容の検査やデータ持ち出し防止 (DLP) まで踏み込むか) は製品によって幅があります。なお、連載第2回で扱った MCP EMA も認可を企業の ID 基盤に集約する仕組みであり、通信内容の検査までは扱いません。

このように、ID 基盤とゲートウェイは、どちらかを選ぶ関係ではなく補完関係にあります。連載で整理した7つの確認ポイントに当てはめると、ユーザー権限や SaaS 接続権限の統制は ID 基盤が、データ持ち出し制御と実行時のトラフィック可視化はゲートウェイが担いやすい領域です。この役割分担を頭に置くと、後述する各社のアプローチも読み解きやすくなります。

why-mcp-gateway-needed

放置される MCP サーバーと攻撃手口

実際、管理の行き届かない MCP サーバーは数多く観測されています。OWASP の MCP Top 10 はシャドー MCP サーバーを主要リスクの1つに挙げました。セキュリティ企業 BlueRock が12,000超の MCP サーバーをスキャンした集計 (2026年6月時点) では、33%に無制限の URI 取得 (SSRF) の脆弱性が、42%にコマンドインジェクションの欠陥が確認されています。Knostic の調査では、公開インターネット上で発見された MCP サーバーのうち手動で検証した119台すべてが、認証なしでツール一覧の取得に応じました。

攻撃の手口も具体的に明らかになってきました。Netskope の脅威リサーチは、ツールの説明文に隠し命令を仕込む tool poisoning や、信頼済みのツールがレジストリや更新経路で悪意ある版に差し替えられる rug pull といった手口を報告しています。

ただし、経路上にチェックポイントを置くだけでこれらを防げるわけではありません。tool poisoning にはツール定義や入出力の検査が有効ですが、rug pull はサプライチェーン攻撃であり、署名検証やバージョン固定、実行時挙動の監視といった対策もあわせて必要になります。何を検知できるかは、そのゲートウェイが内容検査やツール定義のベースライン比較をどこまで実装しているかで決まり、この機能差が後述する製品比較の重要な観点になります。

2つの実装パターン

ゲートウェイは、制御点をどこに置くかで2パターンに分けられます。

  • 集中ゲートウェイ型
    • 配置場所：MCP トラフィックの経路上 (クラウドサービスや専用アプライアンス)
    • 対象範囲：ゲートウェイを経由するすべての MCP 通信
    • 弱点：経由しない直接接続は統制できないため、通信を経由させる仕組みとセットで設計する必要がある
    • 代表例：Okta が計画する Agent Gateway、Netskope の Agentic Broker と AI Gateway。Cloudflare や AWS も同型の製品を提供している (付録参照)
  • クライアント側プロキシ型
    • 配置場所：MCP クライアントと同じホスト
    • 対象範囲：設定ファイルでラップした MCP 接続のみ
    • 弱点：設定していない接続や、プロキシを外して直接つないだ接続は観測できない
    • 代表例：CrowdStrike の MCP proxy

fig-mcp-gateway-two-patterns-1

このほか、エージェント自身が呼び出すセキュリティツールを提供する方式 (Palo Alto Networks) や、SDK でツール呼び出しをフックする方式 (Cisco) もあります。経路の制御ではなくエージェント側への組み込みのため、本記事では付録で触れるにとどめます。

Okta・Netskope・CrowdStrike の比較

3社の現状を表にまとめます (2026年7月時点)。

ベンダー 製品 パターン 提供状況 特徴
Okta Agent Gateway (Okta for AI Agents) 集中ゲートウェイ型 ロードマップ (一般提供時期は未定) 複数の MCP サーバーを集約し単一の仮想 MCP サーバーとして公開。通過するアクセスを監査ログ化
Netskope Netskope One Agentic Broker 集中ゲートウェイ型 一般提供 (2026年3月) Netskope を経由する外部 MCP 通信をリスク評価し、既定ブロックと DLP を適用
Netskope One AI Gateway (MCP Gateway 拡張) 集中ゲートウェイ型 一般提供 (2026年3月) 顧客管理環境に置く仮想アプライアンス。MCP 通信にアクセス制御・DLP・AI Guardrails・レート制限・監査ログを適用
CrowdStrike MCP proxy (Falcon AIDR のコンポーネント) クライアント側プロキシ型 OSS として公開中 (利用には AIDR for Agents 契約が必要) stdio 経由の MCP 通信を中継して検査・監査ログ化

Okta：複数の MCP サーバーを束ねる Agent Gateway

配置場所

Okta for AI Agents の追加機能としてリリースが計画されている Agent Gateway は、複数の MCP サーバーやツールを集約し、単一の仮想 MCP サーバーとして公開する集中ゲートウェイです。ホワイトペーパーでは、各ツール呼び出しの経路上に立つ ID ネイティブなコントロールプレーンとして説明されています。本記事ではこの公開資料の説明に基づき、集中ゲートウェイ型に分類します。

制御できること

ゲートウェイを通過するエージェントとリソース間のアクセスを Okta の ID・ポリシーと連携して認可し、監査ログに残します。

対象外のこと

下流サービス内部の呼び出しは監査の対象外と明記されています。また、すでに一般提供されている「個々の MCP サーバーを認可対象リソースとして登録する仕組み」は ID 基盤としての認可レイヤーであり、複数サーバーを束ねるゲートウェイとは別の機能です。

提供状況

ロードマップ段階です。2026年3月の発表以降、早期アクセスの発表では "Coming Soon"、4月の Okta for AI Agents 一般提供の発表でも "in the months ahead" という位置づけのままで、一般提供時期は現在のところ未定です。

Netskope：外部向けの Agentic Broker と社内向けの AI Gateway

配置場所

Netskope は2つの集中ゲートウェイを使い分けます。Agentic Broker は Netskope のクラウド基盤上にあり、Netskope を経由するよう設定された通信 (主に外部・公開 MCP サーバー向け) を統制します。AI Gateway は顧客管理環境に配置する仮想アプライアンスで、MCP Gateway 拡張により MCP クライアントとサーバーの間にインラインで入ります。AI トラフィックを外部クラウドへ送りたくない規制業界などの要望に応える製品です。

制御できること

Agentic Broker は外部 MCP サーバーをリスク評価し、既定ブロックを含むアクセス制御と DLP を適用します。AI Gateway の MCP Gateway 拡張は、アクセス制御・DLP・AI Guardrails・レート制限・監査ログを提供します (設定手順も公開されています)。

対象外のこと

どちらも通信を経由させる設計が前提のため、Netskope を経由しない直接接続は統制できません。

提供状況

両製品とも2026年3月に一般提供が始まっています (日本語プレスリリース)。一方、MCP Catalog などの一部拡張機能は公式ドキュメント上プライベートプレビューのため、導入検討時は必要な機能がどの段階にあるかの確認が欠かせません。

CrowdStrike：クライアント側で MCP 通信を中継する MCP proxy

配置場所

MCP proxy は、MCP クライアントと同じホストで動くクライアント側プロキシです。クライアントの設定ファイルでサーバー起動コマンドの前に差し込む形で導入し、stdio 経由の MCP 通信を中継します。リモートの HTTP サーバーも stdio に変換すれば保護対象にできます。

制御できること

ツールポイズニング対策と監査ログを提供します。OSS (npm パッケージ) として公開されていますが、検査やログの機能は AIDR API への接続を前提としており、利用には AIDR for Agents サブスクリプションが必要です。

対象外のこと

名称にかかわらず集中型ではなく、各クライアント上で動作します。統制の対象は設定ファイルでラップした接続に限られ、設定していない接続やプロキシを外した直接接続は観測できません。なお CrowdStrike はシャドー AI の発見などブラウザ・クラウド側の監視機能も拡張していますが、いずれも MCP 通信のプロキシとは別の機能です。

提供状況

MCP proxy は OSS として公開中です。基盤製品の Falcon AIDR は2025年12月から一般提供されています。

fig-mcp-gateway-status-matrix-1-1

選定時に確認すること

ID 基盤とゲートウェイの役割の境界は製品ごとに異なります。検討の際は、次の5点をどの製品が担うかを整理すると、構成を比較しやすくなります。

  1. 誰がどの MCP サーバーに接続できるか (認可)
  2. 資格情報の仲介
  3. ツールの集約
  4. 通信内容の検査・DLP
  5. シャドー MCP サーバーの発見

たとえば Okta のエコシステムでは、パートナー企業の Operant MCP Gateway を Okta の ID 基盤と連携させ、ツール呼び出し単位で認可する構成が Okta Integration Network 上で提供されています。ID 基盤とゲートウェイを別レイヤーとして組み合わせるという視点が、実際の製品選定でも軸になります。

おわりに

本記事では、MCP のセキュリティを認可とゲートウェイという2つの制御点で整理しました。認可が決めるのは誰がどこに接続できるかまでで、通信の中身の統制はゲートウェイの領域です。実装には集中ゲートウェイ型とクライアント側プロキシ型があり、提供状況も Okta はロードマップ段階、Netskope は一般提供済み、CrowdStrike は OSS のクライアント側プロキシと差があります。自社のエージェントがどのような経路で MCP サーバーに接続しているかを踏まえ、前節の確認ポイントに沿って各製品の担当範囲を見極めることが、導入検討の第一歩になります。

参考：その他のベンダーの動き

同様の課題には、この3社以外のベンダーも取り組んでいます。主な動きは次のとおりです (2026年7月時点)。

企業 製品名 方式 提供状況 概要
Cloudflare MCP Server Portals 集中ゲートウェイ型 Open Beta MCP サーバーを登録し単一ポータル経由で配信。Zero Trust と統合し、Gateway 経由のルーティングを有効にすると DLP スキャンも適用可能。上流サーバーを Access の OAuth で保護しない場合、直接 URL からポータルを迂回した接続が可能
Palo Alto Networks Prisma AIRS MCP Server ツール組み込み型 提供中 (AIRS ライセンス) エージェント自身が呼び出す脅威スキャンツールを MCP サーバーとして提供。経路上のプロキシではない
Cisco AI Defense SDK 組み込み型ほか 一部提供 2025年12月の発表時点では多くの機能が開発中 (when-and-if-available)。2026年4月に Google Cloud 対応と ADK 連携を発表し、5月にツール呼び出しをコールバックで検査する実装を公開
Cisco Secure Access Agent Gateway 集中ゲートウェイ型 開発中 (when-and-if-available) 2026年6月発表。LLM・MCP サーバー・SaaS API・Web への通信経路上で共通ポリシーを適用し、資格情報をサーバー側で注入する構想
AWS Bedrock AgentCore Gateway 集中ゲートウェイ型 提供中 MCP クライアント・サーバー間の集中ゲートウェイ。OAuth の On-Behalf-Of トークン交換と Lambda インターセプタを提供
Microsoft Entra Agent ID / Defender for Cloud Apps / Purview DLP ID・CASB・DLP の組み合わせ 製品により異なる Entra Agent ID が MCP を利用するエージェントの ID・認証・認可を担う。既存の CASB・DLP は各データ面を補完するが、汎用的な MCP 通信の内容検査への対応は確認できていない

参考ドキュメント

本記事に記載の各製品の仕様・挙動については2026年7月時点の情報を基にしています。各製品とも提供状況・機能が流動的なため、導入検討時は一次情報での確認を推奨します。

AI セキュリティ対策に関するお問い合わせ

MCP や AI エージェントのセキュリティ統制に関するご相談は、ネクストモードまでお気軽にお問い合わせください。各製品の最新の提供状況を含めてご案内できます。

2025_SaaSLP_バナー