Vertex AI Agent Engine Networking Overview

Google Cloud Build with AI Agents
, , ,
1

This document outlines the primary networking models for Agent Engine.

TL;DR

Standard Deployment VPC-SC Deployment PSC-I Deployment
Public Internet Access :white_check_mark: Default :cross_mark: Blocked ↔️ Optional (via proxy)
Private Resource Access :cross_mark: No :cross_mark: No (by default) :white_check_mark: Yes
Primary Use Case Agents using public APIs/DBs High-security environments Agents accessing private services in a VPC/on-prem

1. Standard Deployment

This is the most common and straightforward deployment with no special configuration. In this configuration, the Agent Engine resources are deployed within a Google-managed tenant project and have egress connectivity to the public internet by default. The deployed agent can also connect to databases that have public IPs. In this standard deployment mode, the agent doesn’t have access to private services or private databases. To access private resources, users should configure PSC-I (section 3 below).

Sample notebooks:

2. Secure Deployment: VPC Service Controls (VPC-SC)

Agent Engine supports VPC-SC. To use Agent Engine in a VPC-SC environment, users should follow Vertex AI VPC-SC documentation to create a service perimeter and include the project where they want to deploy agents to Agent Engine.

In this configuration, Agent Engine resources are deployed within a Google-managed tenant VPC. All public internet egress is blocked to ensure no data exfiltration. Any attempt by the agent to access a service outside the perimeter will also be blocked. Likewise, external services cannot access resources inside the perimeter unless explicitly allowed by the perimeter’s configuration. When deploying with VPC-SC, agents can only access Google APIs and services through Private Google Access (PGA).

To allow agents to access private resources or public internet, users should use PSC-I (section 3 below) with VPC-SC together.

3. Private Connectivity: Private Service Connect - Interface (PSC-I) + DNS Peering

Agent Engine supports PSC-I and DNS Peering. Customers should deploy Agent Engine with PSC-I and DNS Peering when customers need to connect Agent Engine to resources hosted in their own VPC or on-premises network. It’s recommended to always use DNS Peering with PSC-I so that agent code can make requests to service domain names directly rather than calling specific IPs. Without DNS peering, the agent’s code must be modified to explicitly include the proxy IP(s) in get() requests when accessing tools in the customer’s VPC or on the Internet.

In this configuration, Agent Engine resources are deployed within a Google-managed tenant VPC. Customers should follow the public document to set up network attachment and DNS zones then set the PSC-I config when deploying to Agent Engine.

Screenshot 2025-09-24 at 2.17.21 PM
Screenshot 2025-09-24 at 2.17.21 PM996×620 117 KB

This diagram illustrates how Agent Engine uses Private Service Connect (PSC) to securely access resources in customer VPC and optionally connect to the public internet.
Private Resource Access Flow
This is the path traffic takes when the Agent Engine connects to a private resource, like the VM at rfc1918-vm.demo.com in the diagram:

  1. Agent to PSC Interface: Traffic from Agent Engine intended for a private service is routed to the PSC Interface (eth1) within the Google-managed tenant project.
  2. Thanks to DNS Peering, the agent can use the domain name (e.g., rfc1918-vm.demo.com) instead of a hardcoded IP address.
  3. PSC to customer VPC: Private Service Connect securely forwards the traffic from the tenant project to the psc-network-attachment in customer project’s VPC.
  4. VPC to Proxy: The traffic is then routed within customer VPC to the proxy-vm.

Public Internet Access Flow
This is the path traffic takes when the Agent Engine needs to reach a public API:

  1. Agent to Proxy: Similar to the private flow, traffic destined for the internet is first sent through the PSC connection to the proxy-vm in customer VPC.
  2. Proxy to Internet: The proxy VM then sends the traffic out towards the internet. It uses Cloud NAT to get a public IP address, and the traffic is subject to customer project’s Cloud Firewall Rules before exiting to the internet.

Agent Engine PSC-I Codelab: https://codelabs.developers.google.com/agent-engine-psc-interface-private

FAQ

Q: Which networking model should I choose?
A: Use the Standard Deployment for simplicity when the agent only needs to access public APIs and databases. Choose VPC-SC when the customer is operating in a high-security environment and need to prevent data exfiltration. Use PSC-I when the agent must connect to private resources (databases, microservices) in customer VPC or on-premise network. PSC-I can also be combined with VPC-SC.

Q: With PSC-I, is the proxy VM in my project required to give my agent public internet access?
A: Yes. In a PSC-I configuration, the Agent Engine has no direct path to the internet. To provide internet access, you must route its traffic through a resource in your VPC, such as a proxy VM, which can then egress to the internet using a tool like Cloud NAT.

Q: How does the agent connect to my on-premise network?
A: You can connect Agent Engine to your on-premise network by using PSC-I. First, establish a connection between your on-premise network and your Google Cloud VPC using Cloud VPN or Interconnect. Then, configure PSC-I to link Agent Engine to that VPC, giving it a path to your on-premise resources.

Q: Where to place the PSC network attachment in a common Shared VPC setup?
A: Consider the following three-project scenario:

  • A VPC Host Project: This project owns the Shared VPC network.
  • A Private GKE Service Project: A service project attached to the Shared VPC, which hosts a private GKE service that your agent needs to access.
  • A Vertex AI Project: A service project, also attached to the Shared VPC, where you are deploying Agent Engine.

Recommendation:

  • In this scenario, you should create the PSC network attachment in the Vertex AI Project.

Reasoning:

  • While the attachment can technically be created in any project connected to the Shared VPC, placing it in the Agent Engine project simplifies permissions. The Agent Engine service uses Vertex AI P4SA to patch the network attachment. Creating the attachment in the Vertex AI project make it easier to manage the configuration of this service account.

Q: What permissions do I need to grant to use PSC-I?
A: Vertex AI needs the compute.networkAttachments.get and compute.networkAttachments.update permissions to update the customer’s network attachment’s allowlist to accept traffic from Google’s internal project. These permissions are available in the Compute Network Admin (roles/compute.networkAdmin) role. So if the network attachment is created in Project A, then you need to grant roles/compute.networkAdmin role to the Vertex AI Service Agent of Project A. If you don’t want to grant the Compute Network Admin role, you can create a custom role that has those permissions and grant it to the Vertex AI SA.

Q: What permissions do I need to grant to use DNS Peering?
A: Your service project’s Vertex AI SA needs to have the DNS Peer (roles/dns.peer) role in the project where you created the DNS record. If you create the DNS record in Project A and use Agent Engine in Project B, then Project B’s Vertex AI SA needs to have the DNS Peer(roles/dns.peer) role in Project A. Project A and Project B can be the same project.

Q: Is there any requirement on the IP range I can use?
A: Vertex can’t reach these IPs: https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/private-service-connect-interface#subnetwork-ip-range-requirements.

Q: Regarding the configuration of psc_interface_config, an optional field named dns_peering_configs is present. If this domain is not specified, will Vertex automatically select the first available DNS zone?
A: No, explicit configuration of the DNS peering is required by the client for Vertex to successfully resolve the DNS zone. Please refer to the documentation at https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/private-service-connect-interface#dns-peering for instructions on establishing DNS peering and assigning the necessary roles.

What’s next

See Vertex AI Agent Engine public document here:

15 Likes
2

Thx Changsong, that is extremely helpful insight!

2 Likes
3

Thanks for sharing.

4

Thank you @changsong

5

hi @changsong, Is there any example of a PSC interface setup? I’m having trouble setting up the PSC interface, especially the DNS peering part, thank you

6

The codelab above should be helpful. You can also see Agent Engine’s public document and linked Vertex AI PSC-I documents here: Using Private Service Connect interface with Vertex AI Agent Engine  |  Vertex AI Agent Builder  |  Google Cloud Documentation. Be sure to check out the FAQ section above and the questions around DNS Peering permission setup.

7

We are having hard time to figure out why we can’t establish the connection using PSC-I so we can make some api calls to our internal services in shared vpc. Is there a better way to debug this?

We see below error by the way.

I am unable to connect to the provided URL. The domain name could not be resolved, which suggests the server might be unavailable or the URL is incorrect.

8

When using PSC network attachment, and at the same time I want to egress traffic to public endpoint platforms like Datadog, how can I do both simultaneously? When I try to use the network attachment, it doesn’t allow me to egress traffic from the Vertex AI Agent engine; I’m getting a ‘network is unreachable’ error. How to resolve this error?

9

Thanks for sharing the insights. I also want to add that when designing a secure or hybrid networking setup, review these options early, as the choice impacts permissions, connectivity, and operational complexity. For production deployments, it’s good to validate the design in a non-prod environment if possible.