> [!WARNING] > > **Preview** > > > This product or feature is > > subject to the "Pre-GA Offerings Terms" in the General Service Terms section > of the [Service Specific > Terms](https://docs.cloud.google.com/terms/service-terms#1). > > Pre-GA products and features are available "as is" and might have limited support. > > For more information, see the > [launch stage descriptions](https://cloud.google.com/products/#product-launch-stages). This page describes how to configure authorization policies for Secure Web Proxy. ## Before you begin - Review the [Secure Web Proxy overview](https://docs.cloud.google.com/secure-web-proxy/docs/overview.md.txt) and [Authorization policy overview](https://docs.cloud.google.com/load-balancing/docs/auth-policy/auth-policy-overview) pages. - [Enable the following APIs](https://docs.cloud.google.com/secure-web-proxy/docs/initial-setup-steps.md.txt#enable-apis): - Network Security API - Network Services API - Certificate Manager API - Make sure that you have the appropriate [roles and permissions](https://docs.cloud.google.com/secure-web-proxy/docs/roles-permissions.md.txt). - You must have an active Secure Web Proxy instance deployed and associated with a `GatewaySecurityPolicy`. For more information, see [Deploy a Secure Web Proxy instance](https://docs.cloud.google.com/secure-web-proxy/docs/quickstart.md.txt). - To configure Secure Web Proxy authorization policies, you must [enable a TLS inspection policy](https://docs.cloud.google.com/secure-web-proxy/docs/enable-tls-inspection). ## Create an authorization policy You can configure authorization policies for two distinct use cases: - **Govern agentic traffic** : to secure outbound traffic from AI agents to *Model Context Protocol* (*MCP* ) servers, tools, and models, see [Configure authorization policies for agentic destinations](https://docs.cloud.google.com/secure-web-proxy/docs/setup-authz-policies#authz-policy-agentic-mcp). You can configure policies and extension bindings on the `agentGateway` resource to enforce MCP tool restrictions, mTLS agent identities, and payload sanitization. - **Secure non-agentic web traffic** : to secure outbound web traffic from non-agentic enterprise workloads, see the examples in the subsequent sections. You can configure policies directly on the Secure Web Proxy `Gateway` resource to enforce mTLS client certificate identities, service accounts, secure tags, or custom authorization extensions. To create an [authorization policy](https://docs.cloud.google.com/secure-web-proxy/docs/policies-and-rules-overview#authorization-policies) for Secure Web Proxy, do the following: - Configure a YAML file that defines the target and rules. - To import the YAML file, run the [`gcloud network-security authz-policies import` command](https://docs.cloud.google.com/sdk/gcloud/reference/network-security/authz-policies/import). ## Configure authorization policies for agentic destinations When you [deploy Secure Web Proxy as an Agent Gateway](https://docs.cloud.google.com/secure-web-proxy/docs/deploy-swp-as-agent-gateway), you can define authorization policies to inspect and restrict the traffic that's directed to MCP tool servers and AI agent destinations. You can configure rules that enforce access control at the following request layers: - **Network rules**: skip TLS inspection or deep payload analysis for specific trusted external model or agent endpoints. - **Extension bindings** : use [`ExtensionBinding` resources in Service Extensions](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/extension-bindings-overview) to attach external governance and security processors, such as Identity-Aware Proxy (IAP) for agent identity verification and Model Armor for prompt and response sanitization. - **HTTP MCP method and tool filtering** : enforce fine-grained controls over specific MCP actions, such as `tools/list` or `tools/call`, and validate arguments to restrict the tools that an agent can invoke. ### Order of evaluation for authorization rules When processing outbound AI agent traffic through an Agent Gateway, rules are evaluated in the following sequence: 1. **Network (L4) authorization rules**: evaluated first. If an SNI match rule applies, such as allowing direct communication to an external model endpoint, traffic bypasses TLS interception. 2. **TLS interception**: traffic that isn't bypassed is then intercepted and decrypted by using the gateway's TLS inspection policy. 3. **Extension binding rules**: requests are evaluated by configured extension services, such as IAP, to verify the caller identity on request headers and Model Armor to inspect decrypted payloads for prompt safety and prevent sensitive data leaks in responses. 4. **HTTP (L7) authorization rules**: HTTP-level authorization policies, such as MCP tool restrictions and method filtering, are evaluated. ### Example 1: Restrict MCP tool execution The following example shows an authorization policy attached to an `agentGateway` resource that allows agents to discover tools (`tools/list`) and run only approved tools (`tools/call` for `get_weather` and `get_location`): 1. Create a file named `authz-policy-mcp.yaml`. ```yaml name: authz-policy-restrict-tools target: resources: - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME" policyProfile: REQUEST_AUTHZ httpRules: - to: operations: - mcp: baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS methods: - name: "tools/list" - name: "tools/call" params: - exact: "get_weather" - exact: "get_location" action: ALLOW ``` Replace the following: - `PROJECT_ID`: ID of your Google Cloud project - `LOCATION`: region where your Agent Gateway and Secure Web Proxy instances are deployed - `AGENT_GATEWAY_NAME`: name of the `agentGateway` resource that's associated with your Secure Web Proxy gateway 2. To import the authorization policy, run the [`gcloud network-security authz-policies import` command](https://docs.cloud.google.com/sdk/gcloud/reference/network-security/authz-policies/import). ``` gcloud network-security authz-policies import authz-policy-restrict-tools \ --source=authz-policy-mcp.yaml \ --location=LOCATION ``` ### Example 2: Bypass TLS interception by using SNI matching If certain external model providers or agentic APIs use certificate pinning or don't require payload inspection, then you can use network rules to match the Server Name Indication (SNI) and allow the connection without decrypting the session. 1. Create a file named `authz-policy-sni.yaml`. ```yaml name: authz-policy-skip-interception target: resources: - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME" policyProfile: REQUEST_AUTHZ networkRules: - to: operations: - snis: - exact: "api.example-model-provider.com" action: ALLOW ``` Replace the following: - `PROJECT_ID`: ID of your Google Cloud project - `LOCATION`: region where your Agent Gateway and Secure Web Proxy instances are deployed - `AGENT_GATEWAY_NAME`: name of the `agentGateway` resource that's associated with your Secure Web Proxy gateway 2. To import the authorization policy, run the [`gcloud network-security authz-policies import` command](https://docs.cloud.google.com/sdk/gcloud/reference/network-security/authz-policies/import). ``` gcloud network-security authz-policies import authz-policy-skip-interception \ --source=authz-policy-sni.yaml \ --location=LOCATION ``` ### Example 3: Enable deep payload inspection with Model Armor by using extension bindings To guard against prompt injection, toxic output, or sensitive data leakage, you can offload traffic processing to Model Armor or a custom `ext_proc` processor by using extension bindings in Service Extensions. This model separates the extension provider from the consumer in the following way: - **Google services (1P)** : for built-in Google services, such as Model Armor and IAP, Google manages the underlying infrastructure. You can directly bind the service by using predefined endpoint URIs (`modelarmor.googleapis.com` or `iap.googleapis.com`). - **Custom and partner extensions (2P/3P)** : for custom internal processors or third-party security vendors, the producer publishes a `ProducerExtension` resource that points to their Private Service Connect service attachment and the consumer binds that resource URI. For more information about how authorization policies and extensions are evaluated on an `agentGateway` resource, see [Delegate authorization with Service Extensions](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/delegate-authorization) and [Extensible policies on Agent Gateway](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/extension-bindings-overview). To configure an extension binding for Model Armor, do the following: 1. Enable the Service Extensions API. ``` gcloud services enable serviceextensions.googleapis.com ``` 2. Create a configuration file named `extension-binding-model-armor.yaml` that targets your `agentGateway` resource, sets your inspection templates, and intercepts the traffic destined for MCP servers. ```yaml name: ext-binding-model-armor target: resources: - "//networkservices.googleapis.com/projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME" failOpen: false producerExtension: modelarmor.googleapis.com producerMetadata: model_armor_settings: '[ { "request_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID", "response_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID" } ]' matchConditions: - to: destination: resources: - prefix: "urn:mcp" ``` Replace the following: - `PROJECT_ID`: ID of your Google Cloud project - `LOCATION`: region where your Agent Gateway and Secure Web Proxy instances are deployed - `AGENT_GATEWAY_NAME`: name of your `agentGateway` resource - `TEMPLATE_PROJECT_ID`: project ID where your Model Armor templates are created - `REQUEST_TEMPLATE_ID`: ID of the template that's used to inspect incoming requests - `RESPONSE_TEMPLATE_ID`: ID of the template that's used to inspect outgoing responses **Note**: - `failOpen: false` blocks traffic if the extension service is unreachable. To allow traffic to pass through uninspected during service disruptions, set `failOpen: true`. - To bind a custom internal or third-party extension instead of Model Armor, set `producerExtension` to the producer's resource path in the following format: `projects/PRODUCER_PROJECT_ID/locations/LOCATION/producerExtensions/PRODUCER_EXTENSION_NAME`. 3. To import the extension binding, run the [`gcloud beta service-extensions extension-bindings import` command](https://docs.cloud.google.com/sdk/gcloud/reference/beta/service-extensions/extension-bindings/import). ``` gcloud beta service-extensions extension-bindings import ext-binding-model-armor \ --source=extension-binding-model-armor.yaml \ --location=LOCATION ``` For more information about binding IAP for identity verification, see [Attach extension bindings to Agent Gateway](https://docs.cloud.google.com/secure-web-proxy/docs/deploy-swp-as-agent-gateway#extension-bindings). ## Authorization policy based on mTLS identity Secure Web Proxy supports enforcing security rules based on identities derived from mutual TLS (mTLS) certificates. Enforcing rules based on these identities is particularly useful in zero-trust environments, where the traffic between clients and the proxy is secured by mTLS. For more information, see [Authorization policy based on principals](https://docs.cloud.google.com/load-balancing/docs/auth-policy/auth-policy-overview#authz-policy-principals). The following example shows an authorization policy for a Secure Web Proxy instance named `swp1`. This example assumes that the traffic to the proxy uses HTTPS protocol. The policy with the `REQUEST_AUTHZ` profile enforces that all traffic to [example.com/mcp](https://example.com/mcp) requires mTLS authentication from a specific principal before the traffic is allowed to pass through. The policy also denies all outbound traffic that isn't intended to go to [example.com/mcp](https://example.com/mcp). 1. Create the authorization policy YAML file. The following example creates an `authz-policy.yaml` file. The policy allows traffic to the specified host and path only if the client presents a certificate that matches the defined `SPIFFE ID` principal. ```yaml $ cat >authz-policy.yaml <authz-policy.yaml <authz-policy-tag.yaml < [!IMPORTANT] > **Important:** Secure Web Proxy supports only authorization extensions that use a fully qualified domain name (FQDN). When you configure a policy with a `CUSTOM` action, Secure Web Proxy offloads the request metadata or payload to Service Extensions. Depending on the response from Service Extensions, the proxy either allows or rejects the traffic. Secure Web Proxy supports the following types of delegations: - [Delegate request authorization decisions to Service Extensions](https://docs.cloud.google.com/service-extensions/docs/configure-extensions-for-swp.md.txt#configure-swp-request): you can use an authorization policy that's configured with a `CUSTOM` action and a `REQUEST_AUTHZ` profile to delegate decisions based on request metadata and headers. In this mode, the access decision is delegated to an authorization extension. You can use this mode to verify identities and permissions. - [Delegate content authorization decisions to Service Extensions](https://docs.cloud.google.com/service-extensions/docs/configure-extensions-for-swp.md.txt#configure-swp-content): you can use an authorization policy with a `CUSTOM` action and a `CONTENT_AUTHZ` profile to delegate decisions to an authorization extension based on the actual data payload of the request. This mode lets you enable deep content inspection and security enforcement, letting you scan for sensitive information or malicious patterns by integrating with services like Model Armor. ## Limitations When you implement authorization policies for Secure Web Proxy, the following limitations apply: - **Target and connectivity constraints**: authorization extensions for Secure Web Proxy don't support IAP as a direct target. - **Policy conflict and compatibility** : if you have a [gateway security policy](https://docs.cloud.google.com/secure-web-proxy/docs/policies-and-rules-overview#policies-overview) with existing security rules, then you don't need to remove them. Secure Web Proxy ignores these rules when you apply an authorization policy to your instance. - **Protocol and inspection requirements** : to configure Secure Web Proxy authorization policies, you must [enable TLS inspection](https://docs.cloud.google.com/secure-web-proxy/docs/enable-tls-inspection). ## What's next - [Use frontend mTLS with Secure Web Proxy](https://docs.cloud.google.com/secure-web-proxy/docs/use-frontend-mtls-with-swp.md.txt)