Private Network Architecture for Gemini Enterprise

Executive summary: Enterprises adopting Gemini Enterprise, Vertex AI, and AI agents face a networking problem that looks like every other enterprise workload at first glance and isn’t. AI services multiply east-west traffic (agent-to-agent, agent-to-tool, agent-to-data), concentrate high-value data behind a small number of APIs, and are frequently rolled out faster than the network and security review cycles built for traditional application launches. This piece lays out a private-by-default architecture — Shared VPC landing zone, Private Service Connect, VPC Service Controls, Network Connectivity Center, and hybrid connectivity — for keeping every one of those paths off the public internet, grounded throughout in Google’s own published architecture guidance.

Table of contents

1. Introduction
2. Google AI services overview
3. Enterprise network architecture: the landing zone
4. Private connectivity
5. Network Connectivity Center
6. Hybrid connectivity
7. AI access patterns
8. Secure API access
9. AI agent networking
10. Enterprise data connectivity
11. Security architecture
12. Logging and monitoring
13. High availability and disaster recovery
14. Deployment models
15. Reference architectures
16. Common mistakes
17. Best practices checklist
18. Next steps
19. Frequently asked questions
20. References

Introduction

Enterprise AI adoption has outrun the network and security review processes most organizations built for conventional application rollouts. A line-of-business team stands up a Gemini Enterprise agent against internal data in weeks, not quarters — and the network architecture underneath it is often whatever was fastest to get a demo working, not what a CISO would sign off on for production access to core systems.

That gap matters more for AI than it did for the last generation of enterprise applications, for three concrete reasons:

• AI concentrates access. A single agent or RAG pipeline often needs read access across several systems of record — CRM, ERP, document stores, ticketing — that previously had no reason to share a network path. That consolidation is exactly the kind of blast-radius expansion Zero Trust architecture is designed to contain.
• AI generates east-west traffic by default. Agent-to-agent calls, agent-to-tool (MCP) calls, and retrieval calls to vector stores and data warehouses are all internal, service-to-service traffic — the traffic pattern classic perimeter firewalls were never designed to inspect, because it never crosses the perimeter at all.
• The cost of a public-facing mistake is now a data exfiltration incident, not a defaced webpage. An AI agent with broad data access and an accidentally public endpoint is a materially different risk than a marketing microsite with the same mistake.

The architectural answer Google Cloud provides is not exotic — it’s the same Zero Trust and defense-in-depth thinking behind BeyondCorp and the enterprise foundations blueprint, applied specifically to Gemini Enterprise, Vertex AI, and the agent platforms built on top of them. The rest of this piece works through that architecture layer by layer: the landing zone, private connectivity, hybrid networking, AI-specific access patterns, and the security and observability controls that tie it together — with the goal that every request into an AI service, from an employee’s laptop or from one agent to another, travels over a private, authenticated, logged path and never touches the public internet.

Google AI services overview

Before designing the network, it’s worth being precise about what’s actually being connected, since these products have different networking primitives and different levels of VPC Service Controls support.

• Gemini Enterprise is Google’s enterprise AI assistant and agent platform — search, conversational AI, and now a broader Gemini Enterprise Agent Platform for building and running agents against enterprise data and connectors (Workspace, third-party SaaS, and custom sources). It supports private UI access via PSC endpoints and can be placed inside a VPC Service Controls perimeter.
• Vertex AI is the underlying ML/AI platform — model training, model serving (including Gemini model access), and the Vertex AI Agent Builder and Agent Engine for building and hosting custom agents. Vertex AI has mature VPC Service Controls support and, for Agent Engine specifically, PSC interface support for reaching private resources.
• Vertex AI Search provides the retrieval layer for RAG patterns — indexing enterprise content and serving semantic search results that an agent or Gemini Enterprise app grounds its answers in.
• Agent Builder / Agent Designer is the no-code/low-code layer for assembling agents, tools, and data-store connections, including connections to MCP (Model Context Protocol) servers — an open, model-agnostic protocol (not a Google-proprietary one) for exposing tools and data sources to an LLM-based agent in a standard way. Google Cloud has published native MCP support in Agent Builder and in Agent Engine deployments, which is why MCP shows up later in this piece as a distinct east-west traffic pattern to design for, not just an implementation detail.

The architectural throughline across all of these: each one is a Google-managed, multi-tenant control plane by default, reached over the public Google API surface unless you deliberately configure private access — which is precisely the default this piece designs against.

flowchart TB
    subgraph GoogleManaged["Google-managed control plane"]
        GE[Gemini Enterprise]
        VAIS[Vertex AI Search]
        AB[Agent Builder / Agent Designer]
        AE[Vertex AI Agent Engine]
        VAI[Vertex AI Model Serving]
    end
    AB -->|configures| GE
    AB -->|configures| AE
    GE -->|retrieval| VAIS
    AE -->|model calls| VAI
    AE -->|tool calls| MCP[MCP Servers]
    GE -->|model calls| VAI

Enterprise network architecture: the landing zone

Everything downstream — private connectivity, VPC Service Controls, agent networking — assumes a landing zone that already separates environments and centralizes network administration. This is the same enterprise foundations blueprint pattern Google publishes for any large workload, not an AI-specific structure, and that consistency is deliberate: your AI platform team shouldn’t need a parallel network model.

Organization hierarchy. Resources roll up through an Organization → Folders → Projects hierarchy. A typical structure separates folders by environment (prod, nonprod, sandbox) and sometimes by business unit, with IAM and Organization Policy constraints inherited down the hierarchy — the reason Organization Policy constraints are set at the folder level for things like “no public IPs” rather than repeated per project.

Shared VPC. A Shared VPC designates one host project that owns the VPC networks, subnets, routes, and firewall policies, while one or more service projects attach to it and run workloads — Vertex AI resources, GKE clusters, Cloud Run services — using the host project’s network. This is what lets a central network/security team own IP addressing, firewall policy, and Private Google Access configuration once, while application and data science teams retain project-level IAM control over their own resources. It’s also the reason PSC endpoints and NCC spokes are typically attached at the host project level: the network topology is centralized there by design.

Environment separation. Production, non-production, and sandbox environments should sit in separate projects (or separate service projects sharing separate host-project VPCs) with distinct firewall policies and, often, distinct VPC Service Controls perimeters. Sandbox environments — where a data science team is experimenting with a new agent framework or an unreleased MCP server — are exactly where a policy gap gets discovered by an attacker rather than a reviewer, so treat “sandbox” as a real trust boundary, not an exemption from one.

flowchart TB
    ORG[Organization]
    ORG --> F_PROD[Folder: Production]
    ORG --> F_NONPROD[Folder: Non-Production]
    ORG --> F_SANDBOX[Folder: Sandbox]

    F_PROD --> HOST_PROD[Host Project: prod-shared-vpc]
    F_PROD --> SVC_AI[Service Project: ai-platform-prod]
    F_PROD --> SVC_DATA[Service Project: data-prod]

    F_NONPROD --> HOST_NONPROD[Host Project: nonprod-shared-vpc]
    F_NONPROD --> SVC_AI_DEV[Service Project: ai-platform-dev]

    F_SANDBOX --> HOST_SANDBOX[Host Project: sandbox-shared-vpc]

    SVC_AI -.->|attached to| HOST_PROD
    SVC_DATA -.->|attached to| HOST_PROD
    SVC_AI_DEV -.->|attached to| HOST_NONPROD

    HOST_PROD --> VPCSC_PROD[VPC-SC Perimeter: Production]
    HOST_NONPROD --> VPCSC_NONPROD[VPC-SC Perimeter: Non-Production]

Private connectivity

This is the mechanism layer that makes “no public internet exposure” an actual network property rather than a policy statement.

Private Google Access lets VM instances or GKE nodes with only internal IP addresses reach Google APIs and services (including Vertex AI and Gemini Enterprise’s control-plane APIs) without a public IP or NAT gateway. It’s a subnet-level setting, and it’s the baseline every other control in this section builds on — see Configure Private Google Access.

Restricted vs. private VIP. Once Private Google Access is on, you choose which virtual IP range API traffic resolves to. restricted.googleapis.com (199.36.153.4–7) routes only to APIs that support VPC Service Controls, which is the recommended default for anything handling sensitive data — it means a misconfigured perimeter can’t accidentally be bypassed by an API outside its protection. private.googleapis.com (199.36.153.8–11) reaches the full Google API surface, including APIs that don’t support VPC-SC, which is sometimes necessary but reintroduces the exfiltration surface VPC-SC exists to close. See Private access options for services for the full comparison.

DNS matters here more than it looks. Neither restricted nor private VIP has a usable public DNS record — you must create a private Cloud DNS zone with a response policy that rewrites *.googleapis.com (and, for Gemini Enterprise/Vertex AI specifically, their service-specific domains) to the chosen VIP. Get this wrong and traffic silently falls back to the public API endpoint over the internet instead of failing loudly, which is a worse outcome than an obvious error — see Configure Private Google Access for on-premises hosts for the on-premises DNS forwarding version of this same problem.

Private Service Connect (PSC) is the layer above Private Google Access, and it comes in two directionally opposite forms that are easy to mix up:

• PSC endpoints let your VPC (the consumer) initiate a connection to a producer service — Google APIs, or a published service like Gemini Enterprise’s private UI access — by creating an internal IP address in your VPC that forwards to that service. This is consumer-initiated, and it’s how employees reach Gemini Enterprise privately: see Configure private UI access for Gemini Enterprise.
• PSC interfaces are bidirectional: a producer (for example, a Vertex AI Agent Engine deployment running in Google’s own tenant project) creates an interface that connects into a network attachment in your VPC, letting the producer’s workload initiate outbound connections into your network — to reach an internal database, for instance. See About Private Service Connect interfaces and, specifically for agents, Using a PSC interface with Vertex AI Agent Engine.

The rule of thumb: endpoints solve “how do my users/workloads reach a Google-managed AI service privately,” interfaces solve “how does a Google-managed AI agent reach my private data privately” — and a full architecture typically needs both, in opposite directions, simultaneously.

flowchart LR
    subgraph Corp["Corporate VPC (Consumer)"]
        User[Employee Workstation]
        PSCEndpoint[PSC Endpoint<br/>internal IP]
        Subnet[Subnet: Private Google Access ON]
    end
    subgraph GoogleTenant["Google-managed tenant project"]
        AgentEngine[Vertex AI Agent Engine]
        PSCInterface[PSC Interface]
    end
    subgraph GoogleAPIs["Google API surface"]
        Restricted[restricted.googleapis.com<br/>VPC-SC supported APIs]
        GeminiEnt[Gemini Enterprise]
    end

    User -->|HTTPS, internal IP| PSCEndpoint
    PSCEndpoint --> GeminiEnt
    Subnet -->|Private Google Access| Restricted

    AgentEngine --> PSCInterface
    PSCInterface -->|producer-initiated| NetworkAttachment[Network Attachment]
    NetworkAttachment --> PrivateDB[(Private Cloud SQL / on-prem DB)]

Network Connectivity Center

Network Connectivity Center (NCC) is Google Cloud’s hub-and-spoke orchestration layer: a global hub resource that spokes — VPC networks, VLAN attachments (Interconnect), VPN tunnels, or router appliances — attach to, giving every spoke transitive reachability to every other spoke through the hub without a full mesh of manual peerings.

When NCC earns its complexity. A single VPC with one or two hybrid connections doesn’t need NCC — a Cloud Router managing BGP sessions directly is simpler and sufficient. NCC becomes the right tool once you have multiple VPCs (say, separate Shared VPCs per business unit or environment) or multiple on-premises sites that all need mutual reachability with each other and with Google Cloud. The alternative — a mesh of VPC Network Peering connections — is non-transitive (A peered to B and B peered to C does not give A reachability to C) and becomes an operational and peering-quota burden past a handful of networks. NCC’s VPC spokes solve exactly this by exporting and importing routes through one hub.

For an AI platform specifically, NCC is what lets a central “AI platform” Shared VPC (hosting Vertex AI PSC endpoints, Gemini Enterprise private access, and MCP server infrastructure) be reachable from every business-unit VPC and every branch office through one consistent hub, instead of each business unit standing up its own private connectivity to the same set of AI services.

flowchart TB
    HUB((NCC Hub))

    HUB --- SPOKE_AI[VPC Spoke:<br/>AI Platform Shared VPC]
    HUB --- SPOKE_BU1[VPC Spoke:<br/>Business Unit 1 VPC]
    HUB --- SPOKE_BU2[VPC Spoke:<br/>Business Unit 2 VPC]
    HUB --- SPOKE_INTERCONNECT[Hybrid Spoke:<br/>Dedicated Interconnect VLAN Attachment]
    HUB --- SPOKE_VPN[Hybrid Spoke:<br/>HA VPN Tunnel - Branch Office]

    SPOKE_INTERCONNECT --- ONPREM[On-Premises Data Center]
    SPOKE_VPN --- BRANCH[Branch Office]

    SPOKE_AI -.transitive via hub.-> SPOKE_BU1
    SPOKE_AI -.transitive via hub.-> ONPREM
    SPOKE_BU2 -.transitive via hub.-> BRANCH

Hybrid connectivity

Reaching on-premises identity providers, data sources, and users means choosing among Dedicated Interconnect, Partner Interconnect, and Cloud VPN / HA VPN — each a different point on the latency/bandwidth/cost curve, all managed dynamically via Cloud Router and BGP rather than static routes.

High availability is a topology choice, not a checkbox. HA VPN topologies publish a 99.99% SLA only with two interfaces on each side across two tunnels; a single-tunnel VPN has no such guarantee. For Interconnect, redundancy means two VLAN attachments across two different edge availability domains at minimum, and — for organizations that can’t tolerate a metro-level fiber cut — a second Interconnect connection in a physically separate metro. HA VPN over Cloud Interconnect is the pattern for combining Interconnect’s bandwidth and latency with IPsec encryption, which matters for enterprises whose compliance posture requires encryption in transit even over a private circuit.

BGP is what makes failover automatic. Cloud Router’s dynamic route exchange means a failed path is withdrawn and traffic shifts to a healthy path without manual intervention — which is the entire point of a hybrid architecture supporting a production AI workload with an SLA. A static-route hybrid setup effectively has no automated failover.

flowchart TB
    subgraph OnPrem["On-Premises Data Center"]
        OR1[On-prem Router 1]
        OR2[On-prem Router 2]
    end
    subgraph GCP["Google Cloud"]
        CR1[Cloud Router 1<br/>BGP]
        CR2[Cloud Router 2<br/>BGP]
        VLAN1[VLAN Attachment<br/>Edge Availability Domain 1]
        VLAN2[VLAN Attachment<br/>Edge Availability Domain 2]
    end

    OR1 <-->|BGP session| VLAN1
    OR2 <-->|BGP session| VLAN2
    VLAN1 --- CR1
    VLAN2 --- CR2

    OR1 -.HA VPN backup path.-> VPNGW[HA VPN Gateway]
    VPNGW -.-> CR1

AI access patterns

Every consumer of an AI service falls into one of a small number of access patterns, and each should map to a specific identity and network control rather than a shared “everyone hits the same endpoint” assumption:

• Corporate desktops (on-network): reach Gemini Enterprise/Vertex AI through the internal PSC endpoint over the corporate LAN, with identity asserted via SSO and device posture checked via BeyondCorp Enterprise / Context-Aware Access.
• Remote users: the same PSC endpoint, reached through a VPN or, in a fuller BeyondCorp model, without a traditional VPN at all — access is brokered per-request based on identity and device signal rather than network location, which is the actual point of Zero Trust: network location stops being a proxy for trust.
• Developers: typically need broader API access (Vertex AI training, model deployment) but should still route through the same private-access pattern, scoped by IAM role rather than a separate, looser network path.
• Applications and AI agents: service-to-service traffic, authenticated with service account identity (or Workload Identity for GKE), never a shared static credential, and never routed through a path that assumes a human is present to complete an interactive login.

sequenceDiagram
    participant U as Corporate User
    participant IdP as Identity Provider (Entra ID / Okta)
    participant CAA as Context-Aware Access
    participant PSC as PSC Endpoint
    participant GE as Gemini Enterprise

    U->>IdP: Authenticate (SSO + MFA)
    IdP-->>U: SAML/OIDC assertion
    U->>CAA: Request access (device + identity context)
    CAA->>CAA: Evaluate Access Level (device posture, IP, MFA)
    CAA-->>U: Access granted
    U->>PSC: HTTPS request (internal IP)
    PSC->>GE: Forward over Google's private network
    GE-->>U: Response (never traverses public internet)

Secure API access

Private connectivity gets a request off the public internet; identity and policy decide whether it should be allowed at all. Four controls do most of the work:

• Workforce Identity Federation lets an existing external IdP (Entra ID, Okta, or any SAML/OIDC provider) authenticate and authorize workforce users directly against Google Cloud IAM, without synchronizing identities into a separate Google-side directory. That matters for AI access specifically because it means the same MFA and conditional-access policy your IdP already enforces for every other enterprise app also governs Gemini Enterprise access — see Best practices for Workforce Identity Federation.
• IAM should grant access to Vertex AI and Gemini Enterprise resources through groups mapped to job function, per the enterprise foundations blueprint’s guidance, not individually assigned roles that drift from reality within a quarter.
• Context-Aware Access (part of BeyondCorp Enterprise / Chrome Enterprise Premium) evaluates device posture, location, and identity signal per request through Access Levels — named, reusable conditions — enforced by Service Perimeters, letting you require a managed, patched device for anyone touching an AI agent with access to regulated data, independent of network path.
• VPC Service Controls (detailed below) is the network-perimeter backstop: even a correctly authenticated, correctly authorized request is blocked if it originates from outside an approved network or identity context the perimeter defines.

The combined effect: an employee reaches Gemini Enterprise over a private IP (PSC), having authenticated through the enterprise IdP the security team already controls (Workforce Identity Federation), on a device that passed a posture check (Context-Aware Access), inside a perimeter that would block the request even if every other control were somehow bypassed (VPC Service Controls). No layer is sufficient alone; that redundancy is the design goal, not an inefficiency.

AI agent networking

Agents introduce a traffic pattern most enterprise networks were never built to see: short-lived, high-frequency, service-to-service calls between an orchestrating agent, the tools/data sources it calls via MCP, and other agents it delegates to — almost entirely east-west traffic that never crosses a traditional perimeter firewall.

Where agents actually run. Vertex AI Agent Engine runs your agent code in a Google-managed tenant project with no default access to your VPC — by design, to keep the multi-tenant control plane isolated. Reaching your private resources (an internal API, an on-prem database, an MCP server behind your firewall) from that agent requires a PSC interface, which is also the mechanism required to give an agent controlled internet egress when VPC Service Controls is enabled — Agent Engine doesn’t provide its own internet egress path, so a proxy VM with an RFC 1918 address inside your VPC is the supported pattern for that specific need.

Self-hosted agents (on GKE, Cloud Run, or Compute Engine — common when an agent needs custom runtime dependencies Agent Engine doesn’t support, or when you want full control over the egress path) sit inside your own Shared VPC from the start, which simplifies the networking at the cost of managing more infrastructure yourself.

MCP servers — whether Google-managed (for Workspace/BigQuery-style connectors) or self-hosted (for an internal system with no existing connector) — are just another internal service from a networking standpoint: reachable over internal DNS and private IPs, authenticated per-call, never exposed on a public listener regardless of how convenient that would be for early testing.

flowchart TB
    subgraph Tenant["Google-managed tenant project"]
        Orchestrator[Orchestrator Agent<br/>Vertex AI Agent Engine]
    end
    subgraph VPC["Enterprise Shared VPC"]
        PSCI[PSC Interface]
        ProxyVM[Egress Proxy VM<br/>RFC 1918]
        SubAgent[Sub-agent<br/>Cloud Run]
        MCPServer[Self-hosted MCP Server<br/>GKE]
        InternalAPI[Internal REST API<br/>Compute Engine]
    end
    Internet((Public Internet<br/>third-party API))
    OnPrem[(On-prem system<br/>via Interconnect)]

    Orchestrator -->|producer-initiated| PSCI
    PSCI --> SubAgent
    PSCI --> MCPServer
    MCPServer --> InternalAPI
    InternalAPI --> OnPrem
    Orchestrator -->|controlled egress only| PSCI
    PSCI --> ProxyVM
    ProxyVM --> Internet

Enterprise data connectivity

RAG pipelines and data-grounded agents need read (and sometimes write) access across a wide span of systems, each with its own private-connectivity pattern:

• BigQuery, Cloud SQL, AlloyDB: reached over Private Google Access / PSC for BigQuery’s API surface, and via Private Service Connect for Cloud SQL or AlloyDB’s private-IP networking for the database connections themselves — never through a public IP with an authorized-networks allowlist, which is a materially weaker control than network-layer isolation.
• Oracle, SAP, SQL Server, IBM MQ, on-premises databases: reached over the hybrid connectivity layer (Interconnect or HA VPN) already covered above — these don’t get a new networking pattern, they use the same private path everything else on-premises uses, resolved through split-horizon internal DNS.
• NAS and file shares: typically reached via the same hybrid path, or via Filestore if migrated into Google Cloud, with access scoped by IAM and, where supported, VPC Service Controls.
• Google Drive and Google Workspace sources: reached through Gemini Enterprise’s native Workspace connectors, which run inside Google’s trust boundary already — no separate network path needed, but worth confirming these connectors are included, deliberately, inside your VPC-SC perimeter’s access scope.
• GitHub, Jira, Confluence, and other SaaS sources: reached via Agent Builder/MCP connectors over the public internet by default (these are external SaaS products, not Google Cloud resources) — the control here isn’t network privacy, it’s making sure the connector’s OAuth scope and the agent’s access to it are as narrow as the use case actually requires, and that Cloud DLP or equivalent screens what gets pulled into a RAG index from an external SaaS source before it’s grounded into agent responses.

Security architecture

Networking answers “can the request physically get there.” IAM, policy, and detection answer “should it, and would we know if something went wrong anyway.” Four controls carry most of that weight for an AI platform specifically:

VPC Service Controls creates a service-level perimeter around a set of projects and APIs — Vertex AI, Gemini Enterprise, BigQuery — that blocks data movement (and public internet access to those APIs) across the boundary except through explicitly configured ingress/egress rules. This is the single highest-leverage control against AI-specific data exfiltration risk: an agent or a compromised credential inside the perimeter still can’t copy a BigQuery dataset out to a personal Cloud Storage bucket in another project, because the perimeter — not just IAM — blocks that path. Note the operational tradeoff covered in VPC-SC’s own guidance on Security Command Center: protecting a perimeter can also block SCC’s own service agents from scanning inside it unless ingress rules explicitly permit them — a common cause of “why did my threat detection coverage silently drop” incidents after a perimeter goes live.

IAM and service accounts. Agents and MCP servers should run under dedicated, narrowly scoped service accounts — never a shared “AI platform” service account reused across every agent, which turns any single agent’s compromise into every agent’s compromise. Organization Policy constraints (disabling service account key creation, requiring OS Login, restricting public IP creation) should be enforced at the folder level so no individual project can opt out by omission.

Firewalls. Hierarchical firewall policies set organization- and folder-level rules (default-deny east-west by default, explicit allow for known agent-to-tool and agent-to-data paths) that individual project owners can’t override — the flat-VPC, allow-everything-internal pattern common in early cloud adoption is precisely what turns one compromised agent into full internal network access.

Cloud Armor protects any AI-facing endpoint that does need a public listener (a customer-facing chat widget backed by Gemini Enterprise, for instance) against L3/L4 DDoS and L7 application-layer attacks, with hierarchical security policies letting a central team enforce a baseline WAF policy across every public-facing AI surface in the organization.

Rounding out the layer: Security Command Center for centralized posture and threat findings, Sensitive Data Protection (DLP) for classifying and redacting sensitive data before it’s indexed into a RAG pipeline or returned in an agent response, CMEK via Cloud KMS for customer-controlled encryption keys on data at rest, Secret Manager for API keys and connector credentials instead of environment variables or config files, and Certificate Manager for TLS certificate lifecycle on any load balancer in front of an AI-facing service.

flowchart TB
    subgraph Perimeter["VPC Service Controls Perimeter: AI Platform"]
        VAI[Vertex AI]
        GE[Gemini Enterprise]
        BQ[BigQuery]
        AgentSA[Agent Service Accounts<br/>scoped per-agent]
    end
    subgraph Bridge["Explicit ingress/egress rules"]
        SCC_Agent[Security Command Center<br/>Service Agent]
        Approved[Approved partner project]
    end
    Internet((Public Internet)) -.blocked.-> Perimeter
    SCC_Agent -->|explicit ingress rule| Perimeter
    Perimeter -->|explicit egress rule, reviewed| Approved
    HierFW[Hierarchical Firewall Policy<br/>default-deny east-west] --> Perimeter
    Armor[Cloud Armor<br/>public-facing endpoints only] --> PublicEndpoint[Customer-facing Chat Widget]
    PublicEndpoint --> GE

Logging and monitoring

Private connectivity and perimeters reduce the attack surface; logging is what lets you prove they’re working and catch the case where they didn’t. At minimum:

• Cloud Audit Logs — specifically Data Access logs, which are not enabled by default for most services — record every API call against Vertex AI and Gemini Enterprise resources, including who called what, from where, and whether it was allowed.
• VPC Flow Logs and NCC/Interconnect telemetry give you the network-layer view: which internal services are actually talking to which, useful both for east-west traffic baselining and for spotting an agent reaching somewhere it has no business reaching.
• Security Command Center findings surface misconfigurations (a public IP where Organization Policy should have prevented one, an overly permissive IAM binding) and active threats, with the caveat noted above that VPC-SC perimeters need explicit ingress rules for SCC’s own scanning to keep working.
• Log Analytics / SIEM export — routing Cloud Logging into BigQuery for Log Analytics, or exporting to an existing SIEM — is what turns raw logs into an actual detection capability rather than a compliance checkbox nobody queries until an incident forces the question.

For AI usage specifically, the two things worth a dedicated dashboard are unusual data-access volume through Vertex AI/Gemini Enterprise APIs (a leading indicator of either a runaway agent or a compromised credential) and any Data Access log entry showing an ingress rule exception being exercised on a VPC-SC perimeter — that’s a boundary being crossed by design, and it should be rare enough that every occurrence gets looked at, not aggregated into a monthly report nobody opens.

High availability and disaster recovery

An AI platform inherits the same HA/DR requirements as any production system, with two additions worth calling out specifically.

Multi-region deployment. Vertex AI and Gemini Enterprise resources are regional; a genuinely resilient architecture runs agent infrastructure and data stores in at least two regions, with NCC’s hub-and-spoke topology providing consistent connectivity to both from every spoke rather than needing region-specific network paths configured individually.

Redundant hybrid connectivity. As covered above, HA VPN’s 99.99% SLA requires the two-tunnel, two-interface topology; Interconnect redundancy requires attachments across separate edge availability domains, and, for metro-level fault tolerance, a second Interconnect in a separate metro entirely.

PSC redundancy. A PSC endpoint should be backed by a producer service with its own regional or multi-regional resilience — check the specific service’s SLA rather than assuming PSC itself adds availability beyond what the producer already provides.

DR planning for agents specifically should include: where agent configuration and prompt/tool definitions are stored (and whether that’s backed up independently of the runtime), whether a regional failure requires re-establishing PSC interfaces and network attachments in the failover region (it typically does, since these are regional resources), and whether your MCP servers and internal APIs have their own failover story that the agent layer doesn’t paper over.

flowchart TB
    HUB((NCC Hub - Global))
    subgraph R1["Region: us-central1"]
        AI1[Vertex AI / Gemini Enterprise]
        PSC1[PSC Endpoint]
    end
    subgraph R2["Region: us-east1 (DR)"]
        AI2[Vertex AI / Gemini Enterprise]
        PSC2[PSC Endpoint]
    end
    HUB --- R1
    HUB --- R2
    subgraph Hybrid["Redundant Hybrid Connectivity"]
        IC1[Dedicated Interconnect<br/>Edge Domain A]
        IC2[Dedicated Interconnect<br/>Edge Domain B]
        VPNBackup[HA VPN - backup path]
    end
    HUB --- IC1
    HUB --- IC2
    HUB --- VPNBackup
    IC1 --- OnPrem[(On-Premises)]
    IC2 --- OnPrem
    VPNBackup -.failover.-> OnPrem

Deployment models

Not every organization needs the full architecture above on day one. The table below is a decision matrix, not a maturity ladder — a highly regulated enterprise with 200 employees still needs the regulated-tier controls, regardless of size.

Reference architectures

The diagrams throughout this piece compose into a small number of end-to-end reference patterns. Rather than repeat near-identical diagrams, here’s how the pieces above map to each named pattern:

• Fully Private Gemini Enterprise = the landing zone (Section 3) + private connectivity (Section 4) + secure API access (Section 8), with a VPC-SC perimeter (Section 11) wrapping the whole thing and no public ingress rule defined at all.
• Hybrid Enterprise = the above, plus the hybrid connectivity topology (Section 6) and NCC hub (Section 5) extending the same private paths to on-premises identity, data, and users.
• Multi-region AI platform and Disaster recovery = the High Availability diagram (Section 13) directly.
• Secure AI agent platform = the AI agent networking diagram (Section 9), with PSC interfaces and the egress proxy pattern as the distinguishing feature versus a simple “employee reaches Gemini Enterprise” flow.
• RAG architecture = Vertex AI Search and enterprise data connectivity (Section 10) feeding into the agent networking diagram — a RAG pipeline is architecturally an agent with unusually broad, unusually sensitive read access, which is exactly why it deserves the same PSC/VPC-SC treatment rather than a lighter-touch exception for being “just retrieval.”
• On-premises integration and Branch office architecture = the NCC hub-and-spoke diagram (Section 5) and hybrid connectivity diagram (Section 6), with a branch office modeled as an additional HA VPN or Partner Interconnect spoke on the same hub rather than a separate architecture.

Common mistakes

The failure modes below account for the overwhelming majority of AI-platform network incidents Google and independent security research report, and none of them are exotic:

• Public IPs on AI infrastructure — VMs or GKE nodes hosting self-hosted agents or MCP servers with an external IP “just for now” during development, that never gets removed before production.
• Open firewall rules, especially 0.0.0.0/0 ingress rules left over from initial connectivity testing, or overly broad internal-allow rules that let any VM in a VPC reach any other VM regardless of function.
• Missing VPC Service Controls entirely, or a perimeter configured so loosely (broad access levels, unreviewed egress rules) that it provides a compliance checkbox without an actual exfiltration control.
• Poor IAM design — individual role grants instead of group-based access, service accounts with roles/owner or roles/editor because a narrower role wasn’t worked out under launch deadline pressure, and roles that never get revisited after the project that justified them ends.
• Flat VPCs with no internal segmentation, where an agent’s compromise or a single misconfigured MCP server has a clear network path to every other internal system.
• Shared service accounts across multiple agents or environments, which turns “which agent did this” into a forensic question during an incident instead of an immediate answer from the log.
• Public APIs for internal tools — standing up an internal API or MCP server with a public listener because it’s faster to test against from a laptop, intending to lock it down “before launch.”
• Missing Private Google Access on a subnet, silently forcing traffic that should be private out through a NAT gateway or, worse, a public IP path that nobody explicitly chose.

Best practices checklist

Networking

• Shared VPC with host/service project separation per environment
• Private Google Access enabled on every subnet
• restricted.googleapis.com used by default; private.googleapis.com only where a specific non-VPC-SC API requires it
• PSC endpoints for all inbound access to Gemini Enterprise / Vertex AI
• PSC interfaces for any agent needing to reach private resources or controlled internet egress
• NCC hub-and-spoke topology once more than 2-3 VPCs or hybrid sites need mutual reachability
• Redundant hybrid connectivity (dual Interconnect or HA VPN’s required two-tunnel topology)

Security

• VPC Service Controls perimeter around every project touching Vertex AI, Gemini Enterprise, or sensitive BigQuery datasets
• Hierarchical firewall policies enforcing default-deny east-west at the folder level
• Cloud Armor on any public-facing AI endpoint
• CMEK on data at rest for regulated workloads
• Secrets in Secret Manager, never in code or environment configuration

IAM

• Group-based IAM bindings, not individual grants
• Dedicated, narrowly scoped service account per agent
• Workforce Identity Federation for workforce access instead of synced/duplicated identities
• Organization Policy constraints (no public IPs, no service account keys) enforced at the folder level

Monitoring

• Data Access audit logs enabled for Vertex AI and Gemini Enterprise
• VPC Flow Logs enabled on subnets carrying agent-to-agent and agent-to-data traffic
• SIEM or Log Analytics export configured, not just default retention
• Alerting on any VPC-SC ingress/egress rule exception being exercised

Operations

• Documented DR runbook covering PSC interface and network attachment re-establishment in a failover region
• Regular review cadence for IAM bindings and VPC-SC access levels, not “set once at launch”
• MCP servers and internal APIs inventoried centrally — no team standing up an untracked MCP server

Compliance

• VPC-SC perimeters tested in dry-run mode before enforce mode, for every regulated workload
• Compliance-scope resources isolated in a dedicated folder with its own perimeter
• Immutable/extended log retention where regulation requires it

Cost optimization

• Interconnect capacity sized to actual sustained throughput, not peak-guess provisioning
• PSC and NCC spoke count reviewed periodically — decommissioned projects should have their spokes removed, not left attached

High availability

• Multi-region deployment for any AI service with an internal SLA commitment
• HA VPN deployed in the two-tunnel, two-interface topology required for its SLA
• Interconnect redundancy across separate edge availability domains, and separate metros for regulated/global tiers

Next steps

1. Inventory what’s already public. Before designing anything new, audit existing Vertex AI, Gemini Enterprise, and agent infrastructure for public IPs, open firewall rules, and missing VPC Service Controls — you cannot prioritize a gap you haven’t found.
2. Stand up the landing zone if it doesn’t already exist. Shared VPC and environment separation are the prerequisite for everything else in this piece; retrofitting them under a flat, single-project setup is materially harder than starting with them.
3. Enable Private Google Access and restricted VIP DNS routing first — it’s the highest-leverage, lowest-effort control here, and it doesn’t require re-architecting anything else to deploy.
4. Pilot VPC Service Controls in dry-run mode against one AI project before enforcing broadly, to surface the ingress/egress rules you’ll actually need without an outage while you find them.
5. Design the agent networking pattern (PSC interface + egress proxy) before the first agent needing private data access ships, not after a workaround (a public API, a hardcoded credential) has already been built and adopted.

If you’d rather have an experienced team validate or build this architecture directly, our Cloud Security and AI Services teams do exactly this kind of Google Cloud network and security architecture work. Get in touch to talk through your specific environment.

FAQ

See the frequently asked questions section below this article for schema-formatted answers to the questions we hear most from architects evaluating this design.

References

All architectural recommendations in this piece are grounded in Google’s own published documentation:

• Gemini Enterprise Agent Platform networking access overview
• VPC Service Controls with Gemini Enterprise Agent Platform
• Configure private UI access for Gemini Enterprise
• Vertex AI Agent Engine overview
• Using a Private Service Connect interface with Vertex AI Agent Engine
• VPC Service Controls with Vertex AI
• About Private Service Connect interfaces
• Private Service Connect overview
• Private access options for services
• Configure Private Google Access
• Configure Private Google Access for on-premises hosts
• Network Connectivity Center overview
• Preset connectivity topologies (NCC)
• VPC spokes overview (NCC)
• Hub-and-spoke network architecture (Architecture Center)
• Cloud Router overview
• HA VPN topologies
• HA VPN over Cloud Interconnect overview
• Partner Interconnect overview
• Shared VPC overview
• Enterprise foundations blueprint
• BeyondCorp Enterprise (Chrome Enterprise Premium) overview
• Overview of VPC Service Controls
• Overview of VPC Service Controls and Security Command Center
• Security Command Center overview
• Cloud Armor overview
• Cloud Armor hierarchical security policies overview
• Workforce Identity Federation
• Best practices for Workforce Identity Federation
• Organization Policy constraints reference
• Secret Manager overview
• CMEK for Secret Manager