IAM 統合アクセス ポリシーの概要

Identity and Access Management（IAM）統合アクセス ポリシー（UAP）を作成すると、宛先エージェント、MCP サーバー、エンドポイントなどのエージェント プリンシパルと宛先リソース間の通信を安全に制御できます。これらのポリシーは、Agent Gateway インスタンスを含むプロジェクトにバインドされます。

Agent Gateway は、Identity-Aware Proxy（IAP）を使用して UAP を評価し、適用します。

また、IAP はコンテキストアウェア アクセスと統合して、エージェントの ID のエンドツーエンドの認証と認可を提供します。

Agent Gateway の UAP を設定するには、IAM UAP を構成するをご覧ください。

エージェント ID にプリンシパル アクセス境界（PAB）を作成することもできます。Agent Gateway は、IAP を使用してプリンシパル アクセス境界ポリシーを適用できます。

Agent Gateway を有効にする

エージェント通信ポリシーを使用するには、Agent Gateway を設定する必要があります。

ポリシーが想定どおりに動作していることを確認するには、ステージング環境で Agent Gateway をドライラン モード（DRY_RUN）で構成することをおすすめします。

ポリシーが正しく機能していることを確認したら、Agent Gateway の構成を更新して、自動適用モードを ENFORCE に設定します。このモードでは、ポリシーに違反するエージェント通信は禁止され、リソースへの通信はブロックされます。

UAP の概要

UAP は、1 つ以上のエージェント プリンシパルが 1 つ以上の宛先リソースにアクセスできるかどうかを制御します。UAP は、1 つのポリシーで複数のルールをサポートすることで、IAM ポリシーモデルを拡張します。IAM 許可ポリシーと拒否ポリシーとは異なり、UAP の各ルールには許可効果と拒否効果の両方を含めることができます。IAM ポリシータイプの詳細を確認する。

ルールには、Common Expression Language（CEL）で表現された条件も含まれています。条件は、ゲートウェイ後のリソースへのアクセスを制御する主要なメカニズムとして機能します。Agent Gateway と IAP で UAP を適用すると、企業全体にデプロイされたエージェントの動作を厳密に制御できます。実際のきめ細かいエージェント ガバナンスのユースケースを 1 つのポリシーで表現できます。

一般的なポリシーには、少なくとも 2 つの異なるルールが含まれています。

• 許可ルール: 許可ルールには、エージェント プリンシパルが特定の安全なオペレーション（ツールで読み取りオペレーションを実行してトラッキング データを取得したり、レジストリ エントリを表示したりするなど）にアクセスできるようにする許可効果があります。
• 拒否ルール: 拒否ルールには、エージェントが重要なリソースに対してコマンドされていない削除や更新オペレーションなどの不要なアクションを実行できないようにする拒否効果があります。

たとえば、顧客データベースへの特権アクセス権を持つ内部ツールとやり取りする必要がある自動カスタマー サポート エージェントについて考えてみましょう。管理者は、IAM UAP を適用するように IAP で Agent Gateway を構成します。管理者は、エージェント プリンシパルがサポート チケットを読み取ることを承認する許可ルールと、エージェント プリンシパルがデータベース レコードを削除または更新することを禁止する拒否ルールを使用して UAP を構成できます。

許可ルールと拒否ルールの両方を含む UAP を使用することで、組織は単一の企業コンプライアンス ポリシーを基盤となるクラウド インフラストラクチャに直接デプロイして、エージェントの動作を制限できます。

ベスト プラクティス

エージェントの下り（外向き）ポリシーを構成する際は、次のベスト プラクティスに従ってください。

• ドライラン モードを使用する: 新しいポリシーまたは変更されたポリシーを最初にドライラン モードでデプロイして、アクティブなエージェント トラフィックをブロックせずにポリシーが想定どおりに機能することを確認します。
• 最小権限の原則を適用する: 必要な権限のみを付与します。CEL 条件では、ワイルドカードではなく、特定のツール名またはパスを使用します。
• ガードレールに拒否ルールを使用する: 明示的な拒否ルールを使用して、本番環境のエンドポイントで破壊的なツールをブロックするなど、重要なガードレールを実装します。拒否ルールは許可ルールをオーバーライドするため、ガードレールに拒否ルールを使用すると効果的です。
• 定期的な監査を実施する: Cloud Audit Logs のログとポリシー構成を定期的に確認して、組織のセキュリティ ポリシーに準拠していることを確認します。

UAP コンポーネント

UAP には 1 つ以上のルールが含まれています。ルールには次のコンポーネントがあります。

エージェント プリンシパル

IAM UAP で、1 つ以上のエージェント プリンシパルを定義します。エージェント プリンシパルは、アクセス権を付与するメンバーです。エージェントは、リソースとの通信を開始するエージェントの ID であるエージェント ID で指定します。さまざまなタイプのエージェントが ID を受け取る方法の詳細については、エージェント ID をご覧ください。エージェント ID は、エージェントの SPIFFE 形式の ID（principal://agents.global.org-... など）を含むプリンシパル IDで表されます。

個々のエージェント ID の配列またはプリンシパル セットの配列を指定できます。

組み込みのエージェント ID は、Agent Runtime（Reasoning Engine）、Gemini Enterprise（Discovery Engine）、エージェント ID で構成された Cloud Run サービスなどの Cloud de Confiance サービス全体でプロビジョニングされます。これらのエージェント プリンシパルは principal://TRUST_DOMAIN/AGENT_UNIQUE_IDENTIFIER という形式になります。ここで、識別子はホスティング サービス上のエージェントのリソースパスを表します。Workload Identity 連携プリンシパル ID を使用してエージェントを指定することもできます。

ルールの効果

ルール効果は、ルールでエージェント プリンシパルによるリソースへのアクセスを許可するか禁止するかを定義します。

宛先リソース

IAM UAP は、エージェント プリンシパルから宛先リソースへのアクセスを管理します。宛先リソースは、エージェント プリンシパルがアクセスしようとしているリソースです。宛先リソースは、ルールの条件で指定します。宛先リソースは、登録済みリソースまたは未登録リソースのいずれかになります。

登録済みリソース

登録済みリソースは、Agent Registry レジストリに登録されているリソースです。

登録されたリソースには次のものがあります。

• レジストリ: プロジェクト内のエージェント レジストリ全体。
• MCP サーバー: エージェント レジストリに登録されている MCP サーバー。
• エージェント: エージェント レジストリに登録されているエージェント。エージェント ID で個々のエージェントを個別に指定できます。エージェントのグループは、プリンシパル セット識別子で指定できます。
• エンドポイント: エージェント レジストリに登録されているエンドポイント。

個々のサービスは Agent Registry に登録できます。エージェント レジストリを地域化し、ルールが登録済みリソースへのアクセスを管理する場合、UAP はレジストリのリージョンにあるリソースにのみ適用されます。

登録されていないリソース

登録されていないリソースは、エージェント レジストリに登録されていないリソースです。UAP ルールで登録されていないリソースへのアクセスを許可または拒否するには、登録されていないホストとパスの属性を含む Common Expression Language（CEL）式を使用して、ルール条件で登録されていないリソースを指定する必要があります。

条件

UAP ルールでは、conditions ブロックで Common Expression Language（CEL）式を使用して、ターゲット リソースのスコープときめ細かいアクセス条件の両方を定義します。

• ターゲット リソースのスコープ: ルールが適用される宛先リソースを識別します。JSON 形式のポリシー ファイルで、destination.agent_registry.mcp_server.name や destination.unregistered.host などの宛先属性を指定します。 Cloud de Confiance コンソールで、[ターゲット リソース] で宛先を選択すると、これらのリソース条件がルールの条件式に自動的に追加されます。

• アクセス条件: ブール式を使用して、ルール効果が適用されるタイミングと制約を決定します。たとえば、UAP CEL 属性を使用して、ツール名、読み取り専用ステータス、HTTP メソッド、パス接頭辞に基づいてアクセスを制限できます。ルール効果（許可または拒否）は、CEL 式全体が true と評価された場合にのみ有効になります。

gcloud CLI と REST API では、これらの CEL 式をルール定義の conditions フィールドで指定します。

Cloud de Confiance コンソールでは、条件作成ツールを使用して標準ルールを構成するか、条件エディタでカスタム CEL 式を直接記述できます。

権限

IAM UAP を使用する IAP V2 では、宛先リソースに対して常に iap.googleapis.com/resources.egressViaIAP 権限が付与されます。gcloud CLI と REST API では、ポリシー ファイルの operation.permissions フィールドで権限を指定します。

ポリシー作成オプション

Cloud de Confiance コンソールの [ポリシー] ページで、IAM UAP を作成できます。UAP（IAM v3 ポリシー）のみを作成することをおすすめします。

gcloud CLI と REST API の両方で、最初に JSON 形式のファイルを作成して IAM UAP を構成できます。UAP のみを作成することをおすすめします。

エンドツーエンドの認証と認可

IAP とコンテキストアウェア アクセスは、次のプロトコルを使用して、デフォルトのエンドツーエンド エージェント ID の認証と認可を提供します。

• 相互 TLS（mTLS）
• 所有証明（DPoP）のデモンストレーション

エージェント ID には、X.509 証明書と証明書バインド トークンがプロビジョニングされます。IAP は、エージェント ID が相互 TLS（mTLS）を使用して Agent Gateway に対して認証を行うようにします。ゲートウェイがエージェントに下り（外向き）とアクセスを許可すると、エージェントは mTLS 境界外へのアクセスを試みます。 Cloud de Confiance API、MCP サーバー、他のエージェント、エンドポイント。通信を保護するため、コンテキストアウェア アクセスでは Google が管理するコンテキストアウェア アクセス ポリシーが適用されます。このポリシーでは、エージェント ID にバインドされた証明書バインド トークンを DPoP で検証する必要があります。コンテキストアウェア アクセスで mTLS と DPoP がどのように使用されるかについて詳しくは、コンテキストアウェア アクセス エージェントのセキュリティをご覧ください。

UAP CEL 属性

UAP では、条件式を使用して条件を定義できます。式には複数のサブ式を含めることができます。各関係サブ条件で使用する宛先リソースタイプによって、使用できる属性が決まります。

たとえば、次の条件では、サブ式 destination.unregistered.path.startsWith('/v1/statements') で、リソースタイプは登録されていない宛先、属性は destination.unregistered.path、startsWith() は CEL 関数です。

destination.unregistered.host == 'finance.example.com' &&
destination.unregistered.path.startsWith('/v1/statements')

次の表に示す属性は、各リソースタイプで使用できます。

次のステップ

• UAP の CEL 属性
• IAM UAP を作成する
• IAM UAP を管理する
• IAM UAP のトラブルシューティング