Deploy Secure Web Proxy as an Agent Gateway

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

This page describes how to configure and deploy your Secure Web Proxy instance as an Agent Gateway.

Overview

Enterprise AI workloads deployed across Google Cloud require structured network boundaries to maintain data privacy compliance, prevent sensitive data leaks, and protect against emerging AI threats such as prompt injection.

Agent Gateway provides centralized security governance, identity enforcement, and content guardrails for outbound traffic from AI agents to large language models (LLMs), Model Context Protocol (MCP) tools, external APIs, remote agents, and standard web destinations.

You can deploy either a Google-managed Agent Gateway or a Secure Web Proxy instance as a self-managed Agent Gateway. Both deployment models provide a common Gemini Enterprise Agent Platform governance solution, including centralized access policies, Agent Registry integration, and content guardrails.

Choose between the following deployment options based on your operational preferences:

• Google-managed Agent Gateway: use this option if you want a fully managed, zero-maintenance experience without the need to manage network proxy infrastructure. For more information, see Google-managed Agent Gateway. This model is optimized for agents that run on either Gemini Enterprise or Agent Runtime on Gemini Enterprise Agent Platform.

• Secure Web Proxy as a self-managed Agent Gateway: deploy your Secure Web Proxy instance as an Agent Gateway if you want to retain full control over your VPC network perimeter, private CA certificates, and proxy routing to support agents that run on Google Kubernetes Engine (GKE) or Cloud Run.

Benefits

Deploying Secure Web Proxy as an Agent Gateway provides the following benefits:

• Customer-controlled infrastructure: you can manage the Secure Web Proxy gateway in your own Virtual Private Cloud (VPC) network, retaining full control over network routing, IP addressing, private CA certificates, and TLS inspection.

• Centralized AI policy enforcement: you can define authorization policies on an agentGateway resource. This lets you directly enforce these policies on your Secure Web Proxy gateway to restrict MCP tool calls, filter the external destinations of AI agents, and invoke content sanitization services like Model Armor.

• Runtime support: you can route outbound traffic from AI agents that are hosted across various runtimes, such as GKE or Cloud Run, through a single proxy perimeter.

• Agent-aware observability: transaction logs in Cloud Logging automatically contain AI agent execution metadata (agentGatewayInfo), including MCP methods, tool names, and Uniform Resource Names (URNs) of Agent Registry destinations.

Architecture

The following steps show how Secure Web Proxy secures outbound traffic as an Agent Gateway:

1. Agent runtimes: autonomous agents that run on either GKE or Cloud Run initiate outbound connections to external APIs, model providers, MCP tool servers, remote agents, or standard web destinations.

2. Outbound traffic routing: agent traffic is directed to Secure Web Proxy by using in-VPC proxy routing or cross-VPC Private Service Connect (PSC) service attachments.

3. Policy evaluation and content sanitization: Secure Web Proxy terminates TLS connections, enforces MCP authorization policies, and invokes extension services such as Model Armor or Identity-Aware Proxy (IAP) to sanitize payloads and verify client identity.

Before you begin

Before deploying your Secure Web Proxy instance as an Agent Gateway, complete the following prerequisites:

1. Enable the following required 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
   

2. Make sure that you have the following required Identity and Access Management (IAM) roles:

   • Compute Network Admin role (roles/compute.networkAdmin)
   • Network Security Admin role (roles/networksecurity.admin)
   • CA Service Admin role (roles/privateca.admin)

3. Configure the following environment variables for your deployment:

   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"
   

4. Optional: If your agent runtimes operate in separate VPC networks or managed environments, such as cross-project GKE or Cloud Run clusters, then you must expose Secure Web Proxy through a Private Service Connect service attachment:

   • Create a PSC NAT subnet with --purpose=PRIVATE_SERVICE_CONNECT.
   • Create a service attachment that targets your Secure Web Proxy gateway. For more information, see Deploy Secure Web Proxy as a Private Service Connect service.

Set up TLS inspection

Secure Web Proxy terminates TLS connections to inspect HTTP headers, evaluate MCP methods, and sanitize payloads.

To configure TLS inspection, create a private Certificate Authority (CA) pool, a root CA, and then a tlsInspectionPolicy resource by doing the following:

1. Create a private CA pool.

   gcloud privateca pools create CA_POOL_NAME \
       --location=REGION \
       --tier=devops \
       --project=PROJECT_ID
   

   Replace the following:

   • CA_POOL_NAME: name of the CA pool
   • REGION: region where the CA pool is created
   • PROJECT_ID: ID of your Google Cloud project

2. Create a root CA in the private 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
   

   Replace the following:

   • ROOT_CA_NAME: name of the root CA
   • CA_POOL_NAME: name of the CA pool
   • REGION: region where the root CA is created
   • PROJECT_ID: ID of your Google Cloud project

   Note: To let client workloads, such as Cloud Run or GKE, to trust the certificates issued by this CA pool during TLS inspection, export the root CA certificate and then add it to your workload's trust store. For example, you can set the AGENT_GATEWAY_ROOT_CERTIFICATES environment variable.

3. Grant the Network Security service account permission to request certificates.

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

4. Create the tlsInspectionPolicy resource in a file named 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
   

   Replace the following:

   • PROJECT_ID: ID of your Google Cloud project
   • REGION: region where the TlsInspectionPolicy is created
   • TLS_INSPECTION_POLICY_NAME: name of the TlsInspectionPolicy resource
   • CA_POOL_NAME: name of the CA pool

5. To import the policy, run the gcloud network-security tls-inspection-policies import command.

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

Deploy Secure Web Proxy

Create a Secure Web Proxy gateway with mutual TLS (mTLS) configured.

1. Make sure that your VPC network has a proxy-only subnet in the region where you want to deploy the gateway.

   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
   

   Replace the following:

   • PROXY_SUBNET_NAME: name of the proxy-only subnet
   • NETWORK_NAME: name of your VPC network
   • REGION: region where the subnet is created

2. Optional: Select an available IP address from your proxy-only subnet range—for example, 10.129.0.10 within 10.129.0.0/23—to assign to your SWP_IP_ADDRESS.

   Note: If you don't add the addresses field in the swp.yaml file, Secure Web Proxy automatically allocates an IP address from the proxy-only subnet.

3. To make sure that your Secure Web Proxy gateway can securely accept incoming client agent connections, create a regional SSL/TLS server certificate in Certificate Manager.

   1. Generate a self-managed certificate and private key.

      openssl req -x509 -newkey rsa:2048 -nodes \
          -keyout "swp.key" \
          -out "swp.crt" \
          -days 365 \
          -subj "/CN=SWP_IP_ADDRESS"
      

      Replace SWP_IP_ADDRESS with the IP address of your Secure Web Proxy gateway.

   2. To upload the certificate into Certificate Manager, run the gcloud certificate-manager certificates create command.

      gcloud certificate-manager certificates create SWP_CERTIFICATE_NAME \
          --location=REGION \
          --certificate-file="swp.crt" \
          --private-key-file="swp.key" \
          --project=PROJECT_ID
      

      Replace the following:

      • SWP_CERTIFICATE_NAME: name of the certificate resource
      • REGION: region where the certificate is created
      • PROJECT_ID: ID of your Google Cloud project

4. To enable frontend mTLS, create a ServerTlsPolicy resource. To allow workloads, such as Cloud Run, to pass their identity certificates to services like IAP, configure the policy with clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

   Note: If you use IAP, then don't set any value for the clientValidationTrustConfig field because it isn't supported.

   1. Create a file named server-tls-policy.yaml, and then add the following content:

      name: projects/PROJECT_ID/locations/REGION/serverTlsPolicies/SERVER_TLS_POLICY_NAME
      mtlsPolicy:
        clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
      

      Replace the following:

      • PROJECT_ID: ID of your Google Cloud project
      • REGION: region where the ServerTlsPolicy is created
      • SERVER_TLS_POLICY_NAME: name of the ServerTlsPolicy resource

   2. To import the policy, run the gcloud network-security server-tls-policies import command.

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

5. Create a gateway security policy to attach your tlsInspectionPolicy.

   1. Create a file named gateway-security-policy.yaml, and then add the following content:

      name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/GATEWAY_SECURITY_POLICY_NAME
      tlsInspectionPolicy: projects/PROJECT_ID/locations/REGION/tlsInspectionPolicies/TLS_INSPECTION_POLICY_NAME
      

      Replace the following:

      • PROJECT_ID: ID of your Google Cloud project
      • REGION: region where the GatewaySecurityPolicy is created
      • GATEWAY_SECURITY_POLICY_NAME: name of the GatewaySecurityPolicy resource
      • TLS_INSPECTION_POLICY_NAME: name of the TlsInspectionPolicy resource

   2. To import the policy, run the gcloud network-security gateway-security-policies import command.

      gcloud network-security gateway-security-policies import GATEWAY_SECURITY_POLICY_NAME \
          --source=gateway-security-policy.yaml \
          --location=REGION \
          --project=PROJECT_ID
      

6. Create a Secure Web Proxy specification file named 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
   

   Replace the following:

   • PROJECT_ID: ID of your Google Cloud project
   • REGION: region where your Secure Web Proxy gateway is created
   • SECURE_WEB_PROXY_NAME: name of your Secure Web Proxy gateway
   • SWP_IP_ADDRESS: IP address of your Secure Web Proxy gateway
   • SWP_CERTIFICATE_NAME: name of the certificate associated with your Secure Web Proxy gateway
   • SERVER_TLS_POLICY_NAME: name of the ServerTlsPolicy resource
   • NETWORK_NAME: name of your VPC network
   • PROXY_SUBNET_NAME: name of the proxy-only subnet
   • GATEWAY_SECURITY_POLICY_NAME: name of the GatewaySecurityPolicy resource

7. To import the Secure Web Proxy gateway, run the gcloud network-services gateways import command.

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

Note: After you create a Secure Web Proxy gateway, you can't change the addresses and ports fields. In addition, if you update an existing gateway's serverTlsPolicy or certificateUrls, the changes aren't automatically propagated to workloads, such as Cloud Run, that use the EgressRouting resource.

To change these fields on an existing Secure Web Proxy gateway without causing workload downtime, do the following:

1. Create another Secure Web Proxy gateway with a new name and the required configuration.

2. Update the agentGateway resource (selfManaged.resourceUris) to reference the new Secure Web Proxy gateway.

3. Update your EgressRouting resource to point to the new Secure Web Proxy gateway.

4. After you verify that the new gateway is successfully managing traffic routes, remove the old Secure Web Proxy gateway from the agentGateway resource and then delete the old gateway resource.

Associate your Secure Web Proxy instance with an Agent Gateway

Note: We recommend that you deploy a dedicated Secure Web Proxy gateway that's connected to an Agent Gateway specifically for AI agent traffic, rather than reusing a proxy that's configured for non-agentic workloads. This separation helps ensure that agent-specific guardrails, such as extension bindings, MCP method filtering, and client identity verification, are isolated from standard gateway security policies.

To associate your Secure Web Proxy instance with an agentGateway resource, do the following:

1. Create a configuration file named 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
   

   Replace the following:

   • PROJECT_ID: ID of your Google Cloud project
   • REGION: region where the Agent Gateway is created
   • AGENT_GATEWAY_NAME: name of the Agent Gateway
   • SECURE_WEB_PROXY_NAME: name of your Secure Web Proxy instance

   Optional: The registries field associates your Agent Gateway with an Agent Registry. If you don't want to use Agent Registry for destination or tool resolution, then don't specify the registries field.

2. To import the agentGateway resource, run the gcloud beta network-services agent-gateways import command.

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

Configure extension bindings and authorization policies

To govern outbound AI agent traffic, configure extension bindings and authorization policies on your agentGateway resource. The proxy ignores any policies that are directly attached to the underlying Secure Web Proxy Gateway resource.

Agent Gateway supports the following two governance layers:

• Extension bindings: attach external security and governance services, such as IAP and Model Armor, directly to your Agent Gateway using Service Extensions.

• Authorization policies: enforce L7 MCP method restrictions and L4 network rules.

Attach extension bindings to Agent Gateway

Use extension bindings in Service Extensions to bind managed services to your Agent Gateway to inspect, authenticate, and control agent interactions.

Step 1: Bind Identity-Aware Proxy (IAP) to your Agent Gateway

To verify agent caller identities and enforce access policies before traffic reaches target tools, bind IAP to your Agent Gateway by doing the following:

1. Create a configuration file named 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"
   

   Replace the following:

   • PROJECT_ID: ID of your Google Cloud project
   • REGION: region where the extension binding is created
   • AGENT_GATEWAY_NAME: name of the Agent Gateway

2. To import the extension binding, run the gcloud beta service-extensions extension-bindings import command.

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

For more information, see Delegate authorization to IAP.

Step 2: Bind Model Armor for prompt and response sanitization

To protect against prompt injection, toxic content, and sensitive data leaks, bind Model Armor to your Agent Gateway by doing the following:

1. Create a configuration file named 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"
   

   Replace the following:

   • PROJECT_ID: ID of your Google Cloud project
   • REGION: region where the extension binding is created
   • AGENT_GATEWAY_NAME: name of the Agent Gateway
   • REQUEST_TEMPLATE_ID: ID of the Model Armor request template
   • RESPONSE_TEMPLATE_ID: ID of the Model Armor response template

2. To import the extension binding, run the gcloud beta service-extensions extension-bindings import command.

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

For more information, see Delegate authorization to Model Armor and Example 3: Enable deep payload inspection with Model Armor by using extension bindings in Set up authorization policies for Secure Web Proxy.

Restrict MCP tools by using authorization policies

To restrict agent tool discovery and execution to approved tools, create and import an authorization policy by doing the following:

1. Create a configuration file named 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
   

   Replace the following:

   • PROJECT_ID: ID of your Google Cloud project
   • REGION: region where the authorization policy is created
   • AGENT_GATEWAY_NAME: name of the Agent Gateway

2. To import the authorization policy, run the gcloud network-security authz-policies import command.

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

Route agents through Agent Gateway

After you configure your Agent Gateway and attach authorization policies to it, you must configure your agent runtime environments to direct their outbound traffic to your Secure Web Proxy instance. Outbound traffic routing operates transparently at the networking layer, redirecting requests to the gateway without modifying your agent application code.

Depending on where your AI workloads run, see the following documentation assets to configure outbound routing:

• GKE: use Cloud Service Mesh ambient networking to intercept outbound agent traffic at the node level and then forward it through an HTTP CONNECT tunnel to your Secure Web Proxy instance. To configure routing policies on your cluster, see Route ambient egress traffic through Secure Web Proxy and Agent Gateway for GKE.
• Cloud Run: configure Direct VPC egress to send outbound agent traffic into your VPC network, where Cloud Run ambient networking redirects the requests to your Secure Web Proxy instance over an HTTP CONNECT tunnel that carries the agent's identity. To set up routing for outbound traffic, see Direct VPC with a VPC network and Agent Gateway for Cloud Run.

Telemetry, logging, and monitoring

When your Secure Web Proxy gateway is associated with an Agent Gateway resource, transaction logs are emitted under the standard Secure Web Proxy networkservices.googleapis.com/Gateway monitored resource. Logging is enabled by default with a sampling rate of 1.0.

Logging

Log entries in Cloud Logging use the LoadBalancerLogEntry format and contain the following AI agent and security payload fields:

• agentGatewayInfo: contains metadata about the agent transaction:

  • agentRegistryResource: full resource name of the matched Agent Registry target, such as an MCP server or skill
  • destinationUrn: information about the destination URN
  • mcpInfo: MCP JSON-RPC call details, including the method such as tools/call or resources/read, and the tool name or resource URI

• authzPolicyInfo: authorization evaluation outcomes (ALLOWED or DENIED) and the names of matching policies

• tls: TLS negotiation details and cryptographic client certificate (mTLS) verification attributes, such as clientCertPresent and clientCertSha256Fingerprint

Monitoring metrics

Agent Gateway exports the following metrics to Cloud Monitoring:

• MCP duration:

  • gcp.mcp.server.operation.duration: latency of operations that the MCP tool server performs
  • gcp.mcp.client.operation.duration: end-to-end round-trip duration of an MCP client call

• HTTP latency:

  • http.server.request.duration: execution latency for incoming agent requests that the gateway processes
  • http.client.request.duration: latency for outbound requests from the proxy to external destinations

• Traffic throughput:

  • gcp.server.request.total_size and gcp.server.response.total_size: size in bytes of requests and responses that the gateway receives and sends
  • gcp.client.request.total_size and gcp.client.response.total_size: size in bytes of requests and responses that the gateway sends to external destinations

What's next

• Configure authorization policies for agentic destinations
• View proxy transaction logs
• Deploy Secure Web Proxy as a Private Service Connect service
• Agent Gateway overview