Private networking for agent systems: govern the path, not only the model

Google Cloud’s multi-agent networking pattern is designed for a publicly accessible Gemini Enterprise application with private connections between root agents, subagents and tools. Those agents may run on Agent Runtime, Cloud Run, GKE, on-premises infrastructure or other clouds.

The design routes A2A and MCP communications through customer-managed VPC paths so organisationally sensitive traffic does not need to traverse the public internet. The important principle is architectural: the public interaction surface and the private execution plane should be modelled separately.

The pattern recommends Shared VPC to centralise routing, subnets, DNS and firewall authority in a host project while agent runtimes live in attached service projects. Network and security administrators own the connectivity substrate; application teams can build agents without receiving permission to modify that substrate.

This is a useful separation of duties for agent systems because a new agent can expand capability quickly. Network reachability should not expand automatically with it.

The source uses Private Service Connect endpoints and interfaces, Cloud Run Direct VPC egress and private VPC routing to move traffic between managed runtimes, internal services and external environments. Different hosting platforms need different ingress and egress patterns.

That means “private networking” is not one switch. It is an end-to-end path that has to be verified for every source runtime, destination service and return route.

• Private Service Connect for defined producer/consumer paths
• Direct VPC or runtime-specific egress into governed networks
• Internal load balancing and private addresses for service reachability
• Hybrid and cross-cloud connectivity where required

Cloud NGFW governs traffic traversing the VPC and the source describes default-deny egress as a core policy direction. Secure Web Proxy can provide controlled internet egress when an agent genuinely needs external access.

Agents are particularly sensitive to egress design because model-directed tool use can produce unexpected destinations. Allow-lists, explicit proxy paths and logged firewall decisions create a narrower capability boundary than unrestricted outbound internet access.

VPC Service Controls can restrict access to supported Google-managed services and reduce data-exfiltration paths even when a workload has network connectivity. Identity-Aware Proxy, Cloud Armor, Model Armor and certificate services address other parts of the path.

The layers are complementary. Firewall policy controls traffic; IAM controls identity and permission; service perimeters constrain managed-service access; application and model protections inspect requests and responses. No single layer substitutes for the others.

Using standard agent protocols does not make the connection trusted by default. The source treats A2A and MCP connection security as explicit design work across GKE, Agent Runtime and Cloud Run source agents.

Protocol interoperability should therefore sit inside an authenticated and authorised transport path. The contract must identify who is calling, which service is allowed, what network path is permitted and how the interaction is observed.

Primary source: Google Cloud Architecture Center, “Multi-agent private networking patterns”. Canonical source: https://docs.cloud.google.com/architecture/multi-agent-private-networking-patterns . Source capture reviewed 7 August 2026.

This note is a platform-neutral editorial synthesis of the source’s Google Cloud design. Product names are retained where they define the source architecture; the broader conclusions concern separation of duties, private service paths, default-deny egress and layered controls.