エージェント ランタイムのトラフィックをエージェント ゲートウェイ経由で転送する

このページでは、Agent Runtime トラフィックを Agent Gateway にルーティングする方法について説明します。Agent Gateway は、Gemini Enterprise Agent Platform エコシステムのネットワークとセキュリティの中核となるコンポーネントです。 ユーザーとエージェント間、エージェントとツール間、エージェント間のやり取りなど、すべてのエージェント インタラクションに対して、安全でガバナンスが適用された接続を提供します。

始める前に

  • Agent Runtime にエージェントをデプロイする方法を 理解しておいてください

  • Agent Gateway について学習します。 . Agent-to-Anywhere(外向き)モードで Agent Gateway を使用すると、ツール、モデル、API、他のエージェントへの外向きトラフィックとのすべての外向き通信を保護して管理できます。Client-to-Agent(内向き)モードでゲートウェイを使用して、エージェントにアクセスできるクライアントを制御します。ゲートウェイを使用すると、これらのインタラクションに適用する必要がある IAP ポリシーと Model Armor テンプレートを選択できます。

  • このワークフローを試すための専用のテスト プロジェクトを作成します。他の重要なワークロードにも使用するプロジェクトは使用しないでください。

制限事項

  • 特定のプロジェクトとリージョンでは、Agent-to-Anywhere(外向き)インスタンスと Client-to-Agent(内向き)インスタンスの Agent Gateway は 1 つずつしか存在できません。Agent Gateway を使用するように構成されている同じプロジェクトとリージョン内のすべての Agent Runtime エージェントは、これらの特定のゲートウェイ インスタンスを使用する必要があります。
  • エージェントで Agent Gateway が有効になっている場合、Security Command Center Agent Engine Threat Detection サービス は使用できません。
  • Runtime エージェントを Agent Gateway リソースからバインド解除することはできません。そのため、専用のテスト プロジェクトを使用してください。

Agent Runtime トラフィックを Agent Gateway にルーティングする

Agent Runtime トラフィックを Agent Gateway にルーティングする手順は次のとおりです。

  1. Agent Gateway リソースを作成し、必要に応じて承認ポリシーをアタッチします。ゲートウェイは、Agent-to-Anywhere(外向き)モードまたは Client-to-Agent(内向き)モードで作成できます。エージェントとゲートウェイは、同じプロジェクトとリージョンに作成する必要があります。手順については、Agent Gateway を設定するをご覧ください。

    ゲートウェイがデプロイのニーズを満たすように構成されていることを確認します。たとえば、エージェントに LLM アクセスが必要な場合は、このアクセスを許可するようにゲートウェイを構成して、Agent Runtime のデプロイが失敗する可能性を防ぎます。

  2. エージェントのデプロイ時にゲートウェイ リソースを指定します。たとえば、Agent Runtime にエージェントをデプロイするには、client.agent_engines.create を使用して、local_agent オブジェクトと任意の 構成を渡します。

    また、この例に示すように identity_type パラメータを使用して、Runtime インスタンスに エージェント ID が割り当てられていることを確認する必要があります。

    remote_agent = client.agent_engines.create(
      agent=local_agent,
      config={
          "agent_gateway_config": {
            "agent_to_anywhere_config": {"agent_gateway": AGENT_GATEWAY_TO_ANYWHERE_NAME},
            # "client_to_agent_config": {"agent_gateway": AGENT_GATEWAY_CLIENT_TO_AGENT_NAME}
          },
          "identity_type": types.IdentityType.AGENT_IDENTITY,
          # Other optional configuration ...
          # "requirements": requirements,
          # "gcs_dir_name": gcs_dir_name,
          # https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/runtime/agent-identity#opt-out-caa
          "env_vars": {
            "GOOGLE_API_PREVENT_AGENT_TOKEN_SHARING_FOR_GCP_SERVICES": False,
          }
      },
    )

    AGENT_GATEWAY_TO_ANYWHERE_NAME は、Agent-to-Anywhere(外向き)モードで作成した Agent Gateway のフルパスに置き換えます。例: projects/PROJECT/locations/REGION/agentGateways/AGENT_GATEWAY_ID

    Client-to-Agent(内向き)モードでゲートウェイを作成した場合は、代わりに client_to_agent_config フィールドを使用し、AGENT_GATEWAY_CLIENT_TO_AGENT_NAME を内向き用に作成した Agent Gateway のフルパスに置き換えます。

  3. エージェントとゲートウェイと同じプロジェクトとリージョンにある Agent Registry インスタンスにエージェントを登録します。詳細については、 エージェントを登録するをご覧ください。

承認された Agent Gateway に Agent Runtime を制限する

カスタムの組織のポリシー制約を作成して、エージェントのデプロイ時に使用できる対象の Agent Gateway リソースのセットを定義できます。

カスタムの組織のポリシー制約を作成する

この例では、事前承認されたゲートウェイのリストとの間のトラフィックのみを許可するカスタム制約を作成します。

Agent-to-Anywhere

  1. Agent-to-Anywhere モード(外向き)のカスタム制約を定義するには、constraint-agent-gateway-egress.yaml という名前のファイルを作成します。

    次の例では、Agent Gateway リソースが指定されている場合(フィールドが存在し、空でない場合)にのみオペレーションが許可され、指定されたゲートウェイが事前承認リストに含まれている場合にのみオペレーションが許可されることを condition フィールドで指定します。

    name: organizations/ORGANIZATION_ID/customConstraints/custom.allowlistedEgressAgentGatewaysForAgentEngine
    resource_types:
    - aiplatform.googleapis.com/ReasoningEngine
    condition: >-
    has(resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway) &&
    resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway != '' &&
    (resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway in [
      'projects/AGENT_PROJECT_ID_1/locations/REGION_1/agentGateways/AGENT_GATEWAY_ID_1',
      'projects/AGENT_PROJECT_ID_2/locations/REGION_2/agentGateways/AGENT_GATEWAY_ID_2',
    ])
    method_types:
    - CREATE
    - UPDATE
    action_type: ALLOW
    display_name: Restrict Reasoning Engine Egress to Approved Agent Gateways
    description: Reasoning Engines can only be bound to a pre-approved list of
    Agent Gateway instances. Binding to any other gateway is denied.
    

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

    • ORGANIZATION_ID: 組織 ID。
    • AGENT_PROJECT_ID: プロジェクト ID。
    • REGION: ゲートウェイが作成されたリージョン。
    • AGENT_GATEWAY_ID: ゲートウェイ ID。
  2. カスタム制約を適用します。

    gcloud alpha org-policies set-custom-constraint EGRESS_CONSTRAINT_PATH
    

    EGRESS_CONSTRAINT_PATH は、前の手順で作成したカスタム 制約ファイルのフルパスに置き換えます。

  3. 制約を適用する組織のポリシーを作成します。組織のポリシーを定義するには、policy-agent-gateway-egress.yaml という名前のポリシー YAML ファイルを作成します。この例では、この制約をプロジェクト レベルで適用しますが、組織レベルまたはフォルダレベルで設定することもできます。

    name: projects/AGENT_PROJECT_ID/policies/custom.allowlistedEgressAgentGatewaysForAgentEngine
    spec:
      rules:
      - enforce: true
    

    AGENT_PROJECT_ID は、実際のプロジェクト ID に置き換えます。

  4. 組織のポリシーを適用します。

    gcloud alpha org-policies set-policy EGRESS_POLICY_PATH
    

    EGRESS_POLICY_PATH は、前の手順で作成した組織のポリシー YAML ファイルのフルパスに置き換えます。ポリシーが有効になるまでに最大 15 分かかります。

Client-to-Agent

  1. Client-to-Agent モード(内向き)のカスタム制約を定義するには、constraint-agent-gateway-ingress.yaml という名前のファイルを作成します。

    次の例では、Agent Gateway リソースが指定されている場合(フィールドが存在し、空でない場合)にのみオペレーションが許可され、指定されたゲートウェイが事前承認リストに含まれている場合にのみオペレーションが許可されることを condition フィールドで指定します。

    name: organizations/ORGANIZATION_ID/customConstraints/custom.allowlistedIngressAgentGatewaysForAgentEngine
    resource_types:
    - aiplatform.googleapis.com/ReasoningEngine
    condition: >-
    has(resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway) &&
    resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway != '' &&
    (resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway in [
      'projects/AGENT_PROJECT_ID_1/locations/REGION_1/agentGateways/AGENT_GATEWAY_ID_1',
      'projects/AGENT_PROJECT_ID_2/locations/REGION_2/agentGateways/AGENT_GATEWAY_ID_2',
    ])
    method_types:
    - CREATE
    - UPDATE
    action_type: ALLOW
    display_name: Restrict Reasoning Engine Ingress to Approved Agent Gateways
    description: Reasoning Engines can only be bound to a pre-approved list of
    Agent Gateway instances. Binding to any other gateway is denied.
    

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

    • ORGANIZATION_ID: 組織 ID。
    • AGENT_PROJECT_ID: プロジェクト ID。
    • REGION: ゲートウェイが作成されたリージョン。
    • AGENT_GATEWAY_ID: ゲートウェイ ID。
  2. カスタム制約を適用します。

    gcloud alpha org-policies set-custom-constraint INGRESS_CONSTRAINT_PATH
    

    INGRESS_CONSTRAINT_PATH は、前の手順で作成したカスタム 制約ファイルのフルパスに置き換えます。

  3. 制約を適用する組織のポリシーを作成します。組織のポリシーを定義するには、policy-agent-gateway-ingress.yaml という名前のポリシー YAML ファイルを作成します。この例では、この制約をプロジェクト レベルで適用しますが、組織レベルまたはフォルダレベルで設定することもできます。

    name: projects/AGENT_PROJECT_ID/policies/custom.allowlistedIngressAgentGatewaysForAgentEngine
    spec:
      rules:
      - enforce: true
    

    AGENT_PROJECT_ID は、実際のプロジェクト ID に置き換えます。

  4. 組織のポリシーを適用します。

    gcloud alpha org-policies set-policy INGRESS_POLICY_PATH
    

    INGRESS_POLICY_PATH は、前の手順で作成した組織のポリシー YAML ファイルのフルパスに置き換えます。ポリシーが有効になるまでに最大 15 分かかります。

カスタムの組織のポリシー制約の使用方法の詳細については、 カスタム制約を作成するをご覧ください。

次のステップ

Codelab

Gemini Enterprise Agent Platform で Agent Gateway を使用してエージェント ワークロードを管理する方法を学習します。

ガイド

Agent Gateway の承認を IAP、Model Armor、または独自のカスタム承認サービスに委任する方法を学習します。

ガイド

Agent Gateway をモニタリングする方法を学習します。