Manage agentic traffic with Agent Gateway

When you deploy autonomous AI agents on Google Kubernetes Engine (GKE), your workloads operate differently than standard microservices. AI agents determine their own execution paths and dynamically call external SaaS APIs, remote Model Context Protocol (MCP) servers, or other internal agents based on user prompts.

Because this behavior is non-deterministic, standard Layer 4 network firewalls cannot fully protect your AI environment. To secure agentic traffic, you must evaluate the identity of the calling agent, restrict exactly which tools it is allowed to use, and sanitize the semantic context of the prompt to prevent threats like prompt injection attacks.

If you are a platform administrator, security engineer, or AI developer, you can use Agent Gateway to secure and govern this agentic traffic. Agent Gateway acts as the central network entry and exit point for your GKE-hosted agents, connecting directly to the policy enforcement layer of the Gemini Enterprise Agent Platform.

Benefits of Agent Gateway for AI workloads

You can use Agent Gateway to achieve the following goals for your agentic applications:

  • Decouple security from agent code: AI developers do not need to build complex authentication, mutual TLS (mTLS), or payload sanitization logic into their agent frameworks. Agent Gateway handles network encryption and policy enforcement at the platform layer.
  • Implement sidecar-less enforcement: GKE ambient networking captures agent traffic outside your Pods, with no sidecars to inject and no changes to agent code. It also encrypts traffic between workloads with mTLS based on each Pod's identity, so you don't have to manage certificates yourself.
  • Enforce AI safety guardrails: sanitize incoming user prompts and outgoing tool responses in real time. Agent Gateway integrates directly with Google Cloud Model Armor to screen payloads for prompt injection attacks or harmful content before they reach your agent's reasoning engine.
  • Secure tool execution: verify that only authorized agents can access specific, high-privilege MCP servers or APIs. You can enforce granular, identity-based access controls for every tool call.
  • Monitor multi-agent systems: collect and view observability telemetry for all agent interactions, enabling you to trace multi-step agent reasoning across different tools and endpoints.

How Agent Gateway works on GKE

Depending on your traffic direction, you can use standard GKE networking resources to configure Agent Gateway to govern the following AI interaction flows:

  • Client-to-Agent (ingress): manage how external clients (such as chat interfaces or developer CLIs) interact with the agents hosted in your GKE cluster. You deploy a regional Application Load Balancer by using the GKE Gateway API. Then, you apply Kubernetes custom resources (GCPAgentGateway, GCPAuthzPolicy, and GCPExtensionBinding) to enforce identity-based access controls, restrict specific MCP tool calls, and screen incoming prompts with Model Armor before the request reaches the agent.
  • Agent-to-Anywhere (egress): route outbound requests securely from your GKE-hosted agents to external data stores, remote MCP servers, and APIs. You use the GKE ambient proxy to redirect this traffic to a Secure Web Proxy (SWP). SWP enforces your security policies, verifies the agent's identity with Identity-Aware Proxy (IAP), and inspects outbound payloads with Model Armor before the traffic leaves your network.
  • East-West (Intra-cluster): control how agents collaborate with peer agents, shared internal tools, or MCP servers within the same cluster. You deploy proxy-per-namespace Layer 7 ambient proxies to enforce mutual TLS (mTLS) and granular access policies without injecting sidecar proxies into your agent Pods. To request access to the Layer 7 ambient proxies preview, contact your Google Cloud account team.

Limitations and requirements

To govern GKE-hosted agents with Agent Gateway , your environment must meet the following baseline requirements:

  • Supported workloads: Agent Gateway supports agents deployed as standard GKE Pods. Agent Substrate on GKE and Agent Sandbox on GKE aren't supported.
  • GKE cluster version: your cluster must run GKE version 1.37.1-gke.1697000 or later.
  • 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 in GKE.
  • Agent Registry: you must register your agent Deployments so that Agent Registry can discover the workloads and sync their metadata. To register them, add the registry.gke.io/functional-type: "AGENT" label to your Deployments. For more information, see Use automatic registration.
  • GKE networking components:
    • For ingress governance, you must enable the GKE Gateway API in your cluster.
    • For egress governance, you must prepare your cluster for ambient networking and provision a Secure Web Proxy instance.

Agent Gateway for GKE is subject to single-project constraints, specific custom extension boundaries, and regional availability limits.

What's next