Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

Service Extensions を使用して認可を委任する

このページでは、Service Extensions を使用して、Agent Gateway の認可を Identity-Aware Proxy、Model Armor、その他のカスタム認可エンジンに委任する方法について説明します。

認可ポリシーと拡張機能

認可ポリシーを使用すると、Agent Gateway によって公開されたエンドポイントを通過するトラフィックに、一元化されたアクセス制御ポリシーとガバナンスポリシーを適用できます。複雑なアクセス制御、コンテンツの安全性、ガバナンスの決定を処理するために、Agent Gateway では、認可拡張機能を使用して認可ポリシーを構成できます。これにより、認可とコンテンツの安全性の決定を、選択した指定の認可エンジンに委任できます。

認可拡張機能は、Agent Gateway デプロイを通過するリクエストをインターセプトし、指定された認可サービスに対してリアルタイムの gRPC 呼び出しを行います。これにより、サービスはトラフィックが宛先に到達する前に、トラフィックの検査、変更、ブロックを行うことができます。Identity-Aware Proxy、Model Armor、セマンティックガバナンスポリシーなどの Google Cloud サービス、または任意のカスタム認証エンジンに認証を委任できます。

認可ポリシーは、ポリシープロファイルを使用して、認可拡張機能に送信されるトラフィックデータのタイプを決定します。

リクエストベースの認可（REQUEST_AUTHZ）: アプリケーションペイロードが処理される前に HTTP リクエストヘッダーを評価します。このプロファイルは、Identity-Aware Proxy への認可の委任など、ID 検証とアクセス制御に使用されます。
コンテンツベースの認可（CONTENT_AUTHZ）: 完全な HTTP リクエストとレスポンスのペイロードを評価します。このプロファイルは、コンテンツの詳細な検査と AI の安全性に使用されます。たとえば、プロンプトとレスポンスの安全性については Model Armor に、自然言語の制約の適用についてはセマンティックガバナンスポリシーに委任します。

カスタム認証エンジンは、ヘッダーを検査するか、アプリケーションペイロード全体を検査するかに応じて、REQUEST_AUTHZ 拡張機能または CONTENT_AUTHZ 拡張機能を使用できます。

リクエストベースのポリシーとコンテンツベースのポリシーに対して認証拡張機能を個別に構成することも、包括的なセキュリティのために両方をゲートウェイで組み合わせることもできます。推奨構成については、推奨される上り（内向き）と下り（外向き）の構成をご覧ください。

認可ポリシー、ポリシープロファイル、ユースケースの詳細については、認可ポリシーの概要をご覧ください。

推奨される上り（内向き）と下り（外向き）の構成

エージェントのライフサイクル全体で包括的なセキュリティを確保するには、次のマルチゲートウェイアーキテクチャパターンをおすすめします。

クライアントからエージェントへのゲートウェイ: クライアントからエージェントへの（上り）ゲートウェイは、単一の CONTENT_AUTHZ ポリシーのみをサポートします。つまり、上り（内向き）で Model Armor とセマンティックガバナンスポリシーを同時に使用することはできません。プロンプトインジェクション攻撃から保護するには、Model Armor CONTENT_AUTHZ ポリシーを使用することを強くおすすめします。ただし、代わりにセマンティックガバナンスポリシー拡張機能を使用する場合は、ゲートウェイで Model Armor が構成されていないことを確認する必要があります。他のタイプのサービス拡張機能は、上り（内向き）ゲートウェイではサポートされていません。
エージェントから任意の場所へのゲートウェイ: エージェントから任意の場所への（下り（外向き））ゲートウェイは、最大 4 つの認可ポリシーをサポートします。下り（外向き）ゲートウェイは REQUEST_AUTHZ ポリシープロファイルと CONTENT_AUTHZ ポリシープロファイルの両方をサポートしています。この上限内で、各タイプの複数のポリシーを構成できます。

次の構成をおすすめします。
- エージェント ID の承認を Identity-Aware Proxy（IAP）に委任する REQUEST_AUTHZ ポリシー。
- 機密データの漏洩を防ぎ、送信ツール呼び出しとレスポンスに自然言語の制約を適用するために、Model Armor またはセマンティックガバナンスポリシーにさらなる決定を委任する 1 つ以上の CONTENT_AUTHZ ポリシー。
ポリシーの評価方法の詳細については、下り（外向き）のポリシー評価をご覧ください。

このマルチゲートウェイトポロジにより、Model Armor は受信プロンプトをスクリーニングし、IAP、Model Armor、セマンティックガバナンスポリシーは送信レスポンスをスクリーニングします。

下り（外向き）のポリシー評価

下り（外向き）ゲートウェイに複数の認可ポリシーが構成されている場合、ポリシープロファイルタイプに従って順次評価されます。

REQUEST_AUTHZ（ヘッダーベース）ポリシー: これらのポリシータイプが最初に評価されます。たとえば、IAP 拡張機能は、呼び出し元エージェントの mTLS ID をチェックし、コンテンツが処理される前に IAM 許可ポリシーを検証します。リクエストがこのチェックに失敗すると、直ちに拒否されます。
CONTENT_AUTHZ（コンテンツベース）ポリシー: これらのポリシータイプは次に評価されます。リクエストがヘッダーベースのチェックに合格すると、ペイロードはコンテンツベースの認可拡張機能（セマンティックガバナンスポリシーエンジンなど）にストリーミングされ、コンテンツの詳細な検査とコンプライアンス評価が行われます。

始める前に

開始する前に、次の要件を満たしていることを確認してください。

Agent Gateway がデプロイされます。Agent Gatewayを構成するをご覧ください。
認可ポリシーをゲートウェイにアタッチするには、デプロイされた Agent Gateway リソースに対する networkservices.agentGateways.use IAM 権限が必要です。

拡張機能を使用して認可ポリシーを構成する

このセクションでは、認可とコンテンツの安全性の判断を Identity-Aware Proxy、Model Armor、その他のカスタムサービスに委任する認可ポリシーを構成する方法について説明します。

IAP に認可を委任する

リクエスト認可拡張機能を構成して、認可ポリシーのアクセス決定を IAP に委任できます。

次の手順では、Agent Gateway インスタンスの認可ポリシーを使用して認可拡張機能を構成する方法について説明します。

始める前に: リソースへのバインディングアクセスポリシーを無効にする（constraints/iam.managed.disableAccessPolicyBindings）マネージド組織のポリシー制約の適用をオフにします。デフォルトでは、このブール値制約は新しい組織で有効になっており、IAM 統合アクセスポリシーをリソースにバインドできなくなります。詳細については、ブール値ルールでポリシーを更新するをご覧ください。
エージェントとツールに必要な IAM 下り（外向き）ポリシーを作成します。詳細については、IAM エージェントポリシーを作成するをご覧ください。
Agent Gateway の作成時に（アクセス認可パラメータを使用して）IAP を有効にするには、Agent-to-Anywhere（下り）モードで Agent Gateway を構成するをご覧ください。
IAP を指すように認可拡張機能を構成します。
1. YAML ファイルで拡張機能を定義します。提供されているサンプル値を使用します。拡張機能をドライランの監査専用モードでデプロイして、認可ポリシーを適用せずにテストする場合は、metadata ブロック内の iamEnforcementMode フィールドを指定します。
```
cat >iap-request-authz-extension.yaml <<EOF
name: my-iap-request-authz-ext
service: iap.googleapis.com
failOpen: false
timeout: 1s
metadata:
  iapPolicyVersion: "V2"
EOF
```
  拡張機能をドライランの監査専用モードでデプロイして、認可ポリシーを適用せずにテストする場合は、metadata ブロック内の iamEnforcementMode フィールドを指定します。これにより、ポリシーを検証し、構成エラーによるトラフィックの中断のリスクを最小限に抑えることができます。
```
cat >iap-request-authz-extension.yaml <<EOF
name: my-iap-request-authz-ext
service: iap.googleapis.com
failOpen: false
timeout: 1s
metadata:
  iapPolicyVersion: "V2"
  iamEnforcementMode: "DRY_RUN"
EOF
```
  ポリシーの適用を開始する準備ができたら、metadata ブロックから iamEnforcementMode: "DRY_RUN" フィールドを削除します。
  
  注: 高度で機能性に優れた、きめ細かいアクセス制御には、統合アクセスポリシー（iapPolicyVersion: "V2"）を使用することを強くおすすめします。既存のゲートウェイで以前の許可ポリシー（iapPolicyVersion: "V1"）を置き換えるには、ポリシー UI に移動し、[統合アクセスポリシー] タブでルールを手動で再定義します。詳細については、IAM エージェントポリシーを作成するをご覧ください。
2. 認可拡張機能をインポートします。次のサンプル値を使用して gcloud service-extensions authz-extensions import コマンドを使用します。
```
gcloud service-extensions authz-extensions import my-iap-request-authz-ext \
    --source=iap-request-authz-extension.yaml \
    --location=LOCATION
```

同じプロジェクトで、決定を拡張機能に委任する認可ポリシーを構成します。

my-iap-request-authz-ext 拡張機能をゲートウェイに関連付ける認可ポリシーを定義します。提供されたサンプル値を使用します。

cat >iap-request-authz-policy.yaml <<EOF
name: my-iap-request-authz-policy
target:
  resources:
    - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
      - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-iap-request-authz-ext"
EOF

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

認可ポリシーをプロジェクトにインポートします。次のサンプル値を使用して gcloud network-security authz-policies import コマンドを使用します。
```
gcloud network-security authz-policies import my-iap-request-authz-policy \
    --source=iap-request-authz-policy.yaml \
    --location=LOCATION
```

Model Armor に認可を委任する

認可拡張機能を構成して、認可ポリシーのコンテンツセキュリティの決定を Model Armor に委任できます。

次の例は、Agent Gateway の認可ポリシーを使用して、このような認可拡張機能を構成する方法を示しています。

コンソール

Google Cloud コンソールを使用して Agent Gateway の Model Armor を有効にするには、次の操作を行います。

必要な Model Armor テンプレートを作成します。
Agent Gateway の作成中に Model Armor を有効にする（[Model Armor を有効にする] チェックボックスを使用）には、Agent Gateway を構成するをご覧ください。Model Armor テンプレートは、クライアントからエージェントへの通信モードとエージェントから外部への通信モードの両方でサポートされています。
Model Armor を使用する場合は、Model Armor テンプレートを使用するために必要な権限を Agent Gateway サービスアカウントに付与する必要があります。サービスアカウントの形式は service-PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com です。ここで、PROJECT_NUMBER はゲートウェイを作成したプロジェクトのプロジェクト番号です。

ゲートウェイとテンプレートが同じプロジェクトにある場合でも、この手順は必要です。次のロールを付与します。
- ゲートウェイを含むプロジェクトの roles/modelarmor.calloutUser ロールと roles/serviceusage.serviceUsageConsumer ロール。
- Model Armor テンプレートを含むプロジェクトの roles/modelarmor.user ロール。
この手順を完了するには、gcloud CLI を使用する必要があります。
```
gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/modelarmor.calloutUser
gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/serviceusage.serviceUsageConsumer
gcloud projects add-iam-policy-binding MODEL_ARMOR_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/modelarmor.user
```
次のように置き換えます。
- GATEWAY_PROJECT_ID: ゲートウェイを作成したプロジェクトのプロジェクト ID。
- GATEWAY_PROJECT_NUMBER: ゲートウェイを作成したプロジェクトのプロジェクト番号。
- MODEL_ARMOR_PROJECT_ID: Model Armor テンプレートを含むプロジェクトのプロジェクト ID。
Agent Runtime にゲートウェイを使用している場合、Agent Runtime サービスエージェントにもこれらの権限が必要です。Agent Gateway を介して Agent Runtime トラフィックをルーティングするをご覧ください。

gcloud

必要な Model Armor テンプレートを作成します。
Model Armor を使用する場合は、Model Armor テンプレートを使用するために必要な権限を Agent Gateway サービスアカウントに付与する必要があります。サービスアカウントの形式は service-PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com です。ここで、PROJECT_NUMBER はゲートウェイを作成したプロジェクトのプロジェクト番号です。

ゲートウェイとテンプレートが同じプロジェクトにある場合でも、この手順は必要です。次のロールを付与します。
- ゲートウェイを含むプロジェクトの roles/modelarmor.calloutUser ロールと roles/serviceusage.serviceUsageConsumer ロール。
- Model Armor テンプレートを含むプロジェクトの roles/modelarmor.user ロール。
```
gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/modelarmor.calloutUser
gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/serviceusage.serviceUsageConsumer
gcloud projects add-iam-policy-binding MODEL_ARMOR_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/modelarmor.user
```
次のように置き換えます。
- GATEWAY_PROJECT_ID: ゲートウェイを作成したプロジェクトのプロジェクト ID。
- GATEWAY_PROJECT_NUMBER: ゲートウェイを作成したプロジェクトのプロジェクト番号。
- MODEL_ARMOR_PROJECT_ID: Model Armor テンプレートを含むプロジェクトのプロジェクト ID。

Model Armor を指すように認可拡張機能を構成します。

YAML ファイルで拡張機能を定義します。提供されているサンプル値を使用します。

cat >ma-content-authz-extension.yaml <<EOF
name: my-ma-content-authz-ext
service: modelarmor.LOCATION.rep.googleapis.com
metadata:
  model_armor_settings: '[
    {
    "response_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/TEMPLATE_ID",
    "request_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/TEMPLATE_ID"
    }
  ]'
failOpen: false
timeout: 1s
EOF

認可拡張機能をインポートします。次のサンプル値を使用して、gcloud service-extensions authz-extensions import コマンドを使用します。
```
gcloud service-extensions authz-extensions import my-ma-content-authz-ext \
   --source=ma-content-authz-extension.yaml \
   --location=LOCATION
```

拡張機能を使用して認可ポリシーを構成します。
1. 拡張機能 my-ma-content-authz-ext を Agent Gateway に関連付ける認可ポリシーを定義します。
  エージェントから任意の宛先へ
  cat >ma-content-authz-policy.yaml <<EOF name: my-ma-content-authz-policy target: resources: - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME" policyProfile: CONTENT_AUTHZ action: CUSTOM customProvider: authzExtension: resources: - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-ma-content-authz-ext" httpRules: - to: operations: [ { "paths": [ { "prefix": "/" } ] } ] when: > request.headers['content-type'] == 'application/json' || request.headers['content-type'].startsWith('text/') EOF
  
  次の点にご注意ください。
  
  policyProfile の値は CONTENT_AUTHZ に設定されています。これは、カスタムポリシープロバイダがリクエスト本文を含むリクエストとレスポンスのトラフィックを処理することを示します。
  
  httpRules パラメータは、CEL 属性を使用して、評価のために Model Armor に転送する特定のトラフィックに一致する条件を作成する方法を示しています。この例では、ルールは application/json または text/ コンテンツタイプのすべてのトラフィックと一致します。このようなルールを使用して、Model Armor の評価を関連するトラフィックに制限することをおすすめします。これにより、サポートされている LLM API、MCP、A2A トラフィックを Model Armor に転送し、エージェントの gRPC 呼び出しなどの内部トラフィックを除外できます。
  クライアントからエージェントへ
  cat >ma-content-authz-policy.yaml <<EOF name: my-ma-content-authz-policy target: resources: - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME" policyProfile: CONTENT_AUTHZ action: CUSTOM customProvider: authzExtension: resources: - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-ma-content-authz-ext" EOF
  
  policyProfile の値は CONTENT_AUTHZ に設定されています。これは、カスタムポリシープロバイダがリクエスト本文を含むリクエストとレスポンスのトラフィックを処理することを示します。
2. 認可ポリシーをプロジェクトにインポートします。次のサンプル値を使用して gcloud network-security authz-policies import コマンドを使用します。
```
gcloud network-security authz-policies import my-ma-content-authz-policy \
  --source=ma-content-authz-policy.yaml \
  --location=LOCATION
```

カスタム認可拡張機能に認可を委任する

カスタム認可拡張機能を構成して、カスタムサービスに判断を委任できます。これらのカスタム拡張機能は、完全修飾ドメイン名（FQDN）のみをターゲットにできます。

FQDN ターゲットを使用する場合、拡張機能は TLS 暗号化で HTTP2 プロトコルを使用して、ポート 443 のエンドポイントと通信します。ただし、拡張機能はサーバー証明書を検証しません。したがって、セキュリティを強化するには、解決されたエンドポイントが VPC ネットワーク内にあることを確認する必要があります。また、Agent Gateway プロジェクトと VPC ネットワークの間に DNS ピアリングが設定されていることを確認します。

特定の FQDN（mycustomauthz.internal.net など）の認可ポリシーを使用して認可拡張機能を構成するには、次の例に示すように、拡張機能の YAML ファイルで service の値として指定します。この例では、FULL_DUPLEX_STREAMED 本文処理モードで ext_proc プロトコルを実装するサーバーが VPC ネットワークにデプロイされていることを前提としています。
```
cat >custom-authz-extension.yaml <<EOF
name: my-custom-authz-ext
service: mycustomauthz.internal.net
failOpen: false
timeout: 1s
EOF
```

カスタムサービスを指す認可拡張機能を作成します。

gcloud beta service-extensions authz-extensions import custom-authz-extension \
  --source=custom-authz-extension.yaml \
  --location=LOCATION

拡張機能を作成したら、認可拡張機能に決定を委任する CUSTOM 認可ポリシーを構成します。

  cat >authz-policy.yaml <<EOF
  name: authz-with-extension
  target:
    resources:
      - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
  policyProfile: CONTENT_AUTHZ
  action: CUSTOM
  customProvider:
    authzExtension:
      resources:
        - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/custom-authz-extension"
  EOF

認可ポリシーを作成します。

gcloud network-security authz-policies import authz-policy-with-extension \
--source=authz-policy.yaml \
--location=LOCATION

この例に示すように、CONTENT_AUTHZ プロファイルを使用して認可拡張機能を認可ポリシーに関連付けると、ゲートウェイはリクエストとレスポンスのペイロード（ヘッダーと本文）に対して拡張機能を呼び出し、エージェントトラフィックのコンテンツの詳細な検査、プロンプトガードレール、データサニタイズが可能になります。デフォルトでは、CONTENT_AUTHZ ポリシーは FULL_DUPLEX_STREAMED モードで Envoy ext_proc プロトコルを使用して、本文イベントを処理します。

IAP 認証と Model Armor ガードレールを組み合わせる

セキュリティを強化するには、REQUEST_AUTHZ ポリシープロファイルを含む CUSTOM 認可ポリシーと、CONTENT_AUTHZ ポリシープロファイルを含む別の CUSTOM 認可ポリシーを設定することをおすすめします。

次の例では、IAP を一元化されたリクエスト承認システムとして使用し、Model Armor を AI ガードレールとして使用しています。前の例で示したように、これらをサービス拡張機能に置き換えて、独自のカスタムソリューションを使用できます。

IAP に委任する REQUEST_AUTHZ 認可拡張機能と、拡張機能を指す認可ポリシーを構成します。

認可拡張機能を定義します。metadata の iapPolicyVersion フィールドは必須です。

cat >iap-extension.yaml <<EOF
name: iap-extension
service: iap.googleapis.com
failOpen: false
timeout: 1s
metadata:
  iapPolicyVersion: "V2"
EOF

認可拡張機能を作成します。

gcloud service-extensions authz-extensions import iap-extension \
--source=iap-extension.yaml \
--location=LOCATION

LOCATION は、拡張機能のリージョンに置き換えます。

拡張機能に委任する REQUEST_AUTHZ 認証ポリシーを構成します。

cat >authz-policy-request-authz.yaml <<EOF
name: authz-iap
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
    - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/iap-extension"
EOF

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

PROJECT_ID: プロジェクト ID。
LOCATION: リソースのロケーション。
AGENT_GATEWAY_NAME: Agent Gateway の名前。

認可ポリシーを作成します。

gcloud network-security authz-policies import authz-iap \
--source=authz-policy-request-authz.yaml \
--location=LOCATION

Model Armor に委任する CONTENT_AUTHZ 認可拡張機能と、拡張機能を指す認可ポリシーを構成します。

拡張機能を定義します。

cat >ma-extension-file.yaml <<EOF
name: ma-extension
service: modelarmor.LOCATION.rep.googleapis.com
metadata:
  model_armor_settings: '[
    {
    "response_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID",
    "request_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID"
    }
  ]'
failOpen: false
timeout: 1s
EOF

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

LOCATION: Model Armor テンプレートが存在するリージョン。
MODEL_ARMOR_PROJECT_ID: Model Armor テンプレートを含むプロジェクト ID。
RESPONSE_TEMPLATE_ID: レスポンステンプレートの ID。
REQUEST_TEMPLATE_ID: リクエストテンプレートの ID。

認可拡張機能を作成します。

gcloud service-extensions authz-extensions import ma-extension \
--source=ma-extension-file.yaml \
--location=LOCATION

拡張機能に委任する CONTENT_AUTHZ 認証ポリシーを構成します。

cat >authz-policy-content-authz.yaml <<EOF
name: authz-ma
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: CONTENT_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
    - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/ma-extension"
EOF

認可ポリシーを作成します。

gcloud network-security authz-policies import ma-authz-policy \
--source=authz-policy-content-authz.yaml \
--location=LOCATION

認可拡張機能が CONTENT_AUTHZ プロファイルに関連付けられている場合、リクエストとレスポンスのヘッダー、本文、トレーラーを含むすべての ext_proc イベントを受信します。ext_proc ベースの認可拡張機能がリクエスト時の認可とコンテンツベースの認可の両方を処理できる場合は、CONTENT_AUTHZ ポリシープロファイルを使用して 1 つの CUSTOM 認可ポリシーを構成することをおすすめします。このポリシーは、汎用的な認可拡張機能を指す必要があります。このアプローチにより、単一の拡張機能と ext_proc 接続を介して両方のタイプの認可が可能になり、レイテンシプロファイルを改善できます。

セマンティックガバナンスポリシーに認可を委任する

認可拡張機能を構成して、認可ポリシーのインテントゲーティングと自然言語制約の決定をセマンティックガバナンスポリシーエンジン（semanticGovernancePolicyEngine）に委任できます。

Policy Engine をプロビジョニングし、Agent Gateway に必要な CONTENT_AUTHZ 認可ポリシーと認可拡張機能バインディングを作成する方法については、Policy Engine を Agent Gateway に接続するをご覧ください。

MCP プロトコル属性に基づく認可

Agent Gateway は、リクエスト内の MCP プロトコルペイロードを解析し、抽出された属性を認可ポリシーで使用できるようにします。

特定のツールの名前などの MCP メソッドパラメータに基づいてアクセスを制限できます。このセクションでは、ALLOW ポリシーと DENY の 2 つの例を示します。

認可ポリシーを構成します。

ALLOW ポリシーの例

この例では、MCP サーバー上の特定のツールセットと基本プロトコル機能へのアクセスを許可しますが、プロンプトとリソースへのアクセスは許可しません。

ALLOW ポリシーを作成するときは、初期化、ロギング、完了、通知、ping などのアクセス固有でない MCP RPC が引き続き機能するように、baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS を指定してください。そうしないと、MCP セッションを確立できません。

cat >authz-policy-restrict-tools.yaml <<EOF
name: my-authz-policy-restrict-tools
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
httpRules:
- to:
    operations:
    - mcp:
        baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS
        methods:
        - name: "tools/list"
        - name: "tools/call"
          params:
          - exact: "get_weather"
          - exact: "get_location"
action: ALLOW
EOF

DENY ポリシーの例

この例では、Agent Gateway の背後にある MCP サーバーへのすべてのプロンプト/ メソッドアクセスを禁止しています。

cat >authz-policy-disallow-prompts.yaml <<EOF
name: my-authz-policy-disallow-prompts
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
httpRules:
- to:
    operations:
    - mcp:
        methods:
        - name: "prompts"
action: DENY
EOF

認可ポリシーを作成します。
```
gcloud network-security authz-policies import AUTHZ_POLICY_NAME \
--source=AUTH_POLICY_YAML_FILE_PATH \
--location=LOCATION
```
次のように置き換えます。
- AUTHZ_POLICY_NAME: 認可ポリシーの名前。
- AUTH_POLICY_YAML_FILE_PATH: 認可ポリシーの YAML ファイルのパス。
- LOCATION: リソースのロケーション。

制限事項

認可ポリシーを使用する場合は、次の制限事項が適用されます。

ゲートウェイあたりの認可ポリシーの最大数は、ゲートウェイモードによって異なります。
- Agent-to-Anywhere（下り（外向き））ゲートウェイの場合、ポリシープロファイル（REQUEST_AUTHZ または CONTENT_AUTHZ）に関係なく、ゲートウェイごとに最大 4 つの認可ポリシーを構成できます。
- クライアントからエージェントへの（上り）ゲートウェイの場合、最大 1 つの CONTENT_AUTHZ ポリシーを構成できます。
詳細については、推奨される上り（内向き）と下り（外向き）の構成をご覧ください。
CONTENT_AUTHZ プロファイルでカスタム認可拡張機能を使用する場合は、本文イベントの ext_proc プロトコルと FULL_DUPLEX_STREAMED モードをサポートする必要があります。
同じプロファイルを使用する複数のカスタム認可ポリシーを構成した場合、実行順序は保証されません。

また、認可拡張機能の制限事項の詳細については、次のセクションをご覧ください。

すべての拡張機能に適用される制限事項については、拡張機能の制限事項をご覧ください。
コールアウトに適用される制限事項については、コールアウトの制限事項をご覧ください。

次のステップ

Codelab

Service Extensions を使用して認可を委任する

認可ポリシーと拡張機能

推奨される上り（内向き）と下り（外向き）の構成

下り（外向き）のポリシー評価

始める前に

拡張機能を使用して認可ポリシーを構成する

IAP に認可を委任する

Model Armor に認可を委任する

コンソール

gcloud

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

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

カスタム認可拡張機能に認可を委任する

IAP 認証と Model Armor ガードレールを組み合わせる

セマンティックガバナンスポリシーに認可を委任する

MCP プロトコル属性に基づく認可

制限事項

次のステップ

Codelab: Agent Platform でエージェントワークロードを管理する

Monitor Agent Gateway

Agent Gateway のトラブルシューティング

Service Extensions を使用して認可を委任する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

認可ポリシーと拡張機能

推奨される上り（内向き）と下り（外向き）の構成

下り（外向き）のポリシー評価

始める前に

拡張機能を使用して認可ポリシーを構成する

IAP に認可を委任する

Model Armor に認可を委任する

コンソール

gcloud

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

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

カスタム認可拡張機能に認可を委任する

IAP 認証と Model Armor ガードレールを組み合わせる

セマンティック ガバナンス ポリシーに認可を委任する

MCP プロトコル属性に基づく認可

制限事項

次のステップ

Codelab: Agent Platform でエージェント ワークロードを管理する

Monitor Agent Gateway

Agent Gateway のトラブルシューティング

Service Extensions を使用して認可を委任する

セマンティックガバナンスポリシーに認可を委任する

Codelab: Agent Platform でエージェントワークロードを管理する