Securing Communication in Multi-Agent Systems on Google Cloud

June 9, 2026 | By Semir Festikj

As organizations continue to adopt AI, agents have switched from isolated assistants to interconnected, distributed systems that orchestrate workflows, interact with services and collaborate with other agents.

This shift in AI implementation introduces new infrastructure challenges, including how private connectivity and service boundaries help regain control over agent communication.

The Rise of Multi-Agent Architectures

Teams across an organization can build agents on different platforms like Gemini Enterprise, Cloud Run or GKE (Google Kubernetes Engine). The most common approach is a multi-agent architecture.

At first, it seems that everything is under control. The agents call various sub-agents and connect to different GCP services like BigQuery or Cloud Storage. But as the agents evolve, the overall architecture becomes more complex. Users add new agents, requesting connection to different services that can span multiple projects, regions and environments. What started simple and small, with clear design, gradually becomes a complex network of dependencies that is harder to track.

Why Does Agent Communication Become a Problem in Multi-Agent Architectures?

The challenge quickly shifts from building agents to managing how agents connect across cloud services. For example, a primary agent may call multiple sub-agents that should be connected to cloud-native or third-party tools. Some of these agents may be managed by different teams or deployed in different environments or regions.

The questions that follow are about control rather than functionality:

• Which agents are allowed to communicate with each other?
• Which services can they access?
• Are these interactions happening through intended paths or through whatever route is available?

Identity alone does not fully answer these questions. An agent might have permission to access a service, but that doesn’t explain where the request originates or how it reaches the service. As systems grow, this lack of visibility can become a significant problem.

Defining Boundaries With VPC Service Controls

To address this, Google Cloud introduced a new security feature called VPC Service Controls. Instead of relying only on IAM, VPC Service Controls defines a boundary around managed services such as BigQuery, Cloud Storage and many more.

This boundary ensures that requests originate from trusted environments. Even if credentials are valid, access may be denied if the request comes from outside the defined perimeter. This feature reduces the risk of data being accessed or exfiltrated from unintended locations.

At this point, the system has a clear notion of trusted sources. Managed services are no longer universally reachable, and access is constrained by where requests originate.

Controlling the Path With Private Service Connect

While VPC Service Controls defines the boundary, it doesn’t define how requests reach services. An agent may still call a managed service through a public endpoint, and the communication path remains implicit.

This is where Private Service Connect changes the model. Instead of relying on public endpoints, services are exposed through private endpoints inside the VPC. Agents connect directly to these endpoints, making the communication path seamless within the architecture.

In this setup, a primary agent doesn’t call a sub-agent through a public URL. Instead, it connects to a defined endpoint that represents that service. The same applies to managed services. Access to BigQuery or Cloud Storage is no longer solely a matter of permissions but of how that access is routed.

This makes communication explicit. If a connection exists, it’s because it was intentionally created.

How Do VPC Service Controls and Private Service Connect Work Together?

In this architecture, the AI Agents run inside a consumer VPC and communicate with sub-agents and Google Cloud managed services through private endpoints. Cloud DNS keeps the communication inside the private network and resolves internal service names to Private Service Connect (PSC) endpoints.

On the producer side, the sub-agents are exposed through internal load balancers and published using PSC. This creates a clear separation between the agents consuming services and the services being exposed. This way, users can intentionally define and control every connection and avoid relying on public endpoints.

The same approach applies to managed services like BigQuery, Cloud Storage and AlloyDB.

VPC Service Controls add another layer of protection by enforcing service perimeters around managed services. With this, all requests are evaluated based on where they originate before access is allowed, even if an agent has valid permissions.

Together, PSC and VPC Service Controls help create a more controlled multi-agent environment. Communication paths are explicit, service exposure is intentional and access to managed services stays within trusted boundaries.

Building Clear Communication in Your Enterprise’s Multi-Agent System

As multi-agent systems grow, the number of connections between agents and services increases quickly. Defining boundaries with VPC Service Controls and controlling communication paths with Private Service Connect allows these systems to move from loosely connected components to more structured and controlled architectures. Instead of relying only on permissions, the system enforces where requests come from and how they are routed.

This shift makes agentic platforms simpler and more predictable as they scale. Understanding the capabilities and differences between the two is essential when designing multi-agent systems that rely on managed services and cross-agent interactions.