Agenten-Gateway-Ausgang von Agent Runtime zu externem MCP

1. Einführung

In diesem Codelab geht es um die Agent Gateway-Ausgangsverwaltung für KI-Agenten, die auf externe MCP-Server (Model Context Protocol) zugreifen, die außerhalb von Google Cloud gehostet werden.

KI-Apps, von eigenständigen Chatbots bis hin zu autonomen Systemen mit Workflows mit mehreren Agenten, können externe Tools dynamisch aufrufen. Es ist wichtig, dass Agenten kontrollierten Zugriff haben, um Datenbanken abzufragen, Webinhalte abzurufen und Aktionen auszuführen. So können Sie sichere und produktive Agenten erstellen. In Unternehmensumgebungen ist die Sicherung der Ausführung von Agent-Tools jedoch eine Herausforderung. Wenn ein Agent direkten Netzwerkzugriff hat, können durch Prompt-Injection-Angriffe oder Modellhalluzinationen vertrauliche Daten exfiltriert oder destruktive Befehle ausgeführt werden.

Um autonome Agents im großen Maßstab zu verwalten, bietet Agent Gateway einen zentralen Zero-Trust-Durchsetzungspunkt, der direkt in die Architektur der Agent Platform integriert ist. Anstatt auf benutzerdefinierte Implementierungen zu setzen, die für jede Anwendung oder jeden Agentencode eindeutig sind, bietet Agent Gateway Netzwerkrouting, Agentenverwaltung und Laufzeitsicherheit auf Plattformebene.

Wenn das Agenten-Gateway im Ausgangsmodus (agent-to-anywhere) ausgeführt wird, werden alle ausgehenden Anfragen von Agenten, die für die Verwendung des Gateways konfiguriert sind, über das Gateway weitergeleitet. Jede Anfrage für die Arbeitslast eines Agenten wird mit der eindeutigen Agentenidentität authentifiziert und mit Identity-Aware Proxy (IAP)-Richtlinien autorisiert. MCP-Tool-Aufrufe werden dynamisch decodiert und auf die Einhaltung von Richtlinien geprüft. Sicherheitsadministratoren können detaillierte Berechtigungen zentral erzwingen, damit Agents nur genehmigte Endpunkte und Methoden aufrufen können.

Was Sie erstellen

  • Agent Gateway im Modus „Ausgehend“ (agent-to-anywhere)
  • IAP-Autorisierungserweiterung (Identity-Aware Proxy)
  • ADK-Agent für Agent Runtime mit Agentenidentität
  • Agent Registry mit Google API- und MCP-Endpunkten
  • Verbindung externer MCP-Tools zu öffentlichen Datasets von Data Commons
  • Autorisierungsrichtlinien mit IAM-Zugriffssteuerung

figure1

Abbildung 1. Codelab-Architektur

Lerninhalte

  • KI-Agenten-Gateway in einer strukturierten Konfigurationssequenz bereitstellen
  • Autorisierungsrichtlinien vom Probelauf- in den Erzwingungsmodus umstellen
  • Google API-Endpunkte und MCP-Server in der Agent Registry registrieren
  • Bedingte Autorisierungsrichtlinien basierend auf MCP-Protokollattributen verwenden
  • Agent Gateway-Logs prüfen, um die Ausgangssteuerung zu validieren

Voraussetzungen

  • Ein Google Cloud-Projekt mit aktivierter Abrechnung
  • IAM-Berechtigungen zum Bereitstellen von Netzwerkdiensten und Agent Platform-Ressourcen
  • Eine POSIX-kompatible Shell (bash oder zsh) mit installierter Google Cloud CLI (gcloud- und bq-Komponenten)
  • Befehlszeilentools: git, curl, jq (JSON-Prozessor), Python 3 und uv (Python-Paketmanager)
  • Ein kostenloser Data Commons-API-Schlüssel für den Zugriff auf Test-Datasets

2. Konzepte

Bereitstellungsreihenfolge

In diesem Codelab wird eine strukturierte Konfigurationsreihenfolge verwendet, damit Agents beim Initialisieren Zugriff auf die erforderlichen Ressourcen haben und die Verbindung bestätigt werden kann, bevor erzwungene Zugriffsrichtlinien angewendet werden.

In diesem Codelab wird die folgende Bereitstellungsreihenfolge verwendet:

  1. Im DRY_RUN-Modus starten:Achten Sie darauf, dass Agent-Anfragen erfolgreich am Gateway eingehen und durchlaufen werden (nur Prüfmodus).
  2. Alle Dienste registrieren:Registrieren Sie alle agentischen Komponenten in der Agent Registry und bestätigen Sie den Zugriff auf Agent-Tools.
  3. Autorisierungsrichtlinien erstellen:Erstellen und wenden Sie Autorisierungsrichtlinien an, um ausgehenden Traffic von Agents zu MCP-Servern und -Endpunkten zuzulassen.
  4. Zum ENFORCED-Modus wechseln:Aktualisieren Sie die Autorisierungserweiterungsrichtlinie, um Richtlinien zu erzwingen und nicht autorisierten ausgehenden Traffic zu blockieren.

figure2

Abbildung 2. Bereitstellungssequenz

Topologie für das Routing von ausgehendem Traffic

Der ausgehende Traffic des Agent-Gateways (agent-to-anywhere) fungiert als zentraler, Zero-Trust-Ausgangsproxy für agentische Arbeitslasten. Wenn ein Agent eine Anfrage an ein externes Tool oder eine externe API sendet, wird die ausgehende Anfrage von Agent Gateway abgefangen und anhand von Governance-Richtlinien ausgewertet, bevor sie an ihr Ziel weitergeleitet wird. In einer Google Cloud Agent Platform-Architektur bietet Agent Gateway Datenebenenkonnektivität für:

  • Private Netzwerke (VPC): Ausgehender Traffic, der auf interne Unternehmens-APIs, Microservices und Datenbanken ausgerichtet ist, die in privaten VPCs gehostet werden, sowie auf lokale oder cloudübergreifende Netzwerke, die über hybride Verbindungen erreichbar sind.
  • Externe Netzwerke (Internet): Ausgehender Traffic, der auf Webdienste von Drittanbietern, SaaS-APIs oder öffentliche Endpunkte ausgerichtet ist.
  • KI-Dienste und Agent Platform:Ausgehender Traffic, der auf verwaltete Google Cloud-APIs, Foundation Models, Google MCP-Endpunkte (z. B. BigQuery) und Plattform-Governance-Dienste (Agent Registry und IAP-Richtlinien) ausgerichtet ist.

figure3

Abbildung 3. Topologie für ausgehendes Routing von Agent Gateway

In diesem Codelab geht es um ausgehenden Traffic von einem benutzerdefinierten Agenten in der Agent Runtime, der auf einen externen MCP-Serverendpunkt eines Drittanbieters ausgerichtet ist, der über das Internet zugänglich ist.

MCP-Protokollprüfung

Der Agent Gateway-Ausgang (agent-to-anywhere) kann den Inhalt von MCP-Anfragen parsen und Zugriffsrichtlinien anhand von detaillierten Protokollattributen auswerten. Egress-Richtlinien für die Kommunikation zwischen Agent und MCP-Server können Bedingungen enthalten, die in Common Expression Language (CEL) ausgedrückt werden und bei jeder Anfrage zur Laufzeit erzwungen werden.

MCP-Aufrufe verwenden in der Regel das JSON-RPC-Wire-Protokollformat und den HTTP-Transport. Die Details der aufgerufenen MCP-Methode (z. B. tools/call), der Name des Zieltools und alle Argumente sind in der JSON-Nutzlast im HTTP-Text enthalten.

Das Attribut iap.googleapis.com/mcp.toolName wird von Agent Gateway extrahiert, indem der JSON-Body geparst wird, um die in der Anfrage angegebene Tool-ID zu finden.

Attribute wie iap.googleapis.com/mcp.tool.isReadOnly und mcp.tool.isDestructive werden normalerweise nicht in jedem Anfragetext gesendet. Stattdessen handelt es sich um Anmerkungen (Metadaten), die mit dem Tool verknüpft sind. Wenn Agent Gateway also toolName aus dem Textkörper extrahiert, wird die Tool-Definition und die zugehörigen Eigenschaften in Agent Registry nachgeschlagen, wo der toolspec.json-Inhalt registriert wurde.

figure4

Abbildung 4. MCP-Prüfung des Agent-Gateways

CEL-Ausdrücke, die in IAP IAM Conditions verwendet werden, haben das Standardformat api.getAttribute('iap.googleapis.com/ATTRIBUTE_NAME', 'DEFAULT_VALUE')== 'DESIRED_VALUE'.

In dieser Tabelle werden die Attribute für die Ausgänge von Agent Gateway beschrieben, die auf MCP-Serveranfragen angewendet werden können:

Attribut

MCP-Methode / ‑Standort

Beschreibung

mcp.toolName

tools/call (Text)

Im RPC-Payload angeforderte Zieltool-ID (z. B. "delete_instance")

mcp.tool.isReadOnly

Agent Registry (toolspec.json)

Gibt an, ob das Tool schreibgeschützt ist (seine Umgebung nicht ändert)

mcp.tool.isDestructive

Agent Registry (toolspec.json)

Gibt an, ob durch den Aufruf des Tools irreversible Änderungen oder Datenverlust auftreten können.

mcp.tool.isIdempotent

Agent Registry (toolspec.json)

Gibt an, ob die wiederholte Ausführung des Tools mit identischen Argumenten zum exakt gleichen Zustand führt.

mcp.tool.isOpenWorld

Agent Registry (toolspec.json)

Gibt an, ob das Tool über begrenzte interne Systeme hinaus auf das unbegrenzte öffentliche Internet zugreift.

Damit sind wir mit den Konzepten fertig. Weiter geht es mit dem Abschnitt Einrichtung.

3. Einrichtung

Erforderliche IAM-Rollen

Die folgenden Rollen sind erforderlich, um die Ressourcen in diesem Codelab zu erstellen:

Kategorie

Erforderliche IAM-Rolle (ID)

Beschreibung

API-Verwaltung

roles/serviceusage.serviceUsageAdmin

Google Cloud API-Dienste aktivieren

Netzwerk und Gateway

roles/networkservices.admin

KI-Agenten-Gateway bereitstellen

Service Extensions

roles/serviceextensions.admin

Routing-Erweiterungen konfigurieren

Netzwerksicherheit

roles/networksecurity.admin

Autorisierungsrichtlinien bereitstellen

Agent Registry

roles/agentregistry.admin

Zulässige Hosts für Kataloge

Vertex AI und Agents

roles/aiplatform.admin

Agent Runtime-Arbeitslasten bereitstellen

Richtlinien für ausgehenden Traffic

roles/iap.admin

roles/iap.egressor-Richtlinien anwenden

Cloud Storage

roles/storage.admin

Bereitstellungs-Staging-Buckets verwalten

Logs und Prüfung

roles/logging.viewer

Traces und Audit-Logs prüfen

Alternativ können Sie eine allgemeine einfache Rolle wie roles/admin oder die alte Rolle roles/owner verwenden.

Auf Ihr Projekt zugreifen

In diesem Codelab wird ein einzelnes Google Cloud-Projekt verwendet. Bei den Konfigurationsschritten werden die gcloud-Befehlszeile und Linux-Shell-Befehle verwendet.

Rufen Sie zuerst die Befehlszeile Ihres Google Cloud-Projekts auf:

Projekt-ID festlegen

gcloud config set project SET_YOUR_PROJECT_ID_HERE

Sitzung authentifizieren

# login to gcloud cli
gcloud auth login
# login for gcloud api
gcloud auth application-default login

Shell-Umgebungsvariablen festlegen

# set custom var for slug (eg, "foo") and region preference
export SLUG="foo"
export REGION="us-central1"
export MREGION="us"
echo ${SLUG}
echo ${REGION}
echo ${MREGION}
# create project vars (automatic)
export PROJ_ID=$(gcloud config list --format="value(core.project)")
export PROJ_NO=$(gcloud projects describe ${PROJ_ID} --format="value(projectNumber)")
export ORG_ID=$(gcloud projects get-ancestors ${PROJ_ID} --format="value(id)" | tail -n 1)
echo ${PROJ_ID}
echo ${PROJ_NO}
echo ${ORG_ID}
# create resource vars (automatic)
export AGW_NAME="agw-${SLUG}-${REGION}-ata"
export AGW_URI="projects/${PROJ_ID}/locations/${REGION}/agentGateways/${AGW_NAME}"
export RE_AGENT_NAME="agent-datacommons"
export RE_AGENT_ID_SET="principalSet://agents.global.org-${ORG_ID}.system.id.goog/attribute.platformContainer/aiplatform/projects/${PROJ_NO}"
export STAGING_BUCKET="agent-staging-${PROJ_NO}"
export MCP_DISPLAY_NAME="api.datacommons.org"
export MCP_RESOURCE_NAME="${REGION}-datacommons-mcp"
export MCP_URL="https://api.datacommons.org/mcp"
echo ${AGW_NAME}
echo ${AGW_URI}
echo ${RE_AGENT_NAME}
echo ${RE_AGENT_ID_SET}
echo ${STAGING_BUCKET}
echo ${MCP_DISPLAY_NAME}
echo ${MCP_RESOURCE_NAME}
echo ${MCP_URL}
# create local dir for config files
mkdir -p cfg

Wenn Sie eine selbstverwaltete Installation des Google Cloud SDK ausführen (d. h. außerhalb von Cloud Shell), aktualisieren Sie die Komponenten auf die neueste Version.

# update gcloud cli
gcloud components update

API-Dienste aktivieren

# enable google apis (agent platform bundle, part 1)
gcloud services enable \
  agentregistry.googleapis.com \
  aiplatform.googleapis.com \
  apphub.googleapis.com \
  apptopology.googleapis.com \
  cloudapiregistry.googleapis.com \
  cloudtrace.googleapis.com \
  compute.googleapis.com \
  dataform.googleapis.com \
  iam.googleapis.com \
  iamconnectors.googleapis.com \
  iap.googleapis.com \
  logging.googleapis.com \
  modelarmor.googleapis.com \
  monitoring.googleapis.com \
  networksecurity.googleapis.com \
  networkservices.googleapis.com \
  notebooks.googleapis.com \
  observability.googleapis.com
# enable google apis (agent platform bundle, part 2)
gcloud services enable \
  securitycenter.googleapis.com \
  saasservicemgmt.googleapis.com \
  storage.googleapis.com \
  telemetry.googleapis.com \
  texttospeech.googleapis.com

Damit ist die Einrichtung abgeschlossen. Weiter geht es mit dem Abschnitt Gateway.

4. Gateway

Bevor Sie die Zugriffssteuerung erzwingen, stellen Sie Agent Gateway bereit und konfigurieren Sie die Autorisierungserweiterung im DRY_RUN-Modus. So können ausgehende Tool-Aufrufe erfolgreich ausgeführt werden, während die Bewertungsergebnisse zu Prüfzwecken protokolliert werden.

Hier verwendet Agent Gateway eine regionale Registry zur Unterstützung regionaler Agent Runtime-Ressourcen.

Gateway erstellen

# create agent gateway config file (regional registry)
cat > cfg/${AGW_NAME}.yaml << EOF
name: ${AGW_NAME}
protocols:
  - MCP
googleManaged:
  governedAccessPath: AGENT_TO_ANYWHERE
registries:
  - "//agentregistry.googleapis.com/projects/${PROJ_ID}/locations/${REGION}"
EOF
# import agent gateway config file (create gateway)
gcloud network-services agent-gateways import ${AGW_NAME} \
  --source="cfg/${AGW_NAME}.yaml" \
  --location=${REGION}
# show agent gateway details (verify deployment state)
gcloud network-services agent-gateways describe ${AGW_NAME} \
  --location=${REGION}

Damit ist der Gateway-Teil abgeschlossen. Weiter geht es mit dem Abschnitt Autorisierung.

5. Autorisierung

Die Autorisierungserweiterung für das Agent Gateway für Identity-Aware Proxy (IAP) ist eine Art Diensterweiterung, die verwendet wird, um Autorisierungsentscheidungen für die gesamte Agent Platform zu delegieren.

  1. Delegierungsablauf:Wenn ein Agent versucht, einen externen Endpunkt oder MCP-Server aufzurufen, leitet er die Anfrage an das Agent Gateway weiter. Anstatt den Zugriff lokal zu prüfen, verwendet das Gateway die Autorisierungserweiterung, um einen Callout an den IAP-Bewertungsdienst zu senden. IAP bewertet die Identität des Agents (SPIFFE-basiert) anhand der IAM-Richtlinie der Zielressource in der Agent Registry. IAP gibt eine Entscheidung vom Typ ALLOW oder DENY an das Gateway zurück, das den Traffic entweder weiterleitet oder mit dem HTTP-Statuscode 403 Forbidden blockiert.
  2. Durchsetzungsmodi:Im Modus DRY_RUN werden Anfragen von IAP ausgewertet und Entscheidungen in Cloud Logging protokolliert, ohne den Traffic zu blockieren. Im ENFORCE-Modus wird jede Anfrage von einem nicht autorisierten Agent oder an ein nicht registriertes Ziel sofort blockiert.
  3. Bindungsebene:Die Dienst-Extension ist über eine Autorisierungsrichtlinie, die mit dem Profil REQUEST_AUTHZ konfiguriert ist, mit dem Agent Gateway verbunden.

Autorisierungserweiterung

Autorisierungserweiterung erstellen

# create authz extension config file (dry run mode)
cat > cfg/${AGW_NAME}-svc-ext-authz-iap-dryrun.yaml << EOF
name: ${AGW_NAME}-svc-ext-authz-iap-dryrun
service: iap.googleapis.com
failOpen: true
timeout: 1s
metadata:
  iamEnforcementMode: "DRY_RUN"
  iapPolicyVersion: "V1"
EOF
# import authz extension file (create extension)
gcloud service-extensions authz-extensions import ${AGW_NAME}-svc-ext-authz-iap-dryrun \
  --source=cfg/${AGW_NAME}-svc-ext-authz-iap-dryrun.yaml \
  --location=${REGION}
# show authz extension details (verify extension state)
gcloud service-extensions authz-extensions describe ${AGW_NAME}-svc-ext-authz-iap-dryrun \
  --location=${REGION}

Autorisierungsrichtlinie

Eine Autorisierungsrichtlinie bindet den Sicherheitsanbieter (IAP) an die Ziel-Gateway-Ressource und gibt das Abfangprofil (REQUEST_AUTHZ) an.

Autorisierungsrichtlinie erstellen

# create authz policy config file (attach dry-run authz extension)
cat > cfg/${AGW_NAME}-authz-policy-profile-iap.yaml << EOF
name: ${AGW_NAME}-authz-policy-profile-iap
target:
  resources:
    - "projects/${PROJ_ID}/locations/${REGION}/agentGateways/${AGW_NAME}"
policyProfile: REQUEST_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
      - "projects/${PROJ_ID}/locations/${REGION}/authzExtensions/${AGW_NAME}-svc-ext-authz-iap-dryrun"
EOF
# import authz policy config file (enable authz policy)
gcloud beta network-security authz-policies import ${AGW_NAME}-authz-policy-profile-iap \
  --source=cfg/${AGW_NAME}-authz-policy-profile-iap.yaml \
  --location=${REGION}
# show authz policy details (verify dry run mode)
gcloud beta network-security authz-policies describe ${AGW_NAME}-authz-policy-profile-iap \
  --location=${REGION}

Damit ist die Autorisierung abgeschlossen. Als Nächstes geht es mit dem Abschnitt Codebase weiter.

6. Codebasis

Der für dieses Codelab verwendete Agent-Code und das Endpunktregistrierungsskript werden in einem Google Cloud-GitHub-Repository verwaltet. Bei den folgenden Schritten wird das Repository lokal geklont, die erforderlichen Dateien werden in die aktuelle Arbeitsverzeichnisstruktur kopiert und temporäre Dateien werden gelöscht.

Für die Agent-Laufzeit wird ein Staging-Bucket für den Speicher erstellt, in den der verpackte Agent-Anwendungscode und seine Abhängigkeitsartefakte hochgeladen, erstellt und bereitgestellt werden.

Remote-Artefakte abrufen

# clone remote repository to temp local dir
git clone https://github.com/GoogleCloudPlatform/cloud-networking-solutions.git ./temp_agw_cuj_arun_egress_emcp
# copy agent runtime and endpoint definitions to working project dir
cp -r temp_agw_cuj_arun_egress_emcp/codelabs/agw-cuj-arun-egress-emcp/agent-datacommons ./agent-datacommons
cp -r temp_agw_cuj_arun_egress_emcp/codelabs/agw-cuj-arun-egress-emcp/endpoints ./endpoints
# remove temporary directory
rm -rf temp_agw_cuj_arun_egress_emcp

Staging-Bucket erstellen

# create storage bucket for agent deployment artifacts
gcloud storage buckets create gs://${STAGING_BUCKET} --location=${REGION}
# verify staging bucket url
gcloud storage buckets list --format="value(storage_url)"

Damit ist der Teil zur Codebasis abgeschlossen. Als Nächstes folgt der Abschnitt Registry.

7. Registry

Die Agent Registry ist ein zentrales Inventar aller KI-Agenten, MCP-Server und Endpunkte (APIs) im KI-Ökosystem. Außerdem ist es ein Katalog, in dem andere registrierte Tools und Dienste für die Verwendung durch KI-Anwendungen aufgeführt, gesucht und gefunden werden können. Beim Agent Gateway-Ausgang (Modus agent-to-anywhere) wird das Datenmodell der Registry als Governance-Framework verwendet, um die Zugriffssteuerung für ausgehenden Traffic zu erzwingen. IAM-Rollenzuweisungen für Hauptkonten, die Agents aufrufen, werden anhand der Richtlinie geprüft, die an die Registry-Ressource gebunden ist.

Um die Umgebung zu starten und Agents zu unterstützen, die verschiedene Google-APIs und -Dienste verwenden, wird ein Skript verwendet, um schnell eine gemeinsame Gruppe von API-Endpunkten mit Hostnamen und Standorten aus endpoints/googleapis.txt zu registrieren.

Endpunkte registrieren

# run python script to register google api endpoints
python3 endpoints/register_endpoints.py \
  --multi-region=${MREGION} \
  --region=${REGION} \
  --mtls-endpoints=include

Endpunkte prüfen

# list registry regional endpoints (verify registration)
gcloud agent-registry endpoints list --location=${REGION} \
  --format="table(displayName, name.basename():label=ENDPOINT_ID, interfaces[0].url:label=URL)"

Damit schließen wir den Abschnitt zur Registrierung ab. Als Nächstes folgt der Abschnitt zu Data Commons.

8. Data Commons

Data Commons ist eine Initiative von Google, um öffentliche Datasets zu organisieren und für alle verfügbar und zugänglich zu machen. Es ist ein kostenloser Dienst, auf den nach Erstellen eines Kontos mit einem API-Schlüssel zugegriffen werden kann.

API-Schlüssel erstellen

Nachdem Sie ein Konto erstellt haben, gehen Sie so vor, um einen API-Schlüssel zu erhalten:

  • Melden Sie sich im API-Portal von Data Commons an.
  • Klicken Sie oben rechts auf die Schaltfläche Meine Apps.
  • Klicken Sie rechts oben unter Ihrem Nutzernamen auf die Schaltfläche + NEUE APP.
  • Geben Sie Ihrer App einen Namen, z. B. „Codelab Agent MCP“.
  • Klicken Sie für die Data Commons API auf die Schaltfläche AKTIVIEREN. api.datacommons.org
  • Klicken Sie rechts unten auf die Schaltfläche SPEICHERN.

Dadurch werden ein API-Schlüssel und ein Secret erstellt. Klicken Sie neben dem Schlüsselwert auf das Symbol „Kopieren“, um den API-Schlüssel zu kopieren. Fügen Sie den Wert in den Terminalbefehl ein, um die Umgebungsvariable DC_API_KEY festzulegen.

# set api key env var
 export DC_API_KEY="YOUR_API_KEY_HERE"

MCP-Server erstellen toolspec

Wenn Sie einen MCP-Server manuell registrieren, muss bei der Registrierung eine Tool-Spezifikationsdatei angegeben werden. Beim Hochladen einer toolspec.json-Datei werden alle vom Endpunkt zur Verfügung gestellten Tools aufgelistet und können von anderen Nutzern gefunden werden.

Das test_mcp.py-Script, das im agent-datacommons/-Code enthalten ist, generiert eine toolspec.json-Datei, indem es eine Verbindung zum Ziel-MCP-Server (über SSE oder HTTP) herstellt und list_tools() aufruft, um alle vom Server bereitgestellten verfügbaren Tools abzurufen.

# generate toolspec for registry ingestion
uv --directory agent-datacommons run python3 test_mcp.py --toolspec=include --token="${DC_API_KEY}"

Ein Blick auf die generierte toolspec-Ausgabe zeigt die MCP-Attribute, die Agent Gateway für die Bewertung und Durchsetzung von Richtlinien für ausgehenden Traffic verwenden kann.

# show toolspec mcp attributes
jq '.tools[] | {name, isReadOnly, isDestructive, isIdempotent, isOpenWorld}' agent-datacommons/toolspec.json

MCP-Server registrieren

# register mcp server
gcloud agent-registry services create ${MCP_RESOURCE_NAME} \
  --location=${REGION} \
  --display-name="${MCP_DISPLAY_NAME}" \
  --description="mcp server for data commons" \
  --mcp-server-spec-type=tool-spec \
  --mcp-server-spec-content=agent-datacommons/toolspec.json \
  --interfaces=url=${MCP_URL},protocolBinding=JSONRPC
# list registry regional mcp servers
gcloud agent-registry mcp-servers list --location=${REGION} --format="table(displayName, interfaces.url)"
# show mcp server registry details
gcloud agent-registry services describe ${MCP_RESOURCE_NAME} --location=${REGION}
# fetch mcp server registry id
export MCP_REGISTRY_ID=$(gcloud agent-registry services describe ${MCP_RESOURCE_NAME} \
  --location=${REGION} \
  --format="value(registryResource.basename())")
echo ${MCP_REGISTRY_ID}

Damit sind wir mit dem Data Commons-Teil fertig. Weiter geht es mit dem Abschnitt Laufzeit.

9. Laufzeit

Der agent-datacommons-ADK-Agent, der in der Agent Runtime bereitgestellt wird, ist im Bereitstellungsskript mit den folgenden Einstellungen für die Integration in die Agent Platform konfiguriert:

  • "identity_type": types.IdentityType.AGENT_IDENTITY, um eine eindeutige SPIFFE-basierte Prinzipalidentität für den Agenten bereitzustellen
  • "agent_gateway_config": { "agent_to_anywhere_config": {"agent_gateway": } }, um den gesamten ausgehenden, vom Agenten initiierten Traffic zur Richtlinienbewertung und ‑durchsetzung an das Agent Gateway weiterzuleiten

KI-Agent bereitstellen

# deploy agent runtime workload
uv --directory agent-datacommons run python3 deploy_agent.py \
  --project=${PROJ_ID} \
  --region=${REGION} \
  --src-dir=./agent \
  --staging-bucket=${STAGING_BUCKET} \
  --display-name="${RE_AGENT_NAME}" \
  --description="agent for data commons stats" \
  --enable-telemetry \
  --enable-agent-identity \
  --agent-gateway-egress=${AGW_URI} \
  --env-var="DC_API_KEY=${DC_API_KEY}"

Deployment-Vitals abrufen

# fetch agent runtime resource (reasoning engine) id
export RE_ENGINE_ID=$(curl -s -X GET \
  "https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJ_ID}/locations/${REGION}/reasoningEngines" \
  -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" | \
  jq -r --arg name "${RE_AGENT_NAME}" '.reasoningEngines[] | select(.displayName==$name) | .name | split("/") | last')
echo ${RE_ENGINE_ID}
# fetch agent runtime (reasoning engine) agent identity
export RE_AGENT_IDENTITY=$(gcloud agent-registry agents list \
  --location=${REGION} --filter="displayName=${RE_AGENT_NAME}" \
  --format="value(attributes.'agentregistry.googleapis.com/system/RuntimeIdentity'.principal)")
echo ${RE_AGENT_IDENTITY}
# fetch agent registry uid for agent
export RE_AGENT_REGISTRY_ID=$(gcloud agent-registry agents list \
  --location=${REGION} \
  --filter="displayName=${RE_AGENT_NAME}" \
  --format="value(uid)")
echo ${RE_AGENT_REGISTRY_ID}

Registry-Eintrag überprüfen

# show agent resource registry details
gcloud agent-registry agents describe ${RE_AGENT_REGISTRY_ID} --location=${REGION}

10. Richtlinien

Autorisierungsrichtlinien für die Agent-Governance lassen Traffic von einem KI-Agent über das Agent Gateway und zum Ziel (z. B. einem MCP-Serverendpunkt eines Drittanbieters für eine SaaS-Anwendung) zu. Sobald Traffic das Ziel erreicht, wird der Datenzugriff durch reguläre Berechtigungen auf Dienst- oder Anwendungsebene autorisiert.

IAM-Rollenzuweisungen für den Agent Gateway-Ausgang ermöglichen Zugriffsrichtlinien, die der Identität des Agent-Hauptkontos Zugriff auf registrierte Zielressourcen über das Agent Gateway gewähren. Richtlinien werden auf der Ebene des Agent Gateway erzwungen und mit IAM-Richtlinien für Identity-Aware Proxy (IAP) validiert.

IAM-Rollen für Agenten für den Agent Gateway-Ausgang gewähren

Agent Gateway prüft eingehende Anfragen, um zu validieren, ob die Identität des aufrufenden Agents die Berechtigung iap.webServiceVersions.egressViaIAP (gewährt durch die Rolle roles/iap.egressor) für die Zielressource hat.

Wenn Sie der Agent-Identität oder der Hauptkontogruppe „Agent Runtime“ die Berechtigung roles/iap.egressor für die ausgewählte Zielressource erteilen, ist dieser ausgehende Traffic zulässig. In diesem Codelab wird die Rolle auf das Hauptkonto agent angewendet, wodurch die Berechtigung für die spezifische Agent Runtime-Agentenidentität gewährt wird.

Die IAM-Richtlinien sind an die Zielressourcen gebunden, wie im Datenmodell der Agent Registry definiert. Die iap_web/agentRegistry-Ressource stellt eine Ebene für die gesamte Registrierung in der IAM-Hierarchie dar. Dabei dient agentRegistry als übergeordnete Ressource für die einzelnen untergeordneten Ressourcen für agents, mcpServers und endpoints. In diesem Codelab ist die IAM-Richtlinie an die Ebenen mcpServer und endpoint gebunden, wodurch die Berechtigung auf die jeweiligen untergeordneten Ressourcen angewendet wird.

Bedingtes Filtern von MCPs

Der Data Commons MCP-Server hat zwei Tools:

  • search_indicators: für Anfragen zum Ermitteln der verfügbaren Daten, zum Suchen nach Variablen oder zum Verstehen der Datenabdeckung
  • get_observations: für Abfragen zum Abrufen bestimmter Datenpunkte oder Zeitreihen

Bei der Konfiguration bedingter Governance-Richtlinien auf MCP-Servern sind einige Standard-MCP-Vorgänge zu beachten. Bevor ein MCP-Client eine tools/call für search_indicators oder get_observations ausführen kann, muss er zuerst Protokoll-Handshake- und Discovery-Anfragen senden:

  • initialize
  • notifications/initialized
  • tools/list

Zur Veranschaulichung der bedingten Richtlinienfilterung wird die Richtlinie für die folgenden Bedingungen konfiguriert:

Tabelle. Richtlinienbewertung für MCP-Anfragen

Anfrage / Methode

mcp.toolName-Wert

CEL-Auswertung

Ergebnis

initialize

""

"" in ['search_indicators', '']

✅ ERLAUBT (200)

tools/list

""

"" in ['search_indicators', '']

✅ ERLAUBT (200)

search_indicators

"search_indicators"

"search_indicators" in [...]

✅ ERLAUBT (200)

get_observations

"get_observations"

"get_observations" in [...]

❌ ABGELEHNT (403)

Damit die Protokoll-Handshakes und der search_indicators-Toolaufruf möglich sind, enthält die bedingte Richtlinienregel eine Zulassung für "search_indicators" oder "" (leerer String).

IAM-Richtlinie für den IAP-MCP-Server der Registry konfigurieren

# show iap iam policy for mcp server
gcloud beta iap web get-iam-policy \
  --region=${REGION} \
  --resource-type=agent-registry \
  --mcp-server=${MCP_REGISTRY_ID}

HINWEIS : etag: sollte den Standardwert ACAB zurückgeben, da noch keine Richtlinien definiert wurden.

# fetch active etag on policy for mcp server
export IAP_ETAG=$(gcloud beta iap web get-iam-policy \
  --resource-type=agent-registry --region=${REGION} \
  --mcp-server=${MCP_REGISTRY_ID} --format="value(etag)")
echo ${IAP_ETAG}
# create policy config file
cat > cfg/iap-policy-dc-agent-to-dc-mcp-tool-1.json << EOF
{
  "bindings": [
    {
      "role": "roles/iap.egressor",
      "members": [
        "${RE_AGENT_IDENTITY}"
      ],
      "condition": {
        "title": "allow ${RE_AGENT_NAME} to use search_indicators tool for ${MCP_DISPLAY_NAME}",
        "expression": "api.getAttribute('iap.googleapis.com/mcp.toolName', '') in ['search_indicators', '']"
      }
    }
  ],
  "etag": "${IAP_ETAG}",
  "version": 3
}
EOF
# import policy file (bind iam policy)
gcloud beta iap web set-iam-policy cfg/iap-policy-dc-agent-to-dc-mcp-tool-1.json \
  --resource-type=agent-registry \
  --mcp-server=${MCP_REGISTRY_ID} \
  --region=${REGION}
# verify iap iam policy for mcp server
gcloud beta iap web get-iam-policy \
  --region=${REGION} \
  --resource-type=agent-registry \
  --mcp-server=${MCP_REGISTRY_ID}

Damit sind wir mit den Richtlinien durch. Als Nächstes geht es um den Audit-Abschnitt.

11. Audit

Die Autorisierungserweiterung für Agent Gateway wird im Modus DRY_RUN ausgeführt. Ausgehende Anfragen werden beobachtet und protokolliert, aber nicht blockiert.

Agent-Anfragen testen

Öffnen Sie ein Browserfenster für die Google Cloud Console-UI und rufen Sie Folgendes auf:

  • Agent Platform → „Agents“ → „Deployments“ → agent-datacommons
  • Wählen Sie den Tab Playground aus.

Alternativ können Sie diesen Terminalbefehl ausgeben und auf den Link klicken, um zum Agent-Playground zu gelangen:

# playground
echo "https://console.cloud.google.com/agent-platform/runtimes/locations/${REGION}/agent-engines/${RE_ENGINE_ID}/playground?project=${PROJ_ID}"

Senden Sie einige Testanfragen.

  • What data do you have on water quality in Zimbabwe?
  • Compare the life expectancy, economic inequality, and GDP growth for BRICS nations

Prüfen Sie, ob die Abfragen gültige Antworten zurückgeben.

Audit-Logs analysieren

Logs ansehen und die Richtlinienbewertungen im Probebetrieb prüfen

# list unique urls with http status and iap authorization result
gcloud logging read \
  "resource.type=\"networkservices.googleapis.com/Gateway\" \
  AND httpRequest.requestUrl:*" \
  --project=${PROJ_ID} \
  --limit=200 \
  --format="value(httpRequest.status, jsonPayload.authzPolicyInfo.result, httpRequest.requestUrl)" | sort -u
200     ALLOWED https://api.datacommons.org/mcp
200     ALLOWED https://cloudresourcemanager.googleapis.com:443/google.cloud.resourcemanager.v3.Projects/GetProject
200     ALLOWED https://telemetry.googleapis.com/v1/traces
200     ALLOWED https://${REGION}-aiplatform.googleapis.com/v1beta1/projects/${PROJ_ID}/locations/${REGION}/publishers/google/models/gemini-2.5-flash:generateContent
200     ALLOWED https://${REGION}-aiplatform.googleapis.com/v1beta1/projects/${PROJ_ID}/locations/${REGION}/reasoningEngines/${RE_ENGINE_ID}/sessions/${RE_SESSION_ID}
200     ALLOWED https://${REGION}-aiplatform.googleapis.com/v1beta1/projects/${PROJ_ID}/locations/${REGION}/reasoningEngines/${RE_ENGINE_ID}/sessions/${RE_SESSION_ID}:appendEvent
200     ALLOWED https://${REGION}-aiplatform.googleapis.com/v1beta1/projects/${PROJ_ID}/locations/${REGION}/reasoningEngines/${RE_ENGINE_ID}/sessions/${RE_SESSION_ID}/events
202     ALLOWED https://api.datacommons.org/mcp

IAM-Richtlinie für IAP-Endpunkte der Registry aktualisieren

Berechtigungen für ausgehenden Traffic für den Telemetrie-Endpunkt erteilen

# set var for endpoint display name
export ENDPOINT_1_DISPLAY_NAME="telemetry.googleapis.com"
echo ${ENDPOINT_1_DISPLAY_NAME}
# fetch endpoint registry id
export ENDPOINT_1_REGISTRY_ID=$(gcloud agent-registry services list \
  --location=${REGION} \
  --filter="displayName=${ENDPOINT_1_DISPLAY_NAME}" \
  --format="value(registryResource.basename())")
echo ${ENDPOINT_1_REGISTRY_ID}
# create policy config file
cat > cfg/iap-policy-re-agent-to-ep-1.json << EOF
{
  "bindings": [
    {
      "role": "roles/iap.egressor",
      "members": [
        "${RE_AGENT_IDENTITY}"
      ]
    }
  ]
}
EOF
# import policy file (bind iam policy)
gcloud -q beta iap web set-iam-policy cfg/iap-policy-re-agent-to-ep-1.json \
  --resource-type=agent-registry \
  --endpoint=${ENDPOINT_1_REGISTRY_ID} \
  --region=${REGION}
# verify iap iam policy for telemetry endpoint
gcloud beta iap web get-iam-policy \
  --region=${REGION} \
  --resource-type=agent-registry \
  --endpoint=${ENDPOINT_1_REGISTRY_ID}

Berechtigungen für ausgehenden Traffic für den aiplatform-Endpunkt gewähren

# set var for endpoint display name
export ENDPOINT_2_DISPLAY_NAME="${REGION}-aiplatform.googleapis.com"
echo ${ENDPOINT_2_DISPLAY_NAME}
# fetch endpoint registry id
export ENDPOINT_2_REGISTRY_ID=$(gcloud agent-registry services list \
  --location=${REGION} \
  --filter="displayName=${ENDPOINT_2_DISPLAY_NAME}" \
  --format="value(registryResource.basename())")
echo ${ENDPOINT_2_REGISTRY_ID}
# create policy config file
cat > cfg/iap-policy-re-agent-to-ep-2.json << EOF
{
  "bindings": [
    {
      "role": "roles/iap.egressor",
      "members": [
        "${RE_AGENT_IDENTITY}"
      ]
    }
  ]
}
EOF
# import policy file (bind iam policy)
gcloud -q beta iap web set-iam-policy cfg/iap-policy-re-agent-to-ep-2.json \
  --resource-type=agent-registry \
  --endpoint=${ENDPOINT_2_REGISTRY_ID} \
  --region=${REGION}
# verify iap iam policy for aiplatform endpoint
gcloud beta iap web get-iam-policy \
  --region=${REGION} \
  --resource-type=agent-registry \
  --endpoint=${ENDPOINT_2_REGISTRY_ID}

Berechtigungen für den Agent-Ausgang für den cloudresourcemanager-Endpunkt gewähren

# set var for endpoint display name
export ENDPOINT_3_DISPLAY_NAME="cloudresourcemanager.googleapis.com"
echo ${ENDPOINT_3_DISPLAY_NAME}
# fetch endpoint registry id
export ENDPOINT_3_REGISTRY_ID=$(gcloud agent-registry services list \
  --location=${REGION} \
  --filter="displayName=${ENDPOINT_3_DISPLAY_NAME}" \
  --format="value(registryResource.basename())")
echo ${ENDPOINT_3_REGISTRY_ID}
# create policy config file
cat > cfg/iap-policy-re-agent-to-ep-3.json << EOF
{
  "bindings": [
    {
      "role": "roles/iap.egressor",
      "members": [
        "${RE_AGENT_IDENTITY}"
      ]
    }
  ]
}
EOF
# import policy file (bind iam policy)
gcloud -q beta iap web set-iam-policy cfg/iap-policy-re-agent-to-ep-3.json \
  --resource-type=agent-registry \
  --endpoint=${ENDPOINT_3_REGISTRY_ID} \
  --region=${REGION}
# verify iap iam policy for cloudresourcemanager endpoint
gcloud beta iap web get-iam-policy \
  --region=${REGION} \
  --resource-type=agent-registry \
  --endpoint=${ENDPOINT_3_REGISTRY_ID}

Damit ist der Audit-Teil abgeschlossen. Weiter geht es mit dem Abschnitt Erzwingen.

12. Erzwingen

Der Agent konnte im DRY_RUN-Modus erfolgreiche Anfragen über das Gateway stellen. Stellen Sie die IAP-Autorisierungserweiterung des Agent Gateway auf den ENFORCE-Modus um, indem Sie die Autorisierungsrichtlinie aktualisieren.

Autorisierungserweiterung aktualisieren

# create authz extension config file (enforced mode)
cat > cfg/${AGW_NAME}-svc-ext-authz-iap-enforced.yaml << EOF
name: ${AGW_NAME}-svc-ext-authz-iap-enforced
service: iap.googleapis.com
failOpen: false
timeout: 1s
metadata:
  iapPolicyVersion: "V1"
EOF
# import authz extension file (create extension)
gcloud service-extensions authz-extensions import ${AGW_NAME}-svc-ext-authz-iap-enforced \
  --source=cfg/${AGW_NAME}-svc-ext-authz-iap-enforced.yaml \
  --location=${REGION}
# list authz extensions (imported configs)
gcloud service-extensions authz-extensions list --location=${REGION}

Autorisierungsrichtlinie aktualisieren

# re-write authz policy config file (pointing to enforced authz extension)
cat > cfg/${AGW_NAME}-authz-policy-profile-iap.yaml << EOF
name: ${AGW_NAME}-authz-policy-profile-iap
target:
  resources:
    - "projects/${PROJ_ID}/locations/${REGION}/agentGateways/${AGW_NAME}"
policyProfile: REQUEST_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
      - "projects/${PROJ_ID}/locations/${REGION}/authzExtensions/${AGW_NAME}-svc-ext-authz-iap-enforced"
EOF
# import authz policy config file (enable new authz policy)
gcloud beta network-security authz-policies import ${AGW_NAME}-authz-policy-profile-iap \
  --source=cfg/${AGW_NAME}-authz-policy-profile-iap.yaml \
  --location=${REGION}
# show authz policy details (verify enforced mode)
gcloud beta network-security authz-policies describe ${AGW_NAME}-authz-policy-profile-iap \
  --location=${REGION}

Bedingtes Zulassen überprüfen

Kehren Sie in der Console-UI zum Playground des Agents zurück.

Senden Sie eine zusätzliche Testanfrage (versuchen Sie, das erlaubte-Toolsearch_indicators aufzurufen).

  • What data topics do you have for Peru?

Die Agentenanfragen an das Gemini-Foundation Model (${REGION}-aiplatform.googleapis.com/...), die Telemetrie-API (telemetry.googleapis.com/...) und den Data Commons MCP-Serverendpunkt (api.datacommons.org/mcp) werden mit HTTP-Statuscodes 200 OK übergeben.

# show gateway logs for http requests
gcloud logging read \
  "resource.type=\"networkservices.googleapis.com/Gateway\" \
  AND httpRequest.requestUrl:*" \
  --project=${PROJ_ID} \
  --limit=10 \
  --format="table(
    timestamp.date(tz=LOCAL):label=TIMESTAMP,
    httpRequest.requestMethod:label=METHOD,
    httpRequest.status:label=STATUS,
    jsonPayload.authzPolicyInfo.result:label=IAP_AUTHZ,
    jsonPayload.agentGatewayInfo.mcpInfo.method:label=MCP_METHOD,
    httpRequest.requestUrl:label=URL)"

Prüfen Sie, ob Anfragen blockiert werden. Suchen Sie in den Gateway-Prüfprotokollen nach abgelehnten Egress-Versuchen mit HTTP-Statuscodes 403 Forbidden.

# show gateway logs for authz denies
gcloud logging read \
  "resource.type=\"networkservices.googleapis.com/Gateway\" \
  AND (jsonPayload.authzPolicyInfo.result=\"DENIED\" OR httpRequest.status=403)" \
  --project=${PROJ_ID} \
  --limit=10 \
  --format="table(
    timestamp.date(tz=LOCAL):label=TIMESTAMP,
    httpRequest.requestMethod:label=METHOD,
    httpRequest.status:label=STATUS,
    jsonPayload.enforcedGatewaySecurityPolicy.serverNameIndication:label=SNI,
    jsonPayload.authzPolicyInfo.result:label=AUTHZ_RESULT,
    jsonPayload.authzPolicyInfo.policies[0].name.basename():label=DENYING_POLICY
  )"
# show gateway logs for mcp requests with method and tool name
gcloud logging read \
  "resource.type=\"networkservices.googleapis.com/Gateway\" \
  AND jsonPayload.agentGatewayInfo.mcpInfo.method:*" \
  --project=${PROJ_ID} \
  --limit=10 \
  --format="table(
    timestamp.date(tz=LOCAL):label=TIMESTAMP,
    httpRequest.status:label=STATUS,
    jsonPayload.authzPolicyInfo.result:label=IAP_AUTHZ,
    jsonPayload.agentGatewayInfo.mcpInfo.method:label=MCP_METHOD,
    jsonPayload.agentGatewayInfo.mcpInfo.parameter:label=TOOL_NAME,
    httpRequest.requestUrl:label=URL
  )"

Bedingte Ablehnung prüfen

Senden Sie eine zusätzliche Testanfrage (versuchen Sie, das Tool deniedget_observations aufzurufen).

  • What are the diabetes levels in Peru compared to Slovakia?

Der Agent sieht sich zuerst search_indicators an und versucht dann, get_observations zu verwenden. Das schlägt jedoch fehl und die Antwort des Agenten bleibt unvollständig.

# show gateway logs for mcp requests with method and tool name
gcloud logging read \
  "resource.type=\"networkservices.googleapis.com/Gateway\" \
  AND jsonPayload.agentGatewayInfo.mcpInfo.method:*" \
  --project=${PROJ_ID} \
  --limit=10 \
  --format="table(
    timestamp.date(tz=LOCAL):label=TIMESTAMP,
    httpRequest.status:label=STATUS,
    jsonPayload.authzPolicyInfo.result:label=IAP_AUTHZ,
    jsonPayload.agentGatewayInfo.mcpInfo.method:label=MCP_METHOD,
    jsonPayload.agentGatewayInfo.mcpInfo.parameter:label=TOOL_NAME,
    httpRequest.requestUrl:label=URL
  )"
TIMESTAMP            STATUS  IAP_AUTHZ  MCP_METHOD                 TOOL_NAME          URL
YYYY-MM-DDTHH:MM:SS  403     DENIED     tools/call                 get_observations   https://api.datacommons.org/mcp
YYYY-MM-DDTHH:MM:SS          ALLOWED    tools/call                 get_observations   https://api.datacommons.org/mcp
YYYY-MM-DDTHH:MM:SS  403     DENIED     tools/call                 get_observations   https://api.datacommons.org/mcp
YYYY-MM-DDTHH:MM:SS  200     ALLOWED    tools/call                 search_indicators  https://api.datacommons.org/mcp
YYYY-MM-DDTHH:MM:SS  200     ALLOWED    tools/list                                    https://api.datacommons.org/mcp
YYYY-MM-DDTHH:MM:SS  202     ALLOWED    notifications/initialized                     https://api.datacommons.org/mcp

So wird bestätigt, dass die Governance-Richtlinie wie erwartet funktioniert.

Die zweite Zeile mit einem leeren Status und ALLOWED ist ein sekundäres Log-Ereignis zum Beenden der Verbindung, das vom Agent Gateway ausgegeben wird, wenn der Socket nach dem Senden der 403-Antwort geschlossen wird. Da Ereignisse zum Schließen der Verbindung keine Antwortstatuscodes haben, ist httpRequest.status leer.

Damit schließen wir den Teil zur Erzwingung ab. Als Nächstes folgt der Abschnitt Bereinigung.

13. Bereinigen

# delete agent
curl -s -X DELETE "https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJ_ID}/locations/${REGION}/reasoningEngines/${RE_ENGINE_ID}?force=true" \
  -H "Authorization: Bearer $(gcloud auth application-default print-access-token)"

# next
# delete storage bucket
gcloud -q storage rm --recursive gs://${STAGING_BUCKET}

# next
# clear policy on mcp server
export IAP_ETAG=$(gcloud beta iap web get-iam-policy --resource-type=agent-registry --mcp-server=${MCP_REGISTRY_ID} --region=${REGION} --format="value(etag)")
cat > cfg/iap-policy-empty.json << EOF
{
  "bindings": [],
  "etag": "${IAP_ETAG}"
}
EOF

gcloud -q beta iap web set-iam-policy cfg/iap-policy-empty.json \
  --resource-type=agent-registry \
  --mcp-server=${MCP_REGISTRY_ID} \
  --region=${REGION}

# next
# clear policy on endpoint 1
export IAP_ETAG=$(gcloud beta iap web get-iam-policy --resource-type=agent-registry --endpoint=${ENDPOINT_1_REGISTRY_ID} --region=${REGION} --format="value(etag)")
cat > cfg/iap-policy-empty.json << EOF
{
  "bindings": [],
  "etag": "${IAP_ETAG}"
}
EOF

gcloud -q beta iap web set-iam-policy cfg/iap-policy-empty.json \
  --resource-type=agent-registry \
  --endpoint=${ENDPOINT_1_REGISTRY_ID} \
  --region=${REGION}

# next
# clear policy on endpoint 2
export IAP_ETAG=$(gcloud beta iap web get-iam-policy --resource-type=agent-registry --endpoint=${ENDPOINT_2_REGISTRY_ID} --region=${REGION} --format="value(etag)")
cat > cfg/iap-policy-empty.json << EOF
{
  "bindings": [],
  "etag": "${IAP_ETAG}"
}
EOF

gcloud -q beta iap web set-iam-policy cfg/iap-policy-empty.json \
  --resource-type=agent-registry \
  --endpoint=${ENDPOINT_2_REGISTRY_ID} \
  --region=${REGION}

# next
# clear policy on endpoint 3
export IAP_ETAG=$(gcloud beta iap web get-iam-policy --resource-type=agent-registry --endpoint=${ENDPOINT_3_REGISTRY_ID} --region=${REGION} --format="value(etag)")
cat > cfg/iap-policy-empty.json << EOF
{
  "bindings": [],
  "etag": "${IAP_ETAG}"
}
EOF

gcloud -q beta iap web set-iam-policy cfg/iap-policy-empty.json \
  --resource-type=agent-registry \
  --endpoint=${ENDPOINT_3_REGISTRY_ID} \
  --region=${REGION}

# next
# remove manual registry entry
gcloud -q agent-registry services delete ${MCP_RESOURCE_NAME} --location=${REGION}
# delete gateway resources
gcloud -q beta network-security authz-policies delete ${AGW_NAME}-authz-policy-profile-iap --location=${REGION}

gcloud -q beta service-extensions authz-extensions delete ${AGW_NAME}-svc-ext-authz-iap-dryrun --location=${REGION}

gcloud -q beta service-extensions authz-extensions delete ${AGW_NAME}-svc-ext-authz-iap-enforced --location=${REGION}

gcloud -q network-services agent-gateways delete ${AGW_NAME} --location=${REGION}

# next
# clean up local working directories and generated configs
rm -rf cfg agent-datacommons endpoints

# end

Damit ist die Bereinigung abgeschlossen. Als Nächstes folgt das Fazit.

14. Fazit

Glückwunsch! Sie haben die ausgehende Kommunikation für einen KI-Agenten, der über Agent Gateway auf Tools zugreift, erfolgreich bereitgestellt und verwaltet.

cosmopup

Cosmopup findet Codelabs einfach toll!

Wie geht es weiter?

Wenn Sie Kommentare, Fragen oder Korrekturen haben, können Sie uns diese gern über dieses Feedbackformular mitteilen.

Vielen Dank!