Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Secure Web Proxy als Agent-Gateway bereitstellen

Auf dieser Seite wird beschrieben, wie Sie Ihre Secure Web Proxy-Instanz als Agent-Gateway konfigurieren und bereitstellen.

Übersicht

In Google Cloud bereitgestellte KI-Arbeitslasten von Unternehmen erfordern strukturierte Netzwerkgrenzen, um die Einhaltung von Datenschutzbestimmungen zu gewährleisten, die Weitergabe vertraulicher Daten zu verhindern und sich vor neuen KI-Bedrohungen wie Prompt Injection zu schützen.

Agent Gateway bietet zentrale Sicherheits-Governance, Identitätserzwingung und Inhalts-Guardrails für ausgehenden Traffic von KI-Agenten zu Large Language Models (LLMs), Model Context Protocol-Tools (MCP), externen APIs, Remote-Agenten und Standard-Webzielen.

Sie können entweder ein von Google verwaltetes Agent Gateway oder eine Secure Web Proxy-Instanz als selbstverwaltetes Agent Gateway bereitstellen. Beide Bereitstellungsmodelle bieten eine gemeinsame Governance-Lösung für die Gemini Enterprise Agent Platform, einschließlich zentraler Zugriffsrichtlinien, Integration der Agent Registry und Content Guardrails.

Wählen Sie je nach Ihren betrieblichen Anforderungen eine der folgenden Bereitstellungsoptionen aus:

Von Google verwaltetes Agent-Gateway: Verwenden Sie diese Option, wenn Sie eine vollständig verwaltete, wartungsfreie Lösung wünschen, ohne eine Netzwerk-Proxy-Infrastruktur verwalten zu müssen. Weitere Informationen finden Sie unter Von Google verwaltetes Agent-Gateway. Dieses Modell ist für Agenten optimiert, die entweder auf Gemini Enterprise oder Agent Runtime auf der Gemini Enterprise Agent Platform ausgeführt werden.
Secure Web Proxy als selbstverwaltetes Agent-Gateway: Stellen Sie Ihre Secure Web Proxy-Instanz als Agent-Gateway bereit, wenn Sie die volle Kontrolle über Ihren VPC-Netzwerkperimeter, private CA-Zertifikate und das Proxy-Routing behalten möchten, um Agents zu unterstützen, die in der Google Kubernetes Engine (GKE) oder in Cloud Run ausgeführt werden.

Vorteile

Die Bereitstellung von Secure Web Proxy als Agent-Gateway bietet folgende Vorteile:

Vom Kunden kontrollierte Infrastruktur: Sie können das Secure Web Proxy-Gateway in Ihrem eigenen VPC-Netzwerk (Virtual Private Cloud) verwalten und behalten die volle Kontrolle über Netzwerkrouting, IP-Adressierung, private CA-Zertifikate und TLS-Prüfung.
Zentralisierte Durchsetzung von KI-Richtlinien: Sie können Autorisierungsrichtlinien für eine agentGateway-Ressource definieren. So können Sie diese Richtlinien direkt auf Ihrem Secure Web Proxy-Gateway erzwingen, um MCP-Toolaufrufe einzuschränken, die externen Ziele von KI-Agenten zu filtern und Dienste zur Inhaltsbereinigung wie Model Armor aufzurufen.
Laufzeitunterstützung: Sie können ausgehenden Traffic von KI-Agenten, die in verschiedenen Laufzeiten wie GKE oder Cloud Run gehostet werden, über einen einzigen Proxy-Perimeter weiterleiten.
Agent-orientierte Beobachtbarkeit: Transaktionslogs in Cloud Logging enthalten automatisch Metadaten zur Ausführung von KI-Agenten (agentGatewayInfo), einschließlich MCP-Methoden, Toolnamen und Uniform Resource Names (URNs) von Agent Registry-Zielen.

Architektur

In den folgenden Schritten wird gezeigt, wie Secure Web Proxy ausgehenden Traffic als Agent-Gateway sichert:

Agent-Laufzeiten: Autonome Agenten, die entweder in GKE oder Cloud Run ausgeführt werden, initiieren ausgehende Verbindungen zu externen APIs, Modellanbietern, MCP-Toolservern, Remote-Agenten oder Standard-Webzielen.
Routing von ausgehendem Traffic: Der Agent-Traffic wird über VPC-internes Proxy-Routing oder VPC-übergreifende Private Service Connect-Dienstanhänge (PSC) an Secure Web Proxy weitergeleitet.
Richtlinienbewertung und Inhaltsbereinigung: Secure Web Proxy beendet TLS-Verbindungen, erzwingt MCP-Autorisierungsrichtlinien und ruft Erweiterungsdienste wie Model Armor oder Identity-Aware Proxy (IAP) auf, um Nutzlasten zu bereinigen und die Clientidentität zu überprüfen.

Hinweis

Bevor Sie Ihre Secure Web Proxy-Instanz als Agent-Gateway bereitstellen, müssen Sie die folgenden Voraussetzungen erfüllen:

Aktivieren Sie die folgenden erforderlichen Google Cloud -APIs:

gcloud services enable \
    networkservices.googleapis.com \
    networksecurity.googleapis.com \
    privateca.googleapis.com \
    certificatemanager.googleapis.com \
    serviceextensions.googleapis.com \
    agentregistry.googleapis.com \
    compute.googleapis.com

Prüfen Sie, ob Sie die folgenden erforderlichen IAM-Rollen (Identity and Access Management) haben:
- Rolle „Compute-Netzwerkadministrator“ (roles/compute.networkAdmin)
- Rolle „Netzwerksicherheitsadministrator“ (roles/networksecurity.admin)
- Rolle „CA Service Admin“ (roles/privateca.admin)

Konfigurieren Sie die folgenden Umgebungsvariablen für Ihre Bereitstellung:

export PROJECT_ID="my-project-id"
export PROJECT_NUMBER="my-project-number"
export REGION="us-central1"
export NETWORK_NAME="swp-vpc"
export PROXY_SUBNET_NAME="swp-proxy-subnet"
export PSC_NAT_SUBNET_NAME="swp-psc-nat-subnet"
export CA_POOL_NAME="swp-ca-pool"
export ROOT_CA_NAME="swp-root-ca"
export TLS_INSPECTION_POLICY_NAME="swp-tls-inspection-policy"
export SECURE_WEB_PROXY_NAME="swp-agent-gateway"
export SWP_IP_ADDRESS="10.129.0.10"
export SWP_CERTIFICATE_NAME="swp-cert"
export SERVER_TLS_POLICY_NAME="swp-server-tls-policy"
export GATEWAY_SECURITY_POLICY_NAME="swp-security-policy"
export SERVICE_ATTACHMENT_NAME="swp-service-attachment"
export AGENT_GATEWAY_NAME="my-agent-gateway"

Optional: Wenn Ihre Agent Runtimes in separaten VPC-Netzwerken oder verwalteten Umgebungen wie projektübergreifenden GKE- oder Cloud Run-Clustern ausgeführt werden, müssen Sie Secure Web Proxy über einen Private Service Connect-Dienstanhang bereitstellen:
- Erstellen Sie ein PSC-NAT-Subnetz mit --purpose=PRIVATE_SERVICE_CONNECT.
- Erstellen Sie einen Dienstanhang, der auf Ihr Secure Web Proxy-Gateway verweist. Weitere Informationen finden Sie unter Secure Web Proxy als Private Service Connect-Dienst bereitstellen.

TLS-Prüfung einrichten

Secure Web Proxy beendet TLS-Verbindungen, um HTTP-Header zu prüfen, MCP-Methoden auszuwerten und Nutzlasten zu bereinigen.

So konfigurieren Sie die TLS-Prüfung: Erstellen Sie einen privaten Zertifizierungsstellen-Pool (CA-Pool), eine Stammzertifizierungsstelle und dann eine tlsInspectionPolicy-Ressource. Gehen Sie dazu so vor:

Erstellen Sie einen privaten CA-Pool.
```
gcloud privateca pools create CA_POOL_NAME \
    --location=REGION \
    --tier=devops \
    --project=PROJECT_ID
```
Ersetzen Sie Folgendes:
- CA_POOL_NAME: Name des CA-Pools
- REGION: Region, in der der CA-Pool erstellt wird
- PROJECT_ID: ID Ihres Projekts in Google Cloud
Erstellen Sie eine Root-CA im privaten CA-Pool.
```
gcloud privateca roots create ROOT_CA_NAME \
    --pool=CA_POOL_NAME \
    --location=REGION \
    --subject="CN=Agent Gateway SWP Root CA, O=MyOrganization" \
    --auto-enable \
    --project=PROJECT_ID
```
Ersetzen Sie Folgendes:
- ROOT_CA_NAME: Name der Stammzertifizierungsstelle
- CA_POOL_NAME: Name des CA-Pools
- REGION: Region, in der die Stamm-CA erstellt wird
- PROJECT_ID: ID Ihres Projekts in Google Cloud
Hinweis: Damit Clientarbeitslasten wie Cloud Run oder GKE den von diesem CA-Pool während der TLS-Prüfung ausgestellten Zertifikaten vertrauen, exportieren Sie das Root-CA-Zertifikat und fügen Sie es dem Trust Store Ihrer Arbeitslast hinzu. Sie können beispielsweise die Umgebungsvariable AGENT_GATEWAY_ROOT_CERTIFICATES festlegen.

Gewähren Sie dem Dienstkonto für Netzwerksicherheit die Berechtigung, Zertifikate anzufordern.

gcloud privateca pools add-iam-policy-binding CA_POOL_NAME \
    --location=REGION \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-networksecurity.iam.gserviceaccount.com" \
    --role="roles/privateca.certificateRequester" \
    --project=PROJECT_ID

Erstellen Sie die Ressource tlsInspectionPolicy in einer Datei mit dem Namen tls-inspection-policy.yaml.
```
name: projects/PROJECT_ID/locations/REGION/tlsInspectionPolicies/TLS_INSPECTION_POLICY_NAME
caPool: projects/PROJECT_ID/locations/REGION/caPools/CA_POOL_NAME
```
Ersetzen Sie Folgendes:
- PROJECT_ID: ID Ihres Projekts in Google Cloud
- REGION: Region, in der der TlsInspectionPolicy erstellt wird
- TLS_INSPECTION_POLICY_NAME: Name der TlsInspectionPolicy-Ressource
- CA_POOL_NAME: Name des CA-Pools

Führen Sie den Befehl gcloud network-security tls-inspection-policies import aus, um die Richtlinie zu importieren.

gcloud network-security tls-inspection-policies import TLS_INSPECTION_POLICY_NAME \
    --source=tls-inspection-policy.yaml \
    --location=REGION \
    --project=PROJECT_ID

Secure Web Proxy bereitstellen

Erstellen Sie ein Secure Web Proxy-Gateway mit konfiguriertem gegenseitigem TLS (mTLS).

Achten Sie darauf, dass Ihr VPC-Netzwerk ein Nur-Proxy-Subnetz in der Region hat, in der Sie das Gateway bereitstellen möchten.
```
gcloud compute networks subnets create PROXY_SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=NETWORK_NAME \
    --range=10.129.0.0/23
```
Ersetzen Sie Folgendes:
- PROXY_SUBNET_NAME: Name des Nur-Proxy-Subnetzes
- NETWORK_NAME: Name des VPC-Netzwerk
- REGION: Region, in der das Subnetz erstellt wird
Optional: Wählen Sie eine verfügbare IP-Adresse aus dem Bereich Ihres Nur-Proxy-Subnetzes aus, z. B. 10.129.0.10 innerhalb von 10.129.0.0/23, um sie Ihrem SWP_IP_ADDRESS zuzuweisen.

Hinweis: Wenn Sie das Feld addresses nicht in der Datei swp.yaml hinzufügen, weist Secure Web Proxy automatisch eine IP-Adresse aus dem Nur-Proxy-Subnetz zu.
Damit Ihr Secure Web Proxy-Gateway eingehende Client-Agent-Verbindungen sicher akzeptieren kann, erstellen Sie im Zertifikatmanager ein regionales SSL/TLS-Serverzertifikat.
1. Generieren Sie ein selbstverwaltetes Zertifikat und einen privaten Schlüssel.
```
openssl req -x509 -newkey rsa:2048 -nodes \
    -keyout "swp.key" \
    -out "swp.crt" \
    -days 365 \
    -subj "/CN=SWP_IP_ADDRESS"
```
  Ersetzen Sie SWP_IP_ADDRESS durch die IP-Adresse Ihres Secure Web Proxy-Gateways.
2. Führen Sie den Befehl gcloud certificate-manager certificates create aus, um das Zertifikat in den Zertifikatmanager hochzuladen.
```
gcloud certificate-manager certificates create SWP_CERTIFICATE_NAME \
    --location=REGION \
    --certificate-file="swp.crt" \
    --private-key-file="swp.key" \
    --project=PROJECT_ID
```
  Ersetzen Sie Folgendes:
  - SWP_CERTIFICATE_NAME: Name der Zertifikatsressource
  - REGION: Region, in der das Zertifikat erstellt wird
  - PROJECT_ID: ID Ihres Projekts in Google Cloud
Erstellen Sie eine ServerTlsPolicy-Ressource, um mTLS für das Frontend zu aktivieren. Wenn Sie Arbeitslasten wie Cloud Run erlauben möchten, ihre Identitätszertifikate an Dienste wie IAP zu übergeben, konfigurieren Sie die Richtlinie mit clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

Hinweis: Wenn Sie IAP verwenden, legen Sie keinen Wert für das Feld clientValidationTrustConfig fest, da es nicht unterstützt wird.
1. Erstellen Sie eine Datei mit dem Namen server-tls-policy.yaml und fügen Sie den folgenden Inhalt hinzu:
```
name: projects/PROJECT_ID/locations/REGION/serverTlsPolicies/SERVER_TLS_POLICY_NAME
mtlsPolicy:
  clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
```
  Ersetzen Sie Folgendes:
  - PROJECT_ID: ID Ihres Projekts in Google Cloud
  - REGION: Region, in der der ServerTlsPolicy erstellt wird
  - SERVER_TLS_POLICY_NAME: Name der ServerTlsPolicy-Ressource
2. Führen Sie den Befehl gcloud network-security server-tls-policies import aus, um die Richtlinie zu importieren.
```
gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
    --source=server-tls-policy.yaml \
    --location=REGION \
    --project=PROJECT_ID
```
Erstellen Sie eine Gateway-Sicherheitsrichtlinie, um Ihre tlsInspectionPolicy anzuhängen.
1. Erstellen Sie eine Datei mit dem Namen gateway-security-policy.yaml und fügen Sie den folgenden Inhalt hinzu:
```
name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/GATEWAY_SECURITY_POLICY_NAME
tlsInspectionPolicy: projects/PROJECT_ID/locations/REGION/tlsInspectionPolicies/TLS_INSPECTION_POLICY_NAME
```
  Ersetzen Sie Folgendes:
  - PROJECT_ID: ID Ihres Projekts in Google Cloud
  - REGION: Region, in der der GatewaySecurityPolicy erstellt wird
  - GATEWAY_SECURITY_POLICY_NAME: Name der GatewaySecurityPolicy-Ressource
  - TLS_INSPECTION_POLICY_NAME: Name der TlsInspectionPolicy-Ressource
2. Führen Sie den Befehl gcloud network-security gateway-security-policies import aus, um die Richtlinie zu importieren.
```
gcloud network-security gateway-security-policies import GATEWAY_SECURITY_POLICY_NAME \
    --source=gateway-security-policy.yaml \
    --location=REGION \
    --project=PROJECT_ID
```

Erstellen Sie eine Secure Web Proxy-Spezifikationsdatei mit dem Namen swp.yaml.

name: projects/PROJECT_ID/locations/REGION/gateways/SECURE_WEB_PROXY_NAME
type: SECURE_WEB_GATEWAY
addresses:
  - "SWP_IP_ADDRESS"
ports:
  - 443
routingMode: EXPLICIT_ROUTING_MODE
certificateUrls:
  - projects/PROJECT_ID/locations/REGION/certificates/SWP_CERTIFICATE_NAME
serverTlsPolicy: projects/PROJECT_ID/locations/REGION/serverTlsPolicies/SERVER_TLS_POLICY_NAME
network: projects/PROJECT_ID/global/networks/NETWORK_NAME
subnetwork: projects/PROJECT_ID/regions/REGION/subnetworks/PROXY_SUBNET_NAME
gatewaySecurityPolicy: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/GATEWAY_SECURITY_POLICY_NAME

Ersetzen Sie Folgendes:

PROJECT_ID: ID Ihres Projekts in Google Cloud
REGION: Region, in der Ihr Secure Web Proxy-Gateway erstellt wird
SECURE_WEB_PROXY_NAME: Name Ihres Secure Web Proxy-Gateways
SWP_IP_ADDRESS: IP-Adresse Ihres Secure Web Proxy-Gateways
SWP_CERTIFICATE_NAME: Name des Zertifikats, das mit Ihrem Secure Web Proxy-Gateway verknüpft ist
SERVER_TLS_POLICY_NAME: Name der ServerTlsPolicy-Ressource
NETWORK_NAME: Name des VPC-Netzwerk
PROXY_SUBNET_NAME: Name des Nur-Proxy-Subnetzes
GATEWAY_SECURITY_POLICY_NAME: Name der GatewaySecurityPolicy-Ressource

Führen Sie den Befehl gcloud network-services gateways import aus, um das Secure Web Proxy-Gateway zu importieren.

gcloud network-services gateways import SECURE_WEB_PROXY_NAME \
    --source=swp.yaml \
    --location=REGION \
    --project=PROJECT_ID

So ändern Sie diese Felder auf einem vorhandenen Secure Web Proxy-Gateway, ohne dass es zu Ausfallzeiten der Arbeitslast kommt:

Erstellen Sie ein weiteres Secure Web Proxy-Gateway mit einem neuen Namen und der erforderlichen Konfiguration.
Aktualisieren Sie die agentGateway-Ressource (selfManaged.resourceUris), um auf das neue Secure Web Proxy-Gateway zu verweisen.
Aktualisieren Sie Ihre EgressRouting-Ressource, sodass sie auf das neue Secure Web Proxy-Gateway verweist.
Nachdem Sie geprüft haben, ob das neue Gateway Traffic-Routen erfolgreich verwaltet, entfernen Sie das alte Secure Web Proxy-Gateway aus der agentGateway-Ressource und löschen Sie dann die alte Gateway-Ressource.

Secure Web Proxy-Instanz mit einem Agent Gateway verknüpfen

So verknüpfen Sie Ihre Secure Web Proxy-Instanz mit einer agentGateway-Ressource:

Erstellen Sie eine Konfigurationsdatei mit dem Namen agent-gateway.yaml.
```
name: projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME
selfManaged:
  resourceUris:
    - //networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/gateways/SECURE_WEB_PROXY_NAME
registries:
  - //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION
```
Ersetzen Sie Folgendes:
- PROJECT_ID: ID Ihres Projekts in Google Cloud
- REGION: Region, in der das Agent-Gateway erstellt wird
- AGENT_GATEWAY_NAME: Name des Agent-Gateways
- SECURE_WEB_PROXY_NAME: Name Ihrer Secure Web Proxy-Instanz
Optional: Das Feld registries verknüpft Ihr Agent Gateway mit einer Agent Registry. Wenn Sie die Agent Registry nicht für die Ziel- oder Toolauflösung verwenden möchten, geben Sie das Feld registries nicht an.

Führen Sie den Befehl gcloud beta network-services agent-gateways import aus, um die Ressource agentGateway zu importieren.

gcloud beta network-services agent-gateways import AGENT_GATEWAY_NAME \
    --source=agent-gateway.yaml \
    --location=REGION \
    --project=PROJECT_ID

Erweiterungsbindungen und Autorisierungsrichtlinien konfigurieren

Wenn Sie den ausgehenden Traffic von KI-Agenten steuern möchten, konfigurieren Sie Erweiterungsbindungen und Autorisierungsrichtlinien für Ihre agentGateway-Ressource. Der Proxy ignoriert alle Richtlinien, die direkt an die zugrunde liegende Secure Web Proxy-Ressource Gateway angehängt sind.

Agent Gateway unterstützt die folgenden beiden Governance-Ebenen:

Erweiterungsbindungen: Hängen Sie externe Sicherheits- und Governance-Dienste wie IAP und Model Armor mithilfe von Service Extensions direkt an Ihr Agent Gateway an.
Autorisierungsrichtlinien: Erzwingen von L7-MCP-Methodeneinschränkungen und L4-Netzwerkregeln.

Erweiterungsbindungen an das KI-Agenten-Gateway anhängen

Verwenden Sie Erweiterungsbindungen in Service Extensions, um verwaltete Dienste an Ihr Agent Gateway zu binden, um KI-Agenteninteraktionen zu prüfen, zu authentifizieren und zu steuern.

Schritt 1: Identity-Aware Proxy (IAP) an Ihr Agent Gateway binden

Wenn Sie die Identität von KI-Agenten überprüfen und Zugriffsrichtlinien erzwingen möchten, bevor der Traffic die Zieltools erreicht, binden Sie IAP an Ihr KI-Agenten-Gateway. Gehen Sie dazu so vor:

Erstellen Sie eine Konfigurationsdatei mit dem Namen ext-binding-iap.yaml.

name: ext-binding-iap
target:
  resources:
  - "//networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME"
failOpen: false
producerExtension: iap.googleapis.com
matchConditions:
- to:
    destination:
      resources:
      - prefix: "urn:mcp"
    notDestinations:
      hosts:
      - suffix: ".googleapis.com"

Ersetzen Sie Folgendes:

PROJECT_ID: ID Ihres Projekts in Google Cloud
REGION: Region, in der die Erweiterungsbindung erstellt wird
AGENT_GATEWAY_NAME: Name des Agent-Gateways

Führen Sie den gcloud beta service-extensions extension-bindings import-Befehl aus, um die Erweiterungsbindung zu importieren.

gcloud beta service-extensions extension-bindings import ext-binding-iap \
    --source=extension-binding-iap.yaml \
    --location=REGION

Weitere Informationen finden Sie unter Autorisierung an IAP delegieren.

Schritt 2: Model Armor für die Bereinigung von Prompts und Antworten binden

So binden Sie Model Armor an Ihr Agent Gateway, um sich vor Prompt Injection, toxischen Inhalten und Datenlecks sensibler Daten zu schützen:

Erstellen Sie eine Konfigurationsdatei mit dem Namen ext-binding-model-armor.yaml.

name: ext-binding-model-armor
target:
  resources:
  - "//networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME"
failOpen: false
producerExtension: modelarmor.googleapis.com
producerMetadata:
  model_armor_settings: '[
    {
      "request_template_id": "projects/PROJECT_ID/locations/REGION/templates/REQUEST_TEMPLATE_ID",
      "response_template_id": "projects/PROJECT_ID/locations/REGION/templates/RESPONSE_TEMPLATE_ID"
    }
  ]'
matchConditions:
- to:
    destination:
      resources:
      - prefix: "urn:mcp"

Ersetzen Sie Folgendes:

PROJECT_ID: ID Ihres Projekts in Google Cloud
REGION: Region, in der die Erweiterungsbindung erstellt wird
AGENT_GATEWAY_NAME: Name des Agent-Gateways
REQUEST_TEMPLATE_ID: ID der Model Armor-Anfragevorlage
RESPONSE_TEMPLATE_ID: ID der Model Armor-Antwortvorlage

Führen Sie den gcloud beta service-extensions extension-bindings import-Befehl aus, um die Erweiterungsbindung zu importieren.

gcloud beta service-extensions extension-bindings import ext-binding-model-armor \
    --source=extension-binding-model-armor.yaml \
    --location=REGION

Weitere Informationen finden Sie unter Autorisierung an Model Armor delegieren und Beispiel 3: Deep Payload Inspection mit Model Armor mithilfe von Erweiterungsbindungen aktivieren in Autorisierungsrichtlinien für Secure Web Proxy einrichten.

MCP-Tools mithilfe von Autorisierungsrichtlinien einschränken

So beschränken Sie die Erkennung und Ausführung von Agent-Tools auf genehmigte Tools: Erstellen und importieren Sie eine Autorisierungsrichtlinie. Gehen Sie dazu so vor:

Erstellen Sie eine Konfigurationsdatei mit dem Namen authz-policy-restrict-mcp-tools.yaml.

name: authz-policy-restrict-mcp-tools
target:
  resources:
  - "projects/PROJECT_ID/locations/REGION/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

Ersetzen Sie Folgendes:

PROJECT_ID: ID Ihres Projekts in Google Cloud
REGION: Region, in der die Autorisierungsrichtlinie erstellt wird
AGENT_GATEWAY_NAME: Name des Agent-Gateways

Führen Sie den Befehl gcloud network-security authz-policies import aus, um die Autorisierungsrichtlinie zu importieren.

gcloud network-security authz-policies import authz-policy-restrict-mcp-tools \
    --source=authz-policy-restrict-mcp-tools.yaml \
    --location=REGION \
    --project=PROJECT_ID

KI-Agenten über Agent Gateway weiterleiten

Nachdem Sie Ihr Agent Gateway konfiguriert und Autorisierungsrichtlinien daran angehängt haben, müssen Sie Ihre Agent-Laufzeitumgebungen so konfigurieren, dass der ausgehende Traffic an Ihre Secure Web Proxy-Instanz weitergeleitet wird. Das Routing von ausgehendem Traffic erfolgt transparent auf der Netzwerkebene. Anfragen werden an das Gateway weitergeleitet, ohne dass der Code Ihrer Agent-Anwendung geändert werden muss.

Je nachdem, wo Ihre KI-Arbeitslasten ausgeführt werden, finden Sie in den folgenden Dokumentationsressourcen Informationen zum Konfigurieren des ausgehenden Routings:

GKE: Verwenden Sie das Ambient Networking von Cloud Service Mesh, um ausgehenden Agent-Traffic auf Knotenebene abzufangen und dann über einen HTTP-CONNECT-Tunnel an Ihre Secure Web Proxy-Instanz weiterzuleiten. Informationen zum Konfigurieren von Routingrichtlinien für Ihren Cluster finden Sie unter Ambient-Ausgangstraffic über Secure Web Proxy weiterleiten und Agent Gateway für GKE.
Cloud Run: Konfigurieren Sie den ausgehenden Direct VPC-Traffic so, dass ausgehender Agent-Traffic an Ihr VPC-Netzwerk gesendet wird. Dort leitet das Ambient Networking von Cloud Run die Anfragen über einen HTTP-CONNECT-Tunnel, der die Identität des Agents enthält, an Ihre Secure Web Proxy-Instanz weiter. Informationen zum Einrichten des Routings für ausgehenden Traffic finden Sie unter Direct VPC mit einem VPC-Netzwerk und Agent Gateway für Cloud Run.

Telemetrie, Logging und Monitoring

Wenn Ihr Secure Web Proxy-Gateway mit einer Agent-Gateway-Ressource verknüpft ist, werden Transaktionslogs unter der standardmäßigen überwachten Secure Web Proxy-Ressource networkservices.googleapis.com/Gateway ausgegeben. Logging ist standardmäßig mit einer Abtastrate von 1.0 aktiviert.

Logging

Logeinträge in Cloud Logging verwenden das Format LoadBalancerLogEntry und enthalten die folgenden Felder für KI-Agenten und Sicherheitsnutzlasten:

agentGatewayInfo: enthält Metadaten zur Agent-Transaktion:
- agentRegistryResource: Vollständiger Ressourcenname des übereinstimmenden Agent Registry-Ziels, z. B. ein MCP-Server oder ein Skill
- destinationUrn: Informationen zum Ziel-URN
- mcpInfo: Details zum MCP-JSON-RPC-Aufruf, einschließlich der Methode, z. B. tools/call oder resources/read, und des Toolnamens oder Ressourcen-URIs
authzPolicyInfo: Ergebnisse der Autorisierungsbewertung (ALLOWED oder DENIED) und die Namen der übereinstimmenden Richtlinien
tls: TLS-Verhandlungsdetails und kryptografische Clientzertifikat-Verifizierungsattribute (mTLS), z. B. clientCertPresent und clientCertSha256Fingerprint

Messwerte überwachen

Das Agent-Gateway exportiert die folgenden Messwerte nach Cloud Monitoring:

MCP-Dauer:
- gcp.mcp.server.operation.duration: Latenz von Vorgängen, die der MCP-Toolserver ausführt
- gcp.mcp.client.operation.duration: End-to-End-Roundtrip-Dauer eines MCP-Clientaufrufs
HTTP-Latenz:
- http.server.request.duration: Ausführungslatenz für eingehende Agent-Anfragen, die vom Gateway verarbeitet werden
- http.client.request.duration: Latenz für ausgehende Anfragen vom Proxy an externe Ziele
Traffic-Durchsatz:
- gcp.server.request.total_size und gcp.server.response.total_size: Größe der Anfragen und Antworten, die das Gateway empfängt und sendet, in Byte
- gcp.client.request.total_size und gcp.client.response.total_size: Größe der Anfragen und Antworten in Byte, die das Gateway an externe Ziele sendet

Secure Web Proxy als Agent-Gateway bereitstellen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Übersicht

Vorteile

Architektur

Hinweis

TLS-Prüfung einrichten

Secure Web Proxy bereitstellen

Secure Web Proxy-Instanz mit einem Agent Gateway verknüpfen

Erweiterungsbindungen und Autorisierungsrichtlinien konfigurieren

Erweiterungsbindungen an das KI-Agenten-Gateway anhängen

Schritt 1: Identity-Aware Proxy (IAP) an Ihr Agent Gateway binden

Schritt 2: Model Armor für die Bereinigung von Prompts und Antworten binden

MCP-Tools mithilfe von Autorisierungsrichtlinien einschränken

KI-Agenten über Agent Gateway weiterleiten

Telemetrie, Logging und Monitoring

Logging

Messwerte überwachen

Nächste Schritte

Secure Web Proxy als Agent-Gateway bereitstellen