エージェント型AIの波は急速に加速しています。シンプルなツールを備えたチャットボットとして始まったものが、今や企業のワークフローに深く組み込まれた自律的なデジタルワーカーへと進化しています。
こうした導入が成熟するにつれ、重大なセキュリティ・ギャップがますます明らかになっています。
現在のエージェントアーキテクチャの多くは、ゴッドキーモデルと呼ばれる、広範で長期間のクレデンシャルがユーザーID、認証、ツールアクセスを単一の共有シークレットに統合したものに依存しています。
この方法では、安全に拡張することはできません。
大規模なエージェントの運用を目指す企業にとっては、委任されたアイデンティティとAIを意識した実施メカニズムへの移行が必要です。
以下では、実際の問題とプロダクショングレードのソリューションについて詳しく見ていきます。
1.真のリスク：過剰に特権化されたエージェント・クレデンシャル
LangChainスタイルのツール、カスタムMCPサーバ、内部ツールゲートウェイなど、初期のエージェント導入の多くでは、認証は静的なサービス認証情報を使用して管理されることがよくあります：
- 長期間のAPIキー
- シェアードサービスアカウント
- 幅広いOAuthクライアント認証情報
- または粗いワークロードアイデンティティ
明確にしておくと、MCP自体は静的な鍵を必要としません。プロトコルは、適切なOAuthと委任されたIDモデルをサポートしています。しかし、実際の実装では、多くのエージェントが、個々のMCPサーバと通信するために、オーバースコープされた非ユーザバウンドの認証情報を使用しています。
これがリスクの源です。
共有アイデンティティ問題（クロスユーザー帰属）
というシナリオを考えてみましょう：
- 50名の従業員が1社のマーケティングエージェントを利用
- エージェントは1つのサービスクレデンシャルを使ってGitHubを呼び出します。
この設定だと、GitHub のログには次のように表示されます：Agent_Service_Account deleted repo X.
何が足りないのか
- どの人間が行動を起こしたか
- ユーザーが許可されているかどうか
- その行動が予想されていたかどうか
監査とフォレンジックの観点からは、帰属が失われます。これは MCP の欠陥ではなく、多くのエージェント導入に存在する ID 伝達のギャップです。
許可範囲が広すぎる問題（クロスツールスコープ）
複数のツールを公開するMCPサーバーを考えてみましょう：
- 読み取りファイル
- リスト_ファイル
- 削除ファイル
エージェントが単一の広範なクレデンシャルで認証を行う場合、プロンプトのインジェクションやエージェントの誤動作が成功すると、よりリスクの高いツールが呼び出される可能性があります。MCPでは、サーバーがツールごとの認証を実施することができますが、今日の多くのMCPサービスは、主にツールの機能に重点を置いており、完全なエンタープライズ・ポリシーの実施ポイントとして機能するようには設計されていません。
これは、アーキテクチャ上の大きなギャップを生み出します。
2.アーキテクチャの現実：MCPサーバーはZTNAゲートウェイではありません
ほとんどの企業では、内部アプリケーションは、包括的な認証、認可、およびリスクポリシーロジックを自前で実装することは期待されていません。その代わりに、この責任は通常、エンタープライズ・アプリケーションの前に位置するゼロ・トラスト・ネットワーク・アクセス（ZTNA）レイヤに集中化されます。
MCPサービスも同じように考えるべきです。
実際には、多くのMCPサーバーが
- ツールの実行に集中
- 信頼できる上流のアイデンティティ
- 粗い認証またはサービスレベル認証の実装
- 深いユーザー/グループポリシーモデルの欠如
- トークン交換を行わない
- は、迅速なリスク決定に対応するようには設計されていません。
すべてのMCPサーバーが完全なゼロ・トラスト・エンフォースメント・エンジンとして機能することを期待するのは、現実的ではありませんし、拡張性もありません。
3.ZTNAがナチュラル・コントロール・ポイントである理由
ZTNAはすでに、以下のような形で、企業のセキュリティにおいて確立された役割を果たしています：
- 前面内部アプリケーション
- 認証の一元化
- アクセスポリシーの実施
- 単一の制御プレーンの提供
- アプリケーションチームの負担軽減
このモデルをMCPサービスに適用することで、企業は従来のアプリケーションとAI主導のツールアクセスの両方を保護する統一的なアプローチを実現できます。
従来のアプリとAI主導のツールアクセスの両方を保護する一貫した方法の1つです。
しかし、AIはZTNAソリューションに新たな要件をもたらします。
4.従来のZTNAではAIの行動が見えない
従来のZTNAソリューションは、以下のような要因に基づいて意思決定を行っていました：
- ユーザーID
- 装置姿勢
- ネットワークコンテキスト
- アプリケーションID
エージェント型AIのトラフィックは、次のような新たなリスク次元を追加します：
- 呼び出されるMCPツール
- 渡される引数
- リクエストがプロンプトで生成されたかどうか
- その行動がハイリスクかどうか
- ユーザがその特定のツールに対して権限を持っているかどうか
従来のZTNAソリューションでは、このレイヤーの制御を確認したり、強制したりすることはできません。MCPサービスを安全にフロントするためには、ZTNAはMCPプロトコルを認識し、AIを認識する必要があります。
必要なのはZTNAの代わりではなく、ZTNAの進化。
MCP対応ZTNA：求められる進化
従来のZTNAは、MCPサービスを含むエンタープライズ・アプリケーションの正しいアーキテ クチャ・フロントドアであり続けています。アプリケーションの外部にアクセス制御を一元化することで、拡張性、監査性、運用効率が向上することが証明されています。
しかし、エージェント主導のワークフローには、従来のZTNAでは対応できなかった2つの新しい要件があります：
ツール実行のためのユーザーレベル委任ID
MCPツールの動作をプロトコルレベルで可視化
これらの要件を満たすことがZTNAに取って代わるのではなく、ZTNAを進化させるのです。
MCPを意識したZTNAレイヤーは、IDの委譲とプロトコルを意識した認可という2つの重要な側面において、従来のゼロ・トラスト・モデルを拡張します。
委任されたアイデンティティトークン交換が必要な理由
AIエージェントがMCPツールを呼び出すとき、下流のサービスは基本的な質問に答えられなければなりません：
このアクションは、どの人間のために実行されていますか？
広範で長寿命のユーザ・トークンをすべてのMCPサービスに直接渡すことは、安全でもスケーラ ブルでもありません。トークンが悪用された場合、過剰な信頼の伝播と爆発半径の拡大が発生します。
代わりに、最新のゼロ・トラスト・アーキテクチャでは、委任されたIDを使用します。
このモデルでは
- ユーザがエンタープライズ IdP で認証
- エージェントはユーザのIDを伝播します。
- ZTNAエンフォースメントレイヤーは、ユーザーを検証します。
- 執行層はトークン交換を実行します。
- 特定のMCPサービス用に、短期間で限定された範囲のクレデンシャルを鋳造します。
このアプローチは、ダウンストリーム・サービスが要求された操作に必要な最小限の権限のみを受け取ることを保証します。
トークン交換の委任により、企業は次のようなことも可能になります：
- 一貫したライフタイム・コントロールの実施
- 観客の正常化
- トークンの爆発半径を縮小
- 完全なユーザー帰属を維持
しかし、アイデンティティだけでは十分ではありません。
MCPプロトコルの認識が重要な理由
完璧なアイデンティティがあっても、従来のZTNAではエージェントが実際に何をしているのかが見えません。
ネットワークの観点からは、MCP トラフィックは標準的な HTTPS として表示されます。プロトコルを認識しなければ、エンフォースメント・レイヤーは見ることができません：
- 呼び出されるMCPツール
- 渡される引数
- その行動がハイリスクかどうか
- ユーザがその特定のツールに対して認可されているかどうか
これが重要な盲点です。
MCPを意識したZTNAレイヤーは、プロトコルを深く解析し、抽出することができます：
- ツール名
- ツール引数
- セッションコンテキスト
- 利用者請求
これらのシグナルにより、単純なアプリケーションのアクセス決定をはるかに超える、きめ細かくAIを意識した認可ポリシーが可能になります。
アイデンティティの委譲とMCPレベルの検査の両方が実施されて初めて、エージェント型ワークフローの真の最小特権の実施が可能になります。
重要な実装の詳細：エージェントはユーザーIDを伝播しなければなりません
委任された ID がエンドツーエンドで機能するためには、エージェントランタイムがユーザ ID 情報を積極的に伝播する必要があります。現在の多くのデプロイメントでは、ユーザはフロントエンドで認証されますが（例えば、ZTNA や OIDC を使用）、ダウンストリームのツール呼び出しは静的なサービス認証情報を使用して行われます。このような場合、ユーザー属性が失われ、最小特権制御が機能しなくなります。
AI を意識したゼロ・トラストを有効にするには、エージェントまたはエージェント・フレームワークが、MCP またはツールの要求が、AI>Secure に向けて検証可能なユーザ・バインド・クレデンシャルを送信するようにする必要があります。この機能は、ほとんどのエージェントフレームワークでは自動的ではなく、一般的に明示的な設定と、場合によってはマイナーなコードの変更が必要です。
推奨される生産パターンデュアルアイデンティティヘッダー
AI>Secureの本番環境では、リクエストには通常、独立して検証可能な2つのIDが含まれます：
エージェントの身元
認証ベアラ
ユーザーID：
X-AI-User-Assertion：
上流への委任：
認証ベアラ
どちらのトークンも、ポリシー評価が行われる前にAI>Secureによって独自に検証されます。
代理店で何が変わるか（最小限）
ほとんどのエージェントフレームワークは、このパターンをサポートするためにわずかな変更しか必要としません：
- MCPエンドポイントをAI>Secureにポイントします。
- 既存のエージェントJWTの送信を継続
- ユーザーJWTを運ぶアウトバウンドヘッダを追加します。
OpenClawのような最新のフレームワークは通常、カスタムアウトバウンドヘッダーをサポートしているため、この移行は簡単です。MCPプロトコルの変更は必要ありません。
AI>Secureが最小特権を強制する方法
リクエストがAI>Secureに到達すると、以下のステップが発生します：
- エージェントの身元確認
- ユーザーIDの検証
- MCPトラフィックの解析
- きめ細かいポリシーが評価されます
- AI＞セキュアがトークン交換を実施
- 短時間の委任トークンが上流に送信されます。
リクエストを転送する前に、AI>Secureは元の認証情報を削除し、インジェクトします：
認証ベアラ
これにより、MCP サーバは適切にスコープされた ID のみを受信します。
AI>Secureが設定しなければならないもの
MCPサーバーごとのアップストリーム認証
各 MCP サーバに対して、AI>Secure は適切なアップストリーム認証方法を設定します：
- OAuthベアラ
- APIキー
- エムティーエルエス
- その他の対応方法
きめ細かな認証ポリシー
AI>セキュアポリシーを実施することができます：
- ツール許可/拒否ルール
- 弁論検査
- ユーザー/グループ制御
- リスクベース条件
アイデンティティ・ブローカーの構成
AI>Secure Identity Broker は以下のタスクを処理します：
- 受信ユーザトークンの検証
- 発行者と閲覧者の確認
- OAuthトークン交換の実行
- 短命な委任トークンの鋳造
- ターゲットMCPサービスへのトークンのスコーピング
- 寿命制限の実施
- 任意に変形する請求項
これらのメカニズムにより、MCP サーバは最小特権クレデンシャルのみを受け取り、複雑な ID ロジッ クを実装する必要はありません。
結論
課題は、MCPプロトコルの欠陥ではありません。核心的な問題は、初期（あるいは現在も）のエージェント導入の多くが、過剰に特権化され、適切な帰属を欠く認証情報に依存していることです。これらの認証情報は、過剰な権限を付与し、特定のアクションを実行したユーザやエージェントを明確に識別できません。その結果、MCP サービスは、その実装に過度な負担を強いることになり、扱うように設計されていないセキュ リティ管理とアクセスポリシーの実施を要求されることになります。
MCPサービスの前にAI対応のZTNAレイヤーを配置することで、企業は次のことが可能になります：
- アクセス制御の一元化
- ユーザー帰属の保持
- ツールごとの最小特権の強制
- MCPサービスの実装に過度の負担をかけないようにします。
ゼロ・トラスト・アーキテクチャをAI時代に適応させる組織は、デジタル従業員を安全に拡大するために最適な立場にあります。自律的なエージェントの時代には、Zero Trustは、誰が接続できるかにとどまらず、AIが実際に何を行うことができるかにまで拡大する必要があります。