Cloud Armor WAF Protection for Applications

Design and Implement Google Cloud Armor Security Policies covers how project-wide minimum policies are built and enforced for tool calls and responses, including rule hierarchy and precedence. In this design, Model Armor provides floor settings that act as the minimum security filters for a project, and Identity and Access Management (IAM) provides allow policies and deny policies that control who can invoke integrated services. Traffic flows from an agent to a Google MCP server (opens in a new tab) and back, and Model Armor inspects that traffic when floor-setting enforcement includes the MCP integration. The policy depends on the Model Armor API being enabled in the project where enforcement will apply.

Enforcement is configured in a fixed order. First the API is enabled, then the protected project is selected, then command-line access is prepared, then the endpoint is set before floor settings are updated:

1. Enable the API: Enable modelarmor.googleapis.com in the project where the floor setting will live, which requires the serviceusage.services.enable permission through the Owner role or Service Usage Admin role.
2. Select the project: Choose the project where minimum filters will apply to MCP tool calls and responses.
3. Activate Cloud Shell: Start a Cloud Shell session from the Google Cloud console for CLI access with the Google Cloud CLI already installed and configured.
4. Set the endpoint: Configure the CLI endpoint override for Model Armor to the global or regional endpoint.

Only after the endpoint is set can the floor-setting resource be created or updated in that project.

1.1Floor Settings as Minimum Project Enforcement

Model Armor floor settings are project-wide minimum security filters that apply the same checks to all MCP tool calls and responses within the project. The floor setting lives at projects/PROJECT_ID/locations/global/floorSetting and enforcement is turned on with floor-setting enforcement enabled. Once enabled, the same filters protect every integrated Google MCP server interaction in that project without configuring each tool separately.

The floor setting follows the project boundary when the agent and the MCP server are separated. If the agent is in a client project and the MCP server is in a resource project, floor settings can be created in both projects. In that case Model Armor is invoked twice, once for each project, so traffic is checked against the client-project minimum on one side and the resource-project minimum on the other side. This dual invocation means policy changes in either project affect the same end-to-end tool call. Changes to floor settings can also affect traffic scanning and safety behaviors across all integrated services, not just MCP, including services such as Vertex AI. Do not enable the prompt injection and jailbreak filter unless MCP traffic carries natural language data, because lower-relevance filters can add noise to structured tool traffic.

1.2Configuring Inspection and Blocking for MCP Traffic

Configuring inspection for Google MCP servers attaches the GOOGLE_MCP_SERVER integrated service to the floor setting with blocking enforcement and logging. The update sets enforcement to INSPECT_AND_BLOCK, which inspects content for the Google MCP server and blocks prompts and responses that match the filters. Cloud logging for the Google MCP server records inspection results, while additional filters add malicious-URI detection and Responsible AI checks.

The example configuration uses three enforcement values that work together:

• INSPECT_AND_BLOCK inspects Google MCP server prompts and responses and blocks content that matches the filters.
• ENABLED turns on the malicious-URI filter enforcement for MCP traffic.
• MEDIUM_AND_ABOVE sets the confidence level for the Responsible AI Dangerous filter, where lower values might result in more false positives.

Together these settings move data from the agent through Model Armor inspection to the MCP server, and move the response back through Model Armor inspection to the agent. The floor setting is the source of the minimum policy, and each MCP tool call and response is the destination where the policy is enforced.

1.3Disabling Automatic Scanning and Managing Scope

Disabling automatic scanning removes the GOOGLE_MCP_SERVER integrated service from the floor setting so Model Armor no longer automatically applies that project's floor rules to Google MCP server traffic. The disable operation updates the same floor-setting resource with the integrated service removed and replaces PROJECT_ID with the Google Cloud project ID. After removal, prompts and responses flow between the agent and the MCP server without project floor-setting inspection for MCP.

This scope change should be weighed carefully because floor settings are shared across integrations. Edits made for MCP can change safety behavior for other integrated services that depend on the same floor setting, so narrowing MCP scope can unintentionally weaken or alter protection elsewhere.

1.4Controlling Access with IAM Allow and Deny Policies

Identity and Access Management (IAM) allow policies and deny policies secure Google Cloud and Google MCP servers by controlling which principals can invoke which tools. The IAM policy applies to the MCP service and its tools, while the principal, tool attributes, and client identity determine whether access is allowed or denied. This access layer works with floor-setting inspection, so IAM decides whether the call is permitted and Model Armor decides whether the content is safe.

Customized governance policies combine multiple criteria to allow or deny access:

• The principal requesting access to the MCP server or tool.
• Tool properties such as the read-only attribute of the requested tool.
• The service name or tool name targeted by the call.
• The application's OAuth client ID making the request.

Use IAM when governance requires restricting use by caller or tool, and use floor settings when protection requires inspecting content in every call and response.

Configure Advanced Rate Limiting and Bot Management covers how Google Cloud Armor (opens in a new tab) stops volumetric floods and automated abuse at the network edge before traffic reaches backends. Google Cloud Armor security policies inspect incoming traffic before it reaches backends behind the load balancer, so excessive or automated requests are stopped outside the application. Rate limiting handles too much traffic from one client, while reCAPTCHA Enterprise handles traffic that looks automated rather than human.

2.1Cloud Armor Rate Limiting Rules

Google Cloud Armor rate limiting rules throttle excessive requests to critical endpoints such as /login, /checkout, or search APIs. A rule defines a request threshold over a time window, for example limiting clients to 100 requests per minute, and a key that identifies each client, such as per-client IP or an HTTP header value. When traffic from one key exceeds the threshold, Cloud Armor throttles the excess and returns HTTP 429 Too Many Requests instead of forwarding the requests to the backend. This protects authentication, checkout, and API search paths from credential stuffing, scraping, and Layer 7 DDoS without blocking normal users who stay under the limit.

Cloud Armor rate limiting depends on Google Cloud Armor Adaptive Protection and the policy default rule for full coverage. Adaptive Protection baselines normal traffic patterns, alerts on Layer 7 anomalies, and generates targeted rules with attack signatures that can be added to the security policy. The lowest-priority default rule should be set to Deny with status code 403 or 404, so traffic that matches no allow rule is denied at the edge. In this design, rate limiting throttles abusive-but-possibly-legitimate clients with 429, while the default deny blocks clearly unwanted traffic with 403 or 404.

2.2reCAPTCHA Enterprise Integration with Cloud Armor

reCAPTCHA Enterprise, an offering that is part of Fraud Defense, filters bots and bulk automation by scoring the risk level of each access attempt. When integrated with an existing web application firewall (WAF) such as Google Cloud Armor, reCAPTCHA Enterprise lets Cloud Armor issue automated challenges or block high-risk bot traffic before requests reach authentication endpoints. The flow moves from browser signal to edge enforcement, so the backend only processes traffic that has passed both rate and bot checks.

For websites, reCAPTCHA Enterprise for Cloud Armor uses action-tokens that travel from the page to the edge in an ordered sequence:

1. Generate: reCAPTCHA Enterprise runs on the protected web page and generates an action-token for a user action such as checkout.
2. Attach: The application attaches the action-token to a predefined request header before the token expires, by default within 30 minutes depending on traffic.
3. Evaluate: Traffic flows from the client to Cloud Armor, and Cloud Armor evaluates the token attributes against the security policy.
4. Enforce: Cloud Armor allows, challenges, or blocks the request before it flows from the load balancer to the backend.

Using a separate reCAPTCHA Enterprise key for each WAF feature keeps this flow reliable. A key is bound to specific web domains and enabled for WAF use, with domain verification left on so only the listed domains and their subdomains can use the key. Changes to the domain list can take up to 30 minutes to take effect, so key rotation and domain moves must be planned ahead of enforcement.

2.3Protecting Authentication and High-Value Transactions

Protection for authentication endpoints in reCAPTCHA Enterprise focuses on account takeover, messaging abuse, and stolen credentials. The same Cloud Armor policy that throttles /login can also enforce bot verdicts on login, password reset, and session renewal paths, concentrating both controls where account risk is highest. This pairing matters because rate limiting alone cannot tell a distributed botnet with low per-IP rates from legitimate users, while risk scoring can.

ReCAPTCHA Enterprise account and transaction defenses address different abuse patterns:

• Account takeover defense obtains risk scores on login, password reset, and session renewal based on sign-in velocities and device fingerprints.
• SMS toll fraud defense evaluates phone number risk profiles on registration and two-factor authentication forms before sending outbound SMS messages.
• Password breach checking detects whether submitted credentials appear in third-party breach data during sign-in and account creation.
• Transaction feedback annotation sends labeled outcomes back to reCAPTCHA Enterprise to reduce false positives and train site-specific risk models.

Integrate and Manage WAF with Load Balancing and Monitoring covers where Google Cloud Armor sits in the traffic path and how its policies are attached and tuned. Google Cloud Armor is a web application firewall (WAF) and distributed denial-of-service (DDoS) protection layer that enforces security policy at the edge before traffic reaches application backends. Traffic flows from internet clients to a load balancer frontend, then through Cloud Armor policy evaluation, and only then to the backend service and its backends. This placement lets one policy stack combine WAF filtering, DDoS protection, Transport Layer Security (TLS) termination, traffic management, and caching with Cloud CDN at the same gateway.

3.1Attaching Policies to Load-Balanced Backends

Service-level Cloud Armor enforcement attaches directly to a backend service fronted by a Global external Application Load Balancer or Classic Application Load Balancer. The load balancer exposes a publicly routable global Anycast IP address that minimizes latency, terminates TLS, and applies host-based and path-based routing before forwarding to the protected backend service. Because the policy is bound to the backend service, each service can carry unique rules that differ from other services behind the same or different frontends.

A common ingress pattern using this attachment works as an ordered flow:

1. Client to gateway: Clients on the public internet send traffic to the Google Cloud-managed load balancer acting as the gateway.
2. Policy enforcement at gateway: The gateway applies Cloud Armor, TLS, and traffic-management policies to the incoming request.
3. Gateway to service: The gateway forwards allowed traffic to a service in the mesh or to backend workloads, while denied, redirected, or throttled traffic never reaches the backends.

A more advanced pattern adds a second-level gateway for separation of concerns. Traffic flows first from clients to the managed load balancer, then from that first-level gateway to an edge proxy configured by Cloud Service Mesh, and only then from the edge proxy to the in-mesh service. The second level lets one team own internet ingress while another team owns mesh ingress and can apply policies not supported in the managed load balancer.

3.2Hierarchical Versus Service-Level Enforcement

Hierarchical Cloud Armor policies (opens in a new tab) separate ownership from enforcement to apply consistent WAF rules across multiple projects. A hierarchical policy is created at the organization or folder level, which owns the policy resource, but its rules are not applied until the policy is associated with an organization, folder, or project node. Once associated, all protected resources at and under that node in the resource hierarchy inherit the rules, which supports organization-wide vulnerability mitigation, compliance enforcement, and granular geographic or IP-based access control.

The two policy types support the same frontends but differ in attachment and actions:

Hierarchical policies support only a subset of service-level capabilities, including limited bot management to EXTERNAL_302 redirect and request decoration. The Goto next action is specific to hierarchical evaluation, where control passes to the next rule or policy level instead of terminating with a service-level throttle or rate-based ban. Choose service-level policies when each backend needs distinct Layer 7 filtering, WAF managed rules, Google Threat Intelligence, reCAPTCHA, or Adaptive Protection behavior, and choose hierarchical policies when the same baseline must propagate across many backends.

3.3Associating Policies and Resolving Effective Rules

Association determines where a hierarchical policy takes effect, and only one hierarchy target flag can be used per policy. The owner node and the association node can be the same resource, and policies can later be moved from one hierarchy node to another as ownership or scope changes.

• Organization: Apply baseline rules to all nodes under the organization with broad Identity and Access Management (IAM) control, specified with the --organization flag.
• Folder: Apply the same rules across multiple projects without covering the entire organization, specified with the --folder flag.
• Project: Apply the same rules across all resources in one project, such as an IP denylist across several backend services, specified with the --project flag.
• Service-level: Apply unique rules to a single backend attachment, specified with the --project-number flag.

Additional flags such as --name and --type are configured the same way as for service-level policies. Enforcement for a protected backend is the union of its inherited hierarchical rules and its directly attached service-level rules, and operators can view all effective Cloud Armor rules for a protected resource in a project to resolve overlaps before tuning.

3.4Monitoring Effectiveness and Tuning for Architecture

Monitoring for Cloud Armor-centered architectures relies on Cloud Monitoring (Monitoring) for metrics visibility and request logging for per-request enforcement evidence. Custom and standard metrics reported by the application can be viewed in Cloud Monitoring alongside Cloud Armor telemetry, which lets operators correlate allowed and denied traffic with backend health, latency, and capacity signals. Request logging and Security Command Center integration extend that view from aggregate trends to individual decisions that need rule adjustment.

Operational tuning connects that telemetry back to load-balancing design. For hybrid architectures, Cloud Load Balancing with a hybrid connectivity network endpoint group (NEG) backend can route external and internal client requests to backends both on-premises and in Google Cloud using weight-based traffic splitting and load-balancing serving capacity for autoscaling. That design inherits DDoS protection, WAF, and Cloud CDN edge caching, but hybrid network connectivity must be sized to handle the additional burst traffic or policy enforcement will mask a capacity bottleneck as a security event.

Key Facts

• Model Armor floor settings at projects/PROJECT_ID/locations/global/floorSetting apply minimum filters to all MCP tool calls and responses in a project, and changes affect all integrated services that share the floor setting.
• Google Cloud Armor rate limiting throttles a client key that exceeds its threshold with HTTP 429 Too Many Requests, while the policy default deny rule blocks unmatched traffic with HTTP 403 or 404.
• reCAPTCHA Enterprise action-tokens must be attached to a predefined request header before expiration, by default within 30 minutes, and domain list changes can take up to 30 minutes to take effect.
• A service-level Cloud Armor policy attaches to a single backend service, while a hierarchical policy attaches to an organization, folder, or project node and is inherited by all protected resources below that node.