Introduction — The rapid evolution of generative AI has driven an architectural shift from standalone prompt-and-response interfaces to autonomous, multi-agent AI systems. These modern AI agents do not operate in a vacuum; to complete complex business workflows, they must dynamically interact with database systems, invoke internal microservices, query external software-as-a-service (SaaS) APIs, and communicate with Model Context Protocol (MCP) servers. However, this autonomy introduces significant network security and compliance challenges. Non-deterministic agent behavior, risk of prompt injection attacks, and the potential for data exfiltration demand a robust, infrastructure-level security framework.
To address these challenges, Google Cloud introduced the Agent Gateway within the Gemini Enterprise Agent Platform. By embracing a shift down network security philosophy, the platform moves the complex burdens of identity management, mutual Transport Layer Security (mTLS) handshakes, policy enforcement, and payload auditing out of the individual agent application code and down into the shared cloud network infrastructure. This technical analysis provides an in-depth breakdown of the networking architecture, routing topologies, Private Service Connect (PSC) interfaces, and security mechanisms that govern this enterprise AI networking control tower.
Overview Agent Gateway — Agent Gateway is the networking component of the Gemini Enterprise Agent Platform ecosystem. It secures and governs connectivity for all agentic interactions, whether they occur between users and agents, agents and tools, or among agents themselves.
Agent Platform provides a full suite of capabilities for the complete agentic development lifecycle, to help agent developers and enterprises Build, Scale, Govern, and Optimize their agentic applications.
Agent Gateway is a key component of Agent Platform, acting as the network entry and exit point for all agent interactions. It gives enterprise security administrators the ability to enforce security and governance policies for agents as a part of the platform infrastructure.
To ensure holistic governance, Agent Gateway seamlessly integrates with core components of the Agent Platform ecosystem:
- Agent Registry: Serving as the authoritative repository for vetted tools and agents, including MCP servers, the registry provides the essential metadata used by the Gateway to apply fine-grained access policies.
- Agent Identity: Every agentive interaction is mapped to a unique, traceable persona. The Gateway utilizes these identities as the primary authorization principle, fortified by Context-Aware Access which mandates mTLS and DPoP for end-to-end cryptographic verification.
- Managed Agent Runtimes: Both the Agent Runtime and Gemini Enterprise environments are engineered to automatically funnel traffic through the Agent Gateway.
- Agent Platform Policies: The Gateway facilitates delegated authorization across IAM, Semantic Governance, and Model Armor, enabling the enforcement of sophisticated, multi-layered security frameworks.
- Agent Observability: By capturing network-level telemetry for every request, the Gateway feeds detailed data into Agent Observability to provide comprehensive visibility into autonomous behaviors.
Key Benefits
Agent Gateway provides a comprehensive suite of advantages for both developers and security administrators, effectively streamlining the complexities inherent in managing enterprise-grade AI interactions at scale.
For agent developers:
- Accelerated Innovation: By offloading the burden of security overhead and networking primitives, creators can concentrate exclusively on designing sophisticated agentic logic.
- Seamless Protocol Mediation: The platform supports diverse communication standards — including MCP, A2A, REST, and gRPC — while ensuring all traffic remains compliant with rigorous enterprise guardrails.
- Framework Interoperability: Security and governance capabilities are delivered as a native infrastructure service, independent of the specific client or development framework utilized.
- Automated Security Lifecycles: The Gateway automates mTLS handshakes and cryptographic verification, ensuring robust transport security. Furthermore, integration with the Agent Identity Auth Manager simplifies the orchestration of secure OAuth 2.0 flows between agents and their target tools.
Section 1: Foundational Network Architecture (VPCs and Subnets)
Implementing a secure, enterprise-grade agentic environment requires a highly structured Virtual Private Cloud (VPC) network topology. To support secure egress pathways, administrators must segregate traffic across several distinct subnet classes, each serving a unique role in routing and security boundary enforcement.
Technical Subnet Segmentation Analysis
Backend Subnets
Backend subnets form the core data storage and application layers of the enterprise VPC. These subnets are configured to reject any direct public internet ingress, allowing connections solely from designated security proxies or peered network endpoints.
Proxy-only Subnets
In Google Cloud, Layer 7 load balancers and security proxies require a reserved proxy-only subnet in the region where the services reside. This subnet is dynamically utilized by Google Cloud to allocate internal IP addresses to Envoy proxy nodes. This CIDR must be dedicated exclusively to active load balancing and cannot contain VM instances or database nodes.
PSC / Network Attachment Subnets
The Network Attachment subnet is the precise landing point where the customer VPC connects to the Google-managed tenant environment. Although the network attachment supports standard private ranges, it must not reside within the 10.0.0.0/24, 10.0.1.0/24, or 10.0.2.0/24 CIDR blocks.
This restriction is a critical constraint of the internal Google-managed tenant proxy architecture. Because the tenant project reserves these specific blocks for internal packet encapsulation and infrastructure transport, placing a customer-side network attachment within these same blocks would result in overlapping address ranges, causing severe routing collisions and connection failures.
Cloud Run Subnets
To support streamable, serverless MCP servers hosted on Cloud Run, a dedicated subnet is deployed with Direct VPC egress enabled. This setup bypasses the need for legacy Serverless VPC Access connectors, allowing serverless runtimes to scale to zero while maintaining high-performance, low-latency private connectivity.
Section 2: Component 1 — Agent Registry Networking
The Agent Registry serves as the centralized catalog and authoritative directory for the entire enterprise AI ecosystem. It maintains a strict inventory of all approved agents, custom API tools, and third-party MCP servers.
From a networking perspective, the Agent Registry functions as the control plane that defines endpoint resolution paths and dynamic metadata lookups:
- Endpoint Path Resolution: AI agents do not target raw, static IP addresses. Instead, they invoke tools registered within the catalog. The Agent Registry resolves these tool calls to target REST URLs, gRPC endpoints, or remote MCP server locations.
- Dynamic Metadata Ingestion: During tool invocation, the Agent Registry provides structured metadata directly to the Agent Gateway. This payload exposes specific annotations such as whether a tool is read-only (isReadOnly) or potentially destructive (isDestructive).
- Policy Enforcement Boundaries: The Agent Gateway uses these catalogued attributes to apply granular access controls. By default, the gateway blocks traffic to any remote tool or server that is not registered, establishing a default-deny boundary at the edge of the enterprise platform.
Section 3: Component 2 — Enterprise Agent Platform Isolation
To prevent lateral movement, potential data exfiltration, or runtime execution compromise, the Gemini Enterprise Agent Platform enforces strict isolation boundaries around the execution space.
Tenant Network Segregation
All agent runtime engines execute inside an isolated, Google-managed tenant VPC network. This tenant space is physically and logically distinct from the customer’s corporate VPC network.
Zero Default Entitlements
There is no default peering or direct routing pathway established between the Google-managed tenant VPC and the customer VPC. On startup, an agent has zero visibility into any private resources or database systems hosted within the customer network.
Section 4: Component 3 — Gateway Deployment & Traffic Routing
The Agent Gateway sits at the intersection of the isolated tenant space and the customer VPC, serving as the central control tower for both inbound (ingress) and outbound (egress) AI traffic.
Egress Routing Topologies
When functioning in Agent-to-Anywhere (egress) mode, the gateway evaluates agent requests against fine-grained security policies before deciding where to forward the payload. This setup establishes private data plane connectivity to:
- Private Networks (VPC): Outbound routing targeting internal databases or private microservices via the PSC network attachment.
- External Networks (Internet): Traffic targeting public SaaS APIs, routed through centralized Secure Web Proxies.
- Google API Services: Outbound paths to Vertex AI foundation models, managed BigQuery instances, or governance systems.
Architectural Reality of Deployment Modes
Organizations can adopt one of two primary architectural configurations:
- Google-Managed Mode: Google deploys and manages the regional Envoy proxy instances inside an isolated tenant project. The customer interacts with this infrastructure declaratively by configuring network connections to a PSC endpoint mapped to their local subnet.
- Self-Managed Mode: Platform engineering teams bind the declarative gateway configuration schema directly to their existing regional load balancing infrastructure, utilizing pre-configured Secure Web Proxies (SWP) or Internal Application Load Balancers (L7-ILB).
Section 5: Bridging the Gap (The PSC Deep Dive)
The foundational plumbing that allows the isolated Google-managed tenant to privately communicate with resources inside the customer VPC relies on Private Service Connect (PSC) interfaces.
1. The PSC Interface
The PSC Interface is a dynamic outbound network interface card (NIC) provisioned automatically inside the secure Google-managed tenant project by the Agent Runtime workflow. Instead of acting as a static destination IP mapping, this interface operates as an outbound transit adapter projecting packets into a designated customer subnet.
2. The Network Attachment
The Network Attachment is an administrative resource explicitly created by the customer’s network administrator within their local VPC. The tenant-side PSC Interface connects directly into this attachment.
By creating this attachment, the customer admin establishes a strict private landing zone, maintaining full administrative control over which Google projects are authorized to initiate connection handshakes.
DNS Peering and Split-Horizon DNS Interception
A physical connection via a PSC interface only solves the routing layer; the agent must also be able to resolve private target hostnames. Because the tenant network has no native access to the customer’s private DNS zones, administrators must configure Cloud DNS Peering.
By mapping private domains (e.g., abc.com.) in the DNS peering configuration, name resolution queries are routed directly into the customer VPC’s private Cloud DNS zone.
For advanced egress scenarios, organizations can leverage DNS interception to route external calls through security proxies:
- Override Public Resolution: Create a private Cloud DNS managed zone inside the customer VPC for the target external domain (such as api.github.com or *.abc.com).
- Point to PSC Endpoint: Within that zone, configure a wildcard DNS A record pointing the hostnames to a reserved global internal IP address (e.g., 240.0.0.10) representing a global PSC Endpoint for Google APIs.
- Transparent Interception: When the agent runtime attempts an outbound call, Cloud DNS intercepts the request and returns the PSC endpoint IP, forcing traffic through the private network path.
Section 6: Advanced Egress — Secure Web Proxy (SWP) Integration
When AI agents must reach resources outside private networks — such as public SaaS APIs or remote web hooks — routing the traffic directly over the open internet introduces data exfiltration vulnerabilities. Organizations mitigate these risks by integrating Secure Web Proxy (SWP) into the egress pipeline.
SWP operates as a fully managed, auto-scaling egress proxy framework situated within the regional proxy-only subnet. It provides a Layer 7 policy engine that inspects outbound traffic, matches HTTP/S request headers, and enforces transparent host-level allow-lists.
- Agent-Level Authorization (Agent Gateway): The gateway intercepts outbound calls and verifies the agent’s SPIFFE identity. The Identity-Aware Proxy (IAP) extension evaluates whether the agent’s cryptographic profile is permitted to access the target resource listed in the registry.
- URL-Level Validation (Secure Web Proxy): Once authorized by the gateway, the traffic passes over the PSC interface to SWP. SWP evaluates the request against domain policies, ensuring that the target URL matches allowed hosts (e.g., *.github.com or *.googleapis.com) and logging the transaction for audit compliance.
Configuration Steps
Step-1 Create a global VPC network.
# create vpc network
gcloud compute networks create vnet-${test} - subnet-mode=custom
Step-2 Create subnets for the Agent Gateway PSC network attachment
# create subnet for agent gateway psc na
gcloud compute networks subnets create subnet-${REGION}-agw \
- network=vnet-${test} \
- range=192.168.10.0/28 \
- region=${REGION} \
- enable-private-ip-google-access
Step-3 Create psc network attachment
gcloud compute network-attachments create psc-na-${REGION}-agw \
- region=${REGION} \
- subnets=subnet-${REGION}-agw \
- connection-preference=ACCEPT_AUTOMATIC
Step-4 Fetch psc na uri
export PSC_NA_URI=$(gcloud compute network-attachments describe psc-na-${REGION}-agw \
- region=${REGION} \
- format="value(selfLink.scope(v1))")
echo ${PSC_NA_URI}
Step-5 Set env var for psc ep ip address
export PSC_EP_IP="240.0.0.10"
echo ${PSC_EP_IP}
Step-6 Reserve internal global ipv4 address
gcloud compute addresses create ip-psc2gapis \
- global \
- purpose=PRIVATE_SERVICE_CONNECT \
- addresses=${PSC_EP_IP} \
- network=vnet-${test}
Step-7 Create psc endpoint for google apis
gcloud compute forwarding-rules create psc2gapis \
- global \
- network=vnet-${test} \
- address=ip-psc2gapis \
- target-google-apis-bundle=all-apis
Step-8 Create DNS zone and records
Create a private Cloud DNS managed zone for the abc.com domain.
# create private dns zone
gcloud dns managed-zones create priv-zone-run \
- description="private zone for cloud run" \
- dns-name="abc.com." \
- visibility=private \
- networks=vnet-${test}
Create a wildcard DNS A record for *.abc.com. pointing to the IP address of the PSC endpoint.
# create dns record
gcloud dns record-sets create *.abc.com \
- zone=priv-zone-run \
- type=A \
- ttl=300 \
- rrdatas=${PSC_EP_IP}
Step-9 Creating Agent Gateway using YAML
# create new agent gateway config YAML file (with network settings)
cat > cfg/${AGW_NAME}-networkConfig.yaml << EOF
name: ${AGW_NAME}
protocols:
- MCP
googleManaged:
governedAccessPath: AGENT_TO_ANYWHERE
registries:
- "//agentregistry.googleapis.com/projects/${PROJ_ID}/locations/${REGION}"
networkConfig:
egress:
networkAttachment: ${PSC_NA_URI}
dnsPeeringConfig:
domains:
- abc.com.
targetProject: ${PROJ_ID}
targetNetwork: projects/${PROJ_ID}/global/networks/vnet-${test}
EOF
Step 10 Import agent gateway config file (create gateway)
gcloud network-services agent-gateways import ${AGW_NAME} \
- source="cfg/${AGW_NAME}-networkConfig.yaml" \
- location=${REGION}
Conclusion
The transition toward autonomous, multi-agent AI architectures requires a parallel shift in network security strategies. The Google Agent Gateway meets this requirement by shifting complex L7 verification down to the network infrastructure. By pairing Private Service Connect interfaces with administrative Network Attachments, organizations can safely bridge the gap between isolated tenant execution spaces and private customer VPC networks.
When combined with split-horizon private name resolution, payload sanitization via Model Armor, and egress domain checking via Secure Web Proxy, the Agent Gateway establishes a zero-trust perimeter. This layered approach guarantees that every agent-to-tool, client-to-agent, and agent-to-anywhere interaction remains private, secure, and fully audited, allowing enterprises to scale their generative AI workloads with confidence.
Disclaimer: This is to inform readers that the views, thoughts, and opinions expressed in the text belong solely to the author, and not necessarily to the author’s employer, organization, committee or other group or individual.
Google Agent Gateway Networking was originally published in Google Cloud – Community on Medium, where people are continuing the conversation by highlighting and responding to this story.
Source Credit: https://medium.com/google-cloud/google-agent-gateway-networking-5417ce96f1be?source=rss—-e52cf94d98af—4
About the Author
