Google Cloud’s release notes carry an entry dated October 27, 2026: VPC connectivity and static IP egress for custom MCP servers is generally available as a Gemini Enterprise feature. The GA covers a specific set of networking capabilities, currently supported in the us-central1 and europe-west1 regions. It is not a blanket announcement about the status of the broader Agent Gateway service. What it changes is where enterprise control over agent behavior can be exercised.
The core of the update is Agent Gateway connectivity templates. A connectivity template defines and manages the egress networking settings for a gateway, and deploying an Agent Gateway with one routes outbound agent tool traffic into a designated customer VPC through a Private Service Connect interface. Once agent traffic is inside the VPC, teams can apply the network controls they already run for other workloads: custom DNS resolution, validation of private certificates, and firewall policy on traffic arriving from the gateway.
The template’s vpcEgress setting offers two modes. PRIVATE_RANGES_ONLY routes only traffic destined for private IP address ranges into the VPC, while internet-bound traffic exits directly through the gateway. ALL_TRAFFIC routes all outbound traffic from your agents through the VPC network, including calls to the public internet and external SaaS APIs. That second mode is the consequential one: VPC Service Controls service perimeters require it, and it is also the mode that moves responsibility onto the customer. Google’s documentation is direct about the trade: because all outbound traffic now routes into your VPC, you manage its routing and security, including the default route that forwards that traffic to your own gateways or security appliances.
Egress is becoming the primary agent control point. As agents take on more work against external tools and data stores, the network layer is where enterprise control is settling, in network form. In ALL_TRAFFIC mode, traffic exits to the public internet through a Cloud NAT gateway on the Private Service Connect subnet, and assigning static external IP addresses to that gateway gives agent traffic a fixed network identity. Remote MCP servers and third-party firewalls can then enforce strict IP allowlists against that identity. The Cloud NAT documentation adds a practical wrinkle: teams that need to know their addresses ahead of time to build an allowlist must use manual NAT IP address assignment, because automatic allocation cannot predict the next address.
Control of this kind carries friction. The network attachment is immutable once configured on both the connectivity template and the gateway, and in-place template updates are unsupported; changing a template means creating a new one and repointing the gateway. Gateways created without a connectivity template cannot be upgraded in place either: Google’s docs say they must be deleted and recreated. For teams with running deployments, the GA arrives as much as a migration notice as a feature release.
These tools let enterprises treat agent traffic as standard network traffic, subject to the same oversight as any other workload. By anchoring agent egress inside the customer’s VPC, Google Cloud hands infrastructure teams the rails for enforcing policy at the network edge, and makes the egress point the place where agent governance actually happens. The scope of that claim stays deliberately narrow: VPC connectivity and static IP egress for custom MCP servers, in two regions, with routing and security responsibilities firmly back on the customer.