Use GKE Gateway as an ingress Agent Gateway

When you host autonomous AI agents or Model Context Protocol (MCP) servers in your Google Kubernetes Engine (GKE) clusters, you must secure incoming connections from external clients, developer CLIs, and other services. Because AI agents determine their execution paths dynamically, standard Layer 4 network firewalls cannot fully protect them. By using the GKE Gateway API to deploy a regional Application Load Balancer, you can govern this client-to-agent (ingress) traffic and apply AI-specific security guardrails before requests reach your workloads.

If you are a platform administrator or security engineer who manages GKE networking, you can use this architecture to expose self-managed agents securely.

Why use Agent Gateway for ingress traffic?

Standard microservices rely on predictable, static dependencies. However, AI agents determine their execution paths dynamically based on user prompts. To secure these unpredictable interaction patterns, you can convert a standard GKE Gateway into an Agent Gateway to accomplish the following:

  • Enforce compound authorization: validate both the identity of the calling service and the semantic context of their request payload at the network edge.
  • Decouple security from agent code: apply strict mutual TLS (mTLS) and authorization policies without requiring AI developers to build complex security logic into their agent applications.
  • Sanitize prompts automatically: screen incoming prompts for prompt injection attacks or harmful content before they reach the agent's reasoning engine.

How ingress agent governance works on GKE

To govern inbound traffic to your agents, you combine standard GKE Gateway API resources with Agent Platform governance policies:

  • GKE Gateway: deploy a standard Gateway resource (configured with the gke-l7-regional-external-managed or gke-l7-rilb GatewayClass) to provision a regional HTTP(S) load balancer as your network entry point.
  • Agent Gateway targeting: create a GCPAgentGateway custom resource that targets your Gateway resource, converting the load balancer into a governed Agent Gateway.
  • Identity and access control: apply a GCPAuthzPolicy custom resource to enforce Layer 7 identity-based access controls. You can verify the calling client's SPIFFE ID and restrict access to specific MCP methods or tool names (such as tools/list or tools/call).
  • Content security and custom authorization: attach a Service Extension Binding custom resource to your GCPAgentGateway to route incoming prompts and outgoing responses through Cloud de Confiance by S3NS Model Armor to block prompt injection attacks, or to delegate authorization decisions to a custom identity provider (IDP).

Prerequisites

Before you can configure an ingress Agent Gateway, your GKE environment must meet the following requirements:

  • GKE cluster version: your cluster must run GKE version 1.37.1-gke.1697000 or later.
  • Gateway API: you must enable the GKE Gateway API in your cluster.
  • Agent Identity: you must assign a cryptographic SPIFFE identity to your agent workloads so that the gateway can evaluate identity-based policies. To learn how to assign these identities to your Pods, see About Agent Identity for GKE.
  • Agent Registry: you must register your agent Deployments so that Agent Registry can discover the workloads and sync their metadata. To Registry can discover the workloads and sync their metadata. To register them, add the registry.gke.io/functional-type: "AGENT" label to your Deployments.

What's next