Agent Gateway の拡張可能なポリシー

エージェントが初期のプロトタイプからエンタープライズ デプロイにスケールするにつれて、内部統制、独自のデータ パイプライン、エンタープライズ セキュリティ ポリシーを統合する必要性が急速に高まります。複雑な認可の決定を、標準の IAM ポリシーだけで簡単に表現できない場合があります。

これらの要件に対応するため、Agent Gateway には新しいポリシー フレームワークが導入されています。これにより、Google サービス、カスタム認可エンジン、サードパーティのセキュリティ プラットフォームによる適用をサポートし、ゲートウェイ全体に同じポリシーを適用できます。このドキュメントでは、エージェント リスクの主なユースケースの概要と、拡張可能なポリシーを構成する方法について説明します。

エージェント リスクに関するポリシー拡張のユースケース

標準的な決定論的制御は、確率論的な AI ワークロードには不十分なことがよくあります。拡張可能なサービス パイプラインを使用すると、組織は、エージェント固有のリスクに合わせて高度なロジックを挿入できます。

  • コンテンツのサニタイズと安全ガードレール: プロンプト インジェクション、ジェイルブレイク、有害な出力、機密情報の損失から保護します（Model Armor の使用など）。
  • データ損失防止（DLP）: ペイロードとストリーミング チャンクをリアルタイムでモニタリングし、独自のコードや PII の外部システムへのデータ漏洩を防ぎます。
  • ゼロトラスト ID ガバナンス: エージェントが機密性の高いバックエンドや外部ツールにアクセスする前に、認証情報を検証し、アクセス制御を適用します（IAP の使用など）。
  • カスタム エンタープライズ コンプライアンス: 内部アーキテクチャに固有のカスタム データ削除ルール、トークン変換、コンプライアンス メカニズムを適用します。

Agent Gateway のポリシー拡張性フレームワーク

Agent Gateway を使用すると、拡張機能バインディングをアタッチして、認可の決定を ID プロバイダ、コンテンツ セーフティ フィルタ、カスタムのサードパーティ セキュリティ プラットフォームなどの専用 Policy Engine に委任できます。

Gemini Enterprise Agent Platform のポリシー拡張性フレームワーク。
Gemini Enterprise のポリシー拡張性フレームワーク。

ポリシー拡張性フレームワークは、ロールとリソースの分離に基づいて動作します。

  • コンシューマー: 最小限の構成作業でゲートウェイにセキュリティとガバナンスの拡張機能を追加したい Agent Gateway オペレーター。

  • プロデューサー: 内部プラットフォーム チーム、1P Google サービス（IAP や Model Armor など）、サードパーティ ISV パートナー。他のユーザーが使用できるようにサービス拡張機能を構築して公開します。

  • ExtensionBinding: コンシューマによって作成されたリソース。ProducerExtension をターゲット Agent Gateway にバインドし、拡張機能が呼び出されるタイミングを決定する一致条件も指定します。これは、コンシューマーが拡張機能の使用を開始するために作成する必要がある唯一のリソースです。

  • ProducerExtension: ext_proc 互換の認可エンジンを単一のマネージド ユニットにパッケージ化する、プロデューサーによって作成されたリソース。すべての基盤となる実行パラメータと接続設定がカプセル化されるため、コンシューマは低レベルのデータプレーン メカニズムを構成する必要がありません。

組み込みの Google 拡張機能

IAP や Model Armor などのファーストパーティ（1P）Google サービスは、効率化された運用モデルで、事前パッケージ化された拡張機能を提供します。

Google サービス用の拡張機能バインディング。
Google サービスの拡張機能バインディング（クリックして拡大）
  • コンシューマ: アプリケーション デベロッパーとセキュリティ運用担当者がコンシューマとして機能します。ゼロトラスト認証またはプロンプト インジェクション保護を有効にするには、コンシューマ プロジェクトから直接 Google の事前定義されたサービス エンドポイント URI をターゲットとする ExtensionBinding リソースを作成します。
  • プロデューサー: Google がプロデューサーとして機能します。Google は、基盤となる Service Infrastructure と拡張機能エンドポイント（iap.googleapis.com や modelarmor.us.rep.googleapis.com など）をグローバルに構築、ホスト、管理します。ProducerExtension リソースを作成または管理する必要はありません。

エンタープライズ拡張機能とパートナー（2P/3P）拡張機能

Custom Governance ロジックの場合、ポリシーの拡張性により、エンタープライズ チームとセキュリティ パートナー間で柔軟な双方向の統合モデルを実現できます。

2P/3P サービス用の拡張機能バインディング。
2P/3P サービスの拡張機能バインディング（クリックして拡大）

  • プロデューサー: 内部のプラットフォーム エンジニアリング チーム（2P）またはサードパーティの ISV セキュリティ ベンダー（3P）がプロデューサーとして機能します。プロデューサーは、Envoy の ext_proc プロトコルと互換性のある gRPC サービスを構築し、専用のプロデューサー プロジェクト（アプリケーション ロードバランサの背後にある Cloud Run サービスなど）でホストします。また、Private Service Connect（PSC）サービス アタッチメントを使用して公開し、ProducerExtension リソースを公開します。

  • コンシューマー: コンシューマー プロジェクト全体のアプリケーション デベロッパーとセキュリティ管理者がコンシューマーとして機能します。プロデューサーが PSC を使用してアクセス権を付与すると、コンシューマーはプロジェクトに ExtensionBinding を作成し、特定の ProducerExtension リソース URI を参照して、ワークロードにカスタム制御（セマンティック ガバナンス ポリシーやサードパーティのファイアウォール ルールなど）を適用します。

デプロイ パターン

拡張機能バインディングは、柔軟なデプロイ パターンをサポートしています。これにより、すべてのトラフィック パスに一貫したガバナンスを適用し、エージェントのデプロイ場所に関係なく、ガバナンス ポリシーが同じように機能するようにできます。ExtensionBinding API は、すべての Agent Gateway デプロイモデルに一律に適用されます。

エンドツーエンドのトラフィック インターセプト パス

拡張機能バインディングを適用すると、エージェント エコシステム内の次の通信パスでトラフィックをインターセプトできます。

  • ユーザー → エージェント（上り（内向き））: Agent Gateway をターゲットとするエンドユーザーまたはクライアント アプリケーションからの受信リクエストをインターセプトして、ユーザー認証、ID ガバナンス、プロンプト インジェクションのサニタイズを適用します。
  • エージェント → ツール / MCP（下り（外向き））: エージェントから Model Context Protocol（MCP）サーバーまたは外部 API への発信呼び出しをインターセプトして、権限を検証し、ツール入力をサニタイズします。
  • エージェント → LLM モデル（下り（外向き））: プロンプトが基盤モデルに到達する前にスキャンし、モデルのレスポンスをフィルタリングして、データ損失や有害な出力を防止します。

  • エージェント → エージェント（A2A 下り（外向き））: 自律型エージェントがプロジェクト間で連携する場合に、エージェント間の通信を制御し、ポリシー境界を適用します。

クライアントからエージェントへ

拡張機能バインディングを使用したクライアントからエージェントへのトラフィック フロー。
拡張機能バインディングを使用したクライアントからエージェントへのトラフィック フロー（クリックして拡大）。

エージェントから任意の宛先へ

拡張機能バインディングを使用したエージェントから任意の場所へのトラフィック フロー。
拡張機能バインディングを使用したエージェントから任意の場所へのトラフィック フロー（クリックして拡大）。

コンシューマー: 拡張機能を Agent Gateway にバインドする

コンシューマー（アプリケーション デベロッパーやセキュリティ オペレーターなど）は、ExtensionBinding を作成して、ガバナンスとセキュリティ ロジックを Agent Gateway に接続します。このリソースは、ターゲット ワークロードを拡張機能にバインドし、拡張機能を呼び出すタイミングを正確に定義する一致条件を宣言します（たとえば、特定の外部ツールまたは MCP サーバーにバインドされたトラフィックをインターセプトします）。一致条件は、インラインで直接指定することも（このセクションの例を参照）、別の YAML ファイルで指定することもできます。

拡張機能プロバイダに応じて、消費は次の 2 つのパスのいずれかに従います。

1P コンシューマーの構成

IAP（IAP）や Model Armor などの Google サービスの場合、Google がバックエンド インフラストラクチャと登録をグローバルに管理します。コンシューマーは、特定の ProducerExtension リソース URI をターゲットにする必要はありません。これらのサービスをワークロードに直接バインドするには、事前定義されたエンドポイント文字列（iap.googleapis.com や modelarmor.us.rep.googleapis.com など）を ExtensionBinding のターゲットとして渡します。

IAP 拡張機能を Agent Gateway にバインドする

次の例は、コンシューマ プロジェクトで 1P Google サービス（IAP）を Agent Gateway にバインドする ExtensionBinding リソースを示しています。指定された matchConditions フィールドに基づいて、トラフィックが MCP サーバーに送信されるときにこの拡張機能が呼び出されます。

  1. 次の構成を含む YAML ファイルを作成します。

    name: EXTENSION_BINDING_NAME
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
matchConditions:
- to:
    destination:
      resources:
      - prefix: "urn:mcp"
producerExtension: "iap.googleapis.com"

    次のように置き換えます。

    • EXTENSION_BINDING_NAME: 拡張機能バインディング リソースの名前。
    • PROJECT_ID: 実際の Cloud de Confiance by S3NS プロジェクト ID。
    • LOCATION: ゲートウェイと拡張機能バインディングのロケーション。
    • AGENT_GATEWAY_NAME: ターゲット Agent Gateway の名前。

  2. 拡張機能のバインディング構成をインポートします。

    gcloud beta service-extensions extension-bindings import EXTENSION_BINDING_NAME \
 --location=LOCATION \
 --source=EXTENSION_BINDING_FILE_PATH

    EXTENSION_BINDING_FILE_PATH は、YAML 構成ファイルのパスに置き換えます。

Model Armor 拡張機能を Agent Gateway にバインドする

プロンプト インジェクション、有害なコンテンツ、機密データの漏洩からエージェントを保護するには、Model Armor をワークロードに直接バインドします。指定された matchConditions フィールドに基づいて、トラフィックが MCP サーバーに送信されるときにこの拡張機能が呼び出されます。

  1. 次の構成を含む YAML ファイルを作成します。

    name: EXTENSION_BINDING_NAME
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
matchConditions:
- to:
    destination:
      resources:
      - prefix: "urn:mcp"
producerExtension: "modelarmor.us.rep.googleapis.com"
failOpen: true
producerMetadata:
  model_armor_settings: '[{
    "request_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID",
    "response_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID"
  }]'

    次のように置き換えます。

    • EXTENSION_BINDING_NAME: 拡張機能バインディング リソースの名前。
    • PROJECT_ID: 実際の Cloud de Confiance プロジェクト ID。
    • LOCATION: リソースのロケーション。
    • AGENT_GATEWAY_NAME: ターゲット Agent Gateway の名前。
    • TEMPLATE_PROJECT_ID: Model Armor テンプレートが配置されているプロジェクト ID。
    • REQUEST_TEMPLATE_ID: リクエストの評価に使用される Model Armor テンプレートの ID。
    • RESPONSE_TEMPLATE_ID: レスポンスの評価に使用される Model Armor テンプレートの ID。

  2. 拡張機能のバインディング構成をインポートします。

    gcloud beta service-extensions extension-bindings import EXTENSION_BINDING_NAME \
 --location=LOCATION \
 --source=EXTENSION_BINDING_FILE_PATH

    EXTENSION_BINDING_FILE_PATH は、YAML 構成ファイルのパスに置き換えます。

2P/3P コンシューマーの構成

別の内部チーム（2P）または外部のサードパーティ ベンダー（3P）によって作成されたサービス拡張機能のコンシューマとして、コンシューマ プロジェクトにサービスの使用アクセス権が明示的に付与されていることを確認する必要があります。アクセスは、プロデューサーが Private Service Connect サービス アタッチメント構成を使用して制御します。アクセス権が付与されたら、プロデューサーから提供された特定の ProducerExtension リソース URI を ExtensionBinding で参照して、ワークロードをバインドします。

カスタム認可エンジンをバインドする

次の例は、2P/3P プロデューサー プロジェクトのカスタム拡張機能をコンシューマー プロジェクトの Agent Gateway にバインドする ExtensionBinding リソースを示しています。指定された matchConditions フィールドに基づいて、トラフィックがエージェントに送信されるときにこの拡張機能が呼び出されます。

  1. 次の構成を含む YAML ファイルを作成します。

    name: EXTENSION_BINDING_NAME
target:
  resources:
  - "projects/CONSUMER_PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
matchConditions:
- to:
    destination:
      resources:
      - prefix: "urn:agent"
producerExtension: "projects/PRODUCER_PROJECT_ID/locations/LOCATION/producerExtensions/PRODUCER_EXTENSION_NAME"

    次のように置き換えます。

    • EXTENSION_BINDING_NAME: 拡張機能バインディング リソースの名前。
    • CONSUMER_PROJECT_ID: Agent Gateway をホストするコンシューマー プロジェクトのプロジェクト ID。
    • LOCATION: リソースのロケーション。
    • AGENT_GATEWAY_NAME: ターゲット Agent Gateway の名前。
    • PRODUCER_PROJECT_ID: ProducerExtension をホストするプロデューサー プロジェクトのプロジェクト ID。
    • PRODUCER_EXTENSION_NAME: ProducerExtension リソースの名前。

  2. 拡張機能のバインディング構成をインポートします。

    gcloud beta service-extensions extension-bindings import EXTENSION_BINDING_NAME \
 --location=LOCATION \
 --source=EXTENSION_BINDING_FILE_PATH

    EXTENSION_BINDING_FILE_PATH は、YAML 構成ファイルのパスに置き換えます。

拡張機能バインディングのアタッチメント ポイント

拡張機能バインディングは、ガバナンス要件に応じて、リソース階層のさまざまなレベルで構成できます。

  • Agent Gateway レベル: ポリシーを Agent Gateway リソースに直接接続して、ゲートウェイを通過するすべてのトラフィックを管理します。
  • プロジェクト レベル: プロジェクト内の特定のタイプのすべてのリソースにグローバルに適用される ExtensionBindings を作成します。これにより、プロジェクト全体のコンプライアンスを適用するエンタープライズ管理者の管理が簡素化されます。

プロジェクト内のすべての Agent Gateway に Model Armor 拡張機能をバインドする

  1. 次の構成を含む YAML ファイルを作成します。

    name: EXTENSION_BINDING_NAME
target:
  scope:
    parent: "projects/PROJECT_NUMBER"
    resourceTypes: "AGENT_GATEWAY"
matchConditions:
- to:
    destination:
      resources:
      - prefix: "urn:mcp"
producerExtension: "modelarmor.us.rep.googleapis.com"
failOpen: true
producerMetadata:
  model_armor_settings: '[{
    "request_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID",
    "response_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID"
  }]'

    次のように置き換えます。

    • EXTENSION_BINDING_NAME: 拡張機能バインディング リソースの名前。
    • PROJECT_NUMBER:Cloud de Confiance プロジェクトのプロジェクト番号。
    • TEMPLATE_PROJECT_ID: Model Armor テンプレートが配置されているプロジェクト ID。
    • LOCATION: リソースのロケーション。
    • REQUEST_TEMPLATE_ID: リクエストの評価に使用される Model Armor テンプレートの ID。
    • RESPONSE_TEMPLATE_ID: レスポンスの評価に使用される Model Armor テンプレートの ID。

  2. 拡張機能のバインディング構成をインポートします。

    gcloud beta service-extensions extension-bindings import EXTENSION_BINDING_NAME \
 --location=LOCATION \
 --source=EXTENSION_BINDING_FILE_PATH

    EXTENSION_BINDING_FILE_PATH は、YAML 構成ファイルのパスに置き換えます。

特定のワークロードに一致するリクエストの場合、プロジェクト レベルとリソースレベルの両方の拡張機能バインディングが実行されます。同じ拡張機能がリソースレベルとプロジェクト レベルの両方で構成されている場合、2 回呼び出されます。

拡張機能を呼び出す一致条件

一致条件は、拡張機能が呼び出されるタイミングを決定します。一致条件は、インラインで直接指定することも（このページの前の例を参照）、YAML ファイルで指定することもできます。

このセクションでは、トラフィック フロー、ターゲット リソース URN、宛先ホストに基づく一般的な状況の YAML ファイル構成の例を示します。

  • MCP ツールサーバーへの下り（外向き）（エージェント → ツール）: エージェントからリモートの Model Context Protocol（MCP）ツールサーバーに送信されるトラフィックをインターセプトします。

    # Invoke extension for all agent traffic to remote MCP servers
- to:
    destination:
      resources:
      - prefix: "urn:mcp"

  • 内向きトラフィック（ユーザー → エージェント）: Agent Gateway によって管理されるエージェントをターゲットとするエンドユーザーまたはクライアント アプリケーションからの受信リクエストをインターセプトします（たとえば、エンドユーザー認証やプロンプト インジェクションのサニタイズを内向きに適用するため）。

    # Invoke extension on incoming user requests targeting agents
- to:
    destination:
      resources:
      - prefix: "urn:agent"

  • LLM モデルへの下り（外向き）（エージェント → LLM モデル）: 宛先ホストを照合して、エージェントから基盤 LLM モデルまたはモデルサーバーに送信されたリクエストをインターセプトします。

    # Invoke extension on traffic sent to a specific model server
- to:
    destination:
      hosts:
      - exact: "myexamplemodelserver.com"

プロデューサー: 拡張機能を構築して公開する

カスタム（2P または 3P）プロデューサーとして、Private Service Connect アタッチメントの背後で ext_proc ベースのサービス拡張機能の実装をホストします。アタッチメントの準備ができたら、拡張機能が動作するリクエスト処理フェーズ、使用する認証局、ext_proc サービスの PSC アタッチメントの URI を指定して、ProducerExtension リソースを作成します。

gcloud beta service-extensions producer-extensions create PRODUCER_EXTENSION_NAME \
  --phase authz \
  --extension-settings=service=projects/PRODUCER_PROJECT_ID/regions/REGION/serviceAttachments/PSC_ATTACHMENT_NAME,authority="example.provider.net"

次のように置き換えます。

  • PRODUCER_EXTENSION_NAME: ProducerExtension リソースの名前。
  • PRODUCER_PROJECT_ID: プロデューサー プロジェクトのプロジェクト ID。
  • REGION: Private Service Connect サービス アタッチメントのリージョン。
  • PSC_ATTACHMENT_NAME: Private Service Connect サービス アタッチメントの名前。

Cloud Run でカスタム拡張機能をホストする

専用のクラスタや VM を管理せずにカスタム ext_proc gRPC サービスを実行したいプロデューサーにとって、Cloud Run は理想的なサーバーレスの代替手段です。

サーバーレス拡張機能を ProducerExtension として公開するには、Private Service Connect（PSC）を使用して公開します。ProducerExtension リソースには PSC サービス アタッチメント URI が必要であり、サービス アタッチメントは Cloud Run サービスを直接ターゲットにするのではなく、ロードバランサ転送ルールをターゲットにするため、Cloud Run サービスの前にアプリケーション ロードバランサ（サーバーレス NEG バックエンドを使用）を配置します。

Cloud Run の 2P サービス用の拡張機能バインディング。
Cloud Run の 2P サービスの拡張機能バインディング（クリックして拡大）。

Cloud Run で拡張機能をホストするためのデプロイ ワークフローの概要は次のとおりです。

  1. Cloud Run に拡張機能をデプロイする: カスタム ext_proc gRPC 拡張機能をコンテナ化されたサービスとして Cloud Run でホストします。

  2. サーバーレス NEG を作成する: Cloud Run で実行されている拡張機能を指すサーバーレス ネットワーク エンドポイント グループ（NEG）をデプロイします。

  3. サーバーレス NEG バックエンドを使用してロードバランサを設定する: サーバーレス NEG をバックエンドとして、VPC ネットワーク内にリージョン アプリケーション ロードバランサを設定します。

  4. PSC を使用してサービスを公開する: ロードバランサの転送ルールを直接参照する Private Service Connect サービス アタッチメントを作成します。これにより、一意のサービス アタッチメント URI（projects/.../regions/.../serviceAttachments/... など）が生成されます。

  5. プロデューサー拡張機能を作成する: 生成された URI を使用して、ProducerExtension リソースをインスタンス化します。

  6. コンシューマー ワークロードをバインドする: コンシューマーは、ProducerExtension リソース URI を参照して、ゲートウェイを拡張機能にバインドできるようになりました。

付録: カスタム拡張機能のコンテキスト メタデータ

カスタム拡張機能がコンテキストを認識した認可と処理の決定を行えるように、 Cloud de Confiance データプレーンはライフサイクルとリソースのコンテキストを ext_proc サーバーに直接渡します。

この情報は、ext_proc gRPC ProcessingRequest の metadata_context フィールド内に型なしメタデータとしてバンドルされます。このメタデータは com.google.serviceextensions.invocation_info 名前空間にあり、標準の google.protobuf.Struct 形式を使用します。

このメタデータをデコードするか、JSON に変換して、ダウンストリーム処理を行うことができます。MCP サーバーにバインドされたトラフィックを含む Agent Gateway をターゲットとするリクエストの JSON 形式の例は次のとおりです。

{
 "binding_selector" : {
   "target" : "//networkservices.googleapis.com/projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME",
   "project_number" : PROJECT_NUMBER,
   "to_resource": "urn:mcp:projects-PROJECT_NUMBER:projects:PROJECT_NUMBER:locations:LOCATION:agentregistry:services:SERVER_ID"
 }
}

JSON のスキーマは次のとおりです。

message ServiceExtensionsInvocationInfo {
  message ExtensionBindingSelector {
    // The target (gateway ID, etc) in fully qualified name format.
    // For example:
    // "//networkservices.googleapis.com/projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
    string target = 1;
    // Project number associated with the target.
    uint64 project_number = 2;
    // The destination resource within the Agent Registry that traffic is directed to.
    string to_resource = 3;
  }
  ExtensionBindingSelector binding_selector = 1;
}