OktaのAgent Gatewayを活用し、ランタイムでAIエージェントを保護

貴社の環境でAIエージェントが今すぐ不正な動作をした場合、誰のために、何に、いつアクセスしたかを特定できますか？多くのセキュリティチームは、それができていません。

AIエージェントは、それを管理するための統制が追いつかないほどの速さでリリースされています。 ゲートウェイはエージェントをツールに接続できます。しかし、エージェントが誰の代理として機能しているかを答えられる人は多くありません。 これは攻撃者に悪用される可能性のあるギャップであり、すでに何らかの問題が発生した後でなければ表面化しません。

ゲートウェイはコントロールとして販売されていますが、そのほとんどはリクエストの背後にいるのが誰なのかを実際に検証することはできません。それがなければ、何も制御していません。渡された権限を使って呼び出しをルーティングし、発生した事象をログに記録するだけです。アイデンティティを基盤としなければ、ゲートウェイは適用すべきルールも、帰属を特定すべきエージェントも、適用すべきガバナンスもない、単なるチェックポイントになってしまいます。

OktaのAgent Gatewayがそのギャップを埋めます。Okta for AI Agents内のランタイム適用レイヤーです。AIエージェントが外部のModel Context Protocol（MCP）を呼び出すように構成できる場所であればどこでも、Agent Gatewayがエージェントからツールへのすべての呼び出しをポリシーに照らして検証し、アクションの実行時に認証情報を分離して、統合された監査証跡を生成します。

Okta for AI AgentsはAgent Gatewayを中心に、アイデンティティとガバナンスの基盤を追加します。これには、エージェントのディスカバリー、第一級のアイデンティティとしての登録、アクセスワークフロー、認定キャンペーン、システム間の監査の関連付けが含まれます。Agent Gatewayは、Okta for AI Agentsの一部として本日より一般提供が開始されました。これにより、セキュアなエージェンティック企業のための設計指針にある、「エージェントは何をしているのか」という3つ目の問いに答えることができます。

本ブログ記事では、ほとんどのエージェントゲートウェイが抱える重要な問題の1つについて解説します。その問題とは、エージェントゲートウェイはエージェントをツールに接続できるものの、エージェントが誰の代理として機能しているかは検証できない、というものです。また、OktaのAgent Gatewayがどう違うかについても解説します。OktaのAgent Gatewayは、認証情報でユーザーとその背後のエージェントの両方が指定されていない限り、呼び出しを処理しません。これにより、権限が誤って借用、共有、または継承されるのを防ぐことができます。

従来のMCPゲートウェイがAIエージェントのセキュリティを確保できない理由

従来のMCPゲートウェイは、エージェントのリクエストをツールにルーティングできますが、多くの場合、重要な保護機能が欠けています。つまり、エージェントが誰の代理として機能しているかを検証できません。

混乱した代理の脆弱性とは

まず、エージェントにゲートウェイがない場合のシナリオの例を見てみましょう。

• 幅広い認証情報のプロビジョニング：従業員記録に関する質問に回答する人事アシスタントをチームが構築します。誰からの要求にも対応できるように、すべてのリソースへの読み取りアクセス権を持つサービスアカウントを付与する人がいます。
• 不正なユーザーリクエスト：Katieは契約社員です。彼女はエージェントにCEOの報酬を尋ねます。
• ポリシーのバイパス：エージェントは、正当に保持しているアクセス権を使用して、それを彼女に渡します。
• 監査の失敗：監査ログでは、リクエストは完全にクリーンに見えます。

情報は何もハッキングされていません。Katieとそのデータの間にあったのは、エージェント自身の判断だけでした。

これが混乱した代理（confused deputy）問題です。リクエストにはユーザーのクエリは含まれますが、権限は含まれません。エージェントは、要求した人が実際に知ることを許可されている内容ではなく、自身がアクセスできる内容に基づいて動作します。これは権限の仕組みに何十年も前から存在する欠陥であり、エージェントに広範なアクセス権を与え、自己管理を任せた場合にまさに露呈する問題です。

従来のMCPアーキテクチャの限界

一括失効

共有ゲートウェイの認証情報を失効させると、接続されているすべてのエージェントのアクセスが切断されます。そのため、管理者は過度に広範な権限を持つ認証情報を永続的にアクティブにするようになってしまいます。

• 管理者は、1つの共有認証情報を使用して、GitHub MCPサーバーに接続されたゲートウェイを構成します。
• すべてのエージェントがそのゲートウェイ経由で接続し、同じ広範なアクセス権を継承します。
• 認証情報を失効させると、その認証情報を使用しているすべてのエージェントのアクセスが切断されます。
• その結果、誰も取り消さなくなります。

単一アイデンティティのベアラートークン

MCPは混乱した代理人の問題を念頭に設計されているものの、根本的な制約があります。MCPはOAuth 2.1ベアラートークンで実行されますが、このトークンは1つのアイデンティティしか指定できません。ゲートウェイはエージェントのトークンを渡すことができず、新しいトークンを作成する必要があります。そのため、ゲートウェイがGitHubに「これはKatieのコーディングエージェントで、Katieの代理として動作しています」と伝えたくても、不可能です。選択されたアイデンティティが、GitHubで認識される唯一のアイデンティティになります。

プロンプトエンジニアリングによる保護が機能しない

プロンプトでエージェントに報酬データには決してアクセスしないよう指示することで、この問題を修正できる可能性があります。おそらくそうはならないでしょう。しかし、その認証情報があれば依然としてすべてにアクセスできてしまうため、最も効果的な安全策はエージェントが「見ない」という選択をすることになりますが、これこそが元々の問題でした。

OktaのAgent Gateway：エンタープライズツールに接続するAIエージェント向けの、アイデンティティネイティブなランタイム適用

Okta for AI Agentsの新機能であるAgent Gatewayは、エージェントが何に接続でき、各アクション中に何を実行できるかを適用するランタイムコントロールポイントです。呼び出し元が、アクションを要求するユーザーとリクエストを行うエージェントの両者を指定する認証情報を提示しない限り、呼び出しは処理されません。アイデンティティを強制するというこの要件が、単にトラフィックを中継するだけのゲートウェイとの違いです。

一般的なゲートウェイは、何らかの対象が接続を許可されていることを認証できます。Agent Gatewayは、リクエストの対象ユーザー、動作しているAIエージェント、およびそのエージェントがユーザーの代理として動作する権限を付与されているかどうかを検証し、ツールが呼び出された時点でポリシーを適用します。

従業員のKatieに代わって、エージェントが呼び出しを行おうとしているとします。一部のゲートウェイは、プラットフォームキーで呼び出し元を認証し、ユーザーをパラメーターとして受け取ります：

このように構築されたゲートウェイでは、キーは検証できますが、Katie本人を検証することはできません。Katieの名前は、呼び出しを行った人物が入力したリクエスト内の単なるテキストにすぎないため、そのキーを持つ人は誰にでもなりすますことができます。

Agent Gatewayでは、この種の認証情報は一切受け付けません。その代わり、Agent GatewayはRFC 8693委任を実装しており、すべてのツール呼び出しにおいて、アイデンティティプロバイダーが発行した、2つの異なるアイデンティティクレームを含む認証情報を提示する必要があります。

• サブジェクト（sub）：アクションを要求している認証済みエンドユーザー
• アクター（act）：リクエストを実行する登録済みのAIエージェント

Agent Gatewayがすべての呼び出しで期待する内容は次のとおりです。

この呼び出しはsubに対するものであり、actは呼び出し元を示します。sub_profileは、呼び出し元がアプリケーションであり、エージェントであることを示します。

何も継承されないため、Agent Gatewayはユーザーを作成できません。その資格情報のsubは、この呼び出しでAgent Gatewayが代理で操作できる唯一のユーザーです。Agent GatewayがMCPサーバーの認証情報を必要とする場合、エージェントの認証情報をOktaと交換し、同じユーザーに紐付けられた認証情報を受け取ります。これは、RFC 8693で定義されている代理（on-behalf-of）セマンティクスに準拠しています。Oktaがその認証情報を返すことができるのは、ユーザーが管理者によって登録された接続を使用して、事前にMCPサーバーで同意しているためです。

そのため、エージェントがAgent Gatewayを説得して、他の誰かのために行動させることはできません。ケイティはまだ質問できます。しかし、Agent GatewayがKatieに紐付けられた認証情報を使用して彼女の代わりに動作するようになったため、エージェントはKatie自身が実行できることしか実行できなくなります。

アイデンティティエンフォースメント機能マトリックス

一般的に、ゲートウェイは受信したクレデンシャルにすでに含まれている情報にのみ基づいて動作します。その認証情報に実際のユーザーとエージェントのアイデンティティが含まれるか、あるいはまったく含まれないかは、認証情報が作成された瞬間に決定されます。

OktaのAgent Gatewayは3行目でのみ動作します。認証情報が、ユーザーとエージェントの両方を指定する検証済みの委任トークンでない限り、呼び出しは処理されません。

効果的なエージェントアクセスルール

実際には、エージェントが実際に実行できることは、Agent Gatewayの権限とユーザーの権限が厳密に一致する範囲に限定されます。

Agent Gatewayは、どのエージェントが呼び出しを行っているか、またどのツールが公開されているかを把握します。MCPサーバーは、自身のレコードと、それにアクセスできるユーザーを把握しています。どちらも不可欠です。

Agent Gateway自体は、独自のプリンシパルを持つ登録されたワークロードであり、何かにアクセスするための永続的な権限はありません。呼び出しが解決される前に、管理者は2つの項目を設定します。

1. 委任リンク：特定のエージェントに、ユーザーに代わってこのゲートウェイに委任する権限を付与します。それがない場合、エクスチェンジは拒否されます。
2. リソース接続：このゲートウェイに特定のMCPサーバーにアクセスする権限を付与し、そのサーバーのどのツールを公開するかを正確に定義します。

いずれの権限も、呼び出し元から推測されることも、エージェントの認証情報によって付与されることもありません。アクセスは、管理者が設定した委任およびリソースの権限に限定されます。

アイデンティティガバナンスは、コストガバナンスの基盤でもある

AIエージェントは、アクセスリスクを生み出すだけでなく、マシン級のスピードでコストを発生させる可能性があります。プレミアムAPIを繰り返し呼び出したり、コストのかかるワークフローをトリガーしたり、消費量の多いツールを起動したりするエージェントは、人間が気付くずっと前に予期せぬコストを発生させる可能性があります。

コストガバナンスは、帰属から始まります。複数のエージェントが1つの認証情報を共有している場合、「アクティビティを生成したのはどのエージェントか」といった基本的な問いに答えることは困難です。エージェントが誰の代理で行動していたのか、コストを押し上げたツールまたはリソースはどれかを把握することはできません。

OktaのAgent Gatewayは、こうした問いに答えるために必要なアイデンティティコンテキストを生成します。各リクエストはユーザーと、ユーザーに代わって動作するエージェントの両方に関連付けられているため、組織はエージェントのアクティビティと、それがアクセスするツールやリソースを関連付けることができます。これにより、エージェントの展開がスケールするのに合わせて、利用状況の監視、予期しないアクティビティの調査、ガバナンスの適用を行うための、より明確な基盤が構築されます。

近日公開：Agent Gatewayを介したCross App Accessのサポートとキルスイッチ

Agent GatewayのCross App Accessのサポート

エージェントは、SlackやSalesforceなどの一般的なSaaSアプリにアクセスする必要がありますが、Oktaではそのためのオープン標準プロトコルとしてCross App Accessを提供しています。サポート開始により、Cross App AccessはAIエージェントがユーザーに代わってアプリケーションに安全にアクセスできるようにし、両方のアイデンティティが維持されます。従業員がそれぞれ各アプリを承認する代わりに、管理者はエージェントが使用できるアプリを一度だけ承認します。

ゲートウェイを介してこれを行うことには、大きなメリットがあります。アプリごとにアクセスを管理するのではなく、一元的なコントロールポイントでエージェントのアクセスを有効または無効にできるからです。

Agent Gatewayは、近日中にCross App Accessをサポートする予定です。これにより、ゲートウェイは「このリクエストは、承認済みの権限付与によるものです」と提示し、そのアサーションを新しいトークンと交換できるようになります。アプリ側での変更は一切必要ありません。このメカニズムは、IETFのドラフト「Identity Continuation Assertion」で提案されています。

Agent Gatewayベースのキルスイッチ

最後に、すべてのツール呼び出しが単一のランタイム制御ポイントを通過するため、Agent Gatewayはリクエストをリアルタイムで停止できます。このキルスイッチ機能が利用可能になると、無効化されたエージェントに発行されたトークンを持つリクエストをすべて拒否することで、すでに発行済みのトークンも含めてエージェントを即座に無効化できるようになります。Oktaの境界で適用されるため、接続されている各アプリが個別にアクセス権を取り消すのを待つ必要はありません。

AIエージェントゲートウェイの評価方法：確認すべき4つの重要な質問

ゲートウェイの現状を把握するための4つの質問をご紹介します。

• 発行者の検証：MCPサーバーはどの認証情報を受け取りますか？誰が発行したものですか？
• ユーザーアイデンティティの証明：ゲートウェイは、どのユーザーに対する呼び出しかを示すことができますか？それとも、ユーザーは呼び出し元が指定するパラメーターですか？
• 同意の来歴：誰の同意に基づいて、エージェントはそのMCPサーバーへのアクセスを承認されましたか？
• バイパスのリスク：エージェントが、パスにゲートウェイがなくても機能する認証情報を保持することはありますか？

Agent Gatewayは、これら4つの質問すべてに対応するために構築されています。

Agent Gatewayは全体像の一部にすぎません。Okta for AI Agentsは、企業が展開するエージェントのセキュリティを確保するために必要な可視性、制御、ガバナンスを提供する、より広範なプラットフォームです。

Agent Gatewayは、Okta for AI Agentsで追加費用なしでご利用いただけます。

既存のお客様：アカウント担当者にご連絡いただければ、すぐにご利用を開始できます。

Okta for AI Agentsをまだご利用いただいていませんか？ Oktaのデータシートをダウンロードして、Okta for AI Agentsを活用して単一のコントロールプレーンからAIエージェントを安全に管理する方法をご確認ください。

本ブログで言及されている将来の製品、機能、仕様、認定に関する記述は、情報提供のみを目的としています。これらは提供を確約するものではなく、購買の意思決定を行う際に依拠すべきものではありません。

これらの資料は、一般的な情報提供のみを目的としており、法律、プライバシー、セキュリティ、コンプライアンス、またはビジネス上の助言ではありません。

このコンテンツは、最新のセキュリティ、法律、および/またはプライバシーの動向を反映していない可能性があります。 このコンテンツの利用者は、自身の責任において、自身の法的および/または専門的アドバイザーから助言を得るものとし、コンプライアンス、実装、購入の意思決定のために本資料の情報に依存すべきではありません。

Oktaは、本コンテンツに関していかなる表明または保証も行いません。また、これらの推奨事項を利用者が実装した結果生じたいかなる損失または損害についても、当社は一切責任を負いません。お客様に対するOktaの契約上の保証に関する情報は、okta.com/agreementsでご覧いただけます。