Enterprise Managed AI Agents: Security Architecture with VPC-SC and PSC

1. Architectural Foundation: The Three-Layer Security Model for Enterprise Managed AI Agents

Deploying enterprise-grade managed AI agents within an isolated Virtual Private Cloud (VPC) requires a defense-in-depth framework that safeguards corporate intelligence at every boundary.
To establish resilient security for Managed Agents API configurations and IAM access management, organizations implement a structured three-layer security model encompassing network isolation, perimeter-based data exfiltration prevention, and granular identity governance.

Core Defense-in-Depth Tiers for AI Agents

The three-layer security architecture establishes defense tiers designed to secure enterprise AI assistant interactions across physical routing boundaries, cloud service perimeters, and internal permission frameworks.

Security Layer	Key Mechanism	Target Threat Vector
Network Isolation	Private Service Connect	Public internet exposure and unencrypted or open routing vectors
Data Exfiltration Prevention	VPC Service Controls	Unauthorized downloading or data transfer to external clouds and unmanaged endpoints
Granular Permission Control	IAM roles (e.g., roles/aiplatform.user) and specific bucket ACLs	Unauthorized resource modifications and privilege misuse resulting from compromised credentials

Network Isolation and Perimeter Boundaries

The Network Isolation tier operates at the foundation of the architecture by utilizing Private Service Connect.
This mechanism completely eliminates public internet routing, establishing and enforcing private VPC communication channels for managed agent workloads.
Building directly on top of network isolation, the Data Exfiltration Prevention layer implements VPC Service Controls around the AI assistant's perimeter.
This perimeter defense prevents unauthorized downloading, copying, or moving of sensitive corporate data across boundaries to external clouds or unmanaged endpoints.

Granular Identity Governance

Within the isolated perimeter, the Granular Permission Control tier manages authorization down to individual resources and storage components.
By implementing specific IAM roles—such as roles/aiplatform.user—alongside targeted Cloud Storage bucket access control lists (ACLs), this layer restricts operational rights to least-privilege levels.
This granular access management ensures that even if credentials are breached, unauthorized modifications to AI resources, agent pipelines, or underlying enterprise storage repositories remain strictly blocked.

2. Data Exfiltration Prevention: Enforcing VPC Service Controls (VPC-SC) Perimeters

Deploying enterprise AI assistants and Managed Agents APIs within isolated network boundaries requires safeguards that extend beyond identity-level authentication.
While Identity and Access Management (IAM) governs identity authorization, it cannot independently prevent authorized identities from copying sensitive model weights or prompt data to external environments.
VPC Service Controls (VPC-SC) resolves this boundary challenge by establishing a strict security perimeter around Google Cloud resources, blocking unauthorized data exfiltration across public networks.
Even if valid IAM credentials are compromised or misused, VPC-SC denies API calls originating from unauthorized public internet locations.

Restricted VIP and Private VIP Routing Configurations

Network traffic intended for protected APIs inside the isolated perimeter must be routed through dedicated private virtual IP addresses rather than default public endpoints.
Google Cloud provides distinct routing paths to handle VPC-SC traffic and standard private communications.

Endpoint Type	DNS Domain Name	Assigned IP Range	Primary Function and Scope
Restricted VIP	restricted.googleapis.com	199.36.153.4/30 (199.36.153.4, 199.36.153.5, 199.36.153.6, 199.36.153.7)	Routes traffic strictly to VPC-SC supported services to ensure data perimeter boundary compliance.
Private VIP	private.googleapis.com	199.36.153.8/30	Enables private connectivity to Google Cloud APIs without perimeter-only routing constraints.

Restricted VIP resolves restricted.googleapis.com to the IP range 199.36.153.4/30, covering IP addresses 199.36.153.4, 199.36.153.5, 199.36.153.6, and 199.36.153.7.
Conversely, Private VIP routes traffic via private.googleapis.com across the 199.36.153.8/30 address range.
To accommodate authorized administrative workloads across boundaries, context-aware access can be granted using ingress rules.
These ingress rules evaluate incoming client attributes, including source IP addresses, client identities, device data, or source Google Cloud projects.
During implementation, administrators can deploy dry-run mode to monitor API traffic patterns and analyze potential perimeter violations without blocking active production requests.

Blocking Cross-Boundary Storage and Query Operations

Within an enforced perimeter, VPC-SC encapsulates the entire operational lifecycle of AI workflows and associated datasets.
Protected artifacts include training data, custom models, neural architecture search models, online inference requests, batch inference results, and Gemini models.
When assets reside within this boundary, direct data transfers to unsanctioned external environments are systematically intercepted.
For example, running gcloud storage cp to transfer files to external public Cloud Storage buckets is blocked across perimeter boundaries.
Similarly, execution of bq mk targeting external BigQuery tables is prevented, halting unauthorized external data ingestion and egress.

Operational Trade-Offs and Perimeter Limitations

Implementing VPC-SC involves specific operational constraints that engineering teams must account for when designing AI architectures.
VPC-SC is structured specifically to control data payload movement rather than metadata attributes.
Furthermore, real-time URL context retrieval is disabled in VPC-SC protected projects to prevent outbound data exfiltration channels.
Additionally, request and response logging cannot be used under VPC Service Controls.
These functional trade-offs require architecting agent inspection workflows and audit processes within the explicit boundaries defined by the perimeter.

3. Private Connectivity Architecture: Implementing Private Service Connect (PSC) and Subnet Attachments

Deploying enterprise AI assistants and Managed Agents workloads within fully isolated VPC perimeters requires a zero-trust network fabric that prevents data exfiltration and blocks exposure to public routing tables.
To securely connect isolated compute environments with Google-managed agent infrastructure, architects must implement bidirectional private networking using Private Service Connect (PSC) endpoints, dedicated network attachments, and controlled egress gateways.

PSC Google API Endpoints and IP Reservation

Private Service Connect (PSC) for Google APIs establishes secure, direct communication channels between consumer VPCs and Google-managed services over internal VPC or hybrid networks.
By deploying PSC endpoints, workloads target consumer-specified internal IP addresses and private DNS endpoints rather than routing across the public internet.
These PSC endpoints allow consumer VPCs to initiate private connections directly to Google-managed producer services, keeping all API calls strictly within Google's private backbone.
In an enterprise deployment pattern, an internal PSC endpoint IP allocation uses a reserved static private IP, such as 10.0.60.100, ensuring predictable name resolution and strict firewall control for all outbound API calls.

Transitive Access via PSC Network Interfaces and Attachments

While traditional endpoints handle consumer-to-producer traffic, managed AI workloads require reverse communication into consumer resources.
PSC Network Interfaces enable producer managed services, such as Vertex AI Pipelines and Agent Runtime, to initiate transitive connections back into consumer VPC subnets.
To facilitate this pattern, network attachment resources are configured directly inside the consumer VPC to allocate private IP addresses to the producer PSC interfaces.
For example, a pipeline network attachment subnet can be provisioned with a dedicated CIDR block of 192.168.10.0/28 to isolate pipeline-driven traffic.
Architects must account for resource lifecycle constraints: network attachments cannot be deleted by the consumer until the producer service actively releases the allocated PSC interface resources.

Network Construct	IP / CIDR Allocation	Directionality	Architectural Purpose
Internal PSC Endpoint	10.0.60.100	Consumer to Producer	Routes private Google API and agent runtime calls without public internet exposure.
Pipeline Network Attachment Subnet	192.168.10.0/28	Producer to Consumer (Transitive)	Assigns consumer IP addresses to producer PSC interfaces for Vertex AI Pipelines and Agent Runtime.
IAP TCP Forwarding Range	35.235.240.0/20	Inbound Administrative	Enables secure administrative VM access without public IP assignment.

Cloud NAT and Secure Outbound Egress Design

Maintaining isolation requires that backend nodes and agent execution runtimes operate completely devoid of public IP addresses.
To support outbound internet dependencies where required, Cloud Router and Cloud NAT allow controlled outbound egress for managed workloads without assigning external IP addresses to individual VMs or instances.
For secure operational access into private runtime environments, Identity-Aware Proxy (IAP) TCP forwarding utilizes the source IP range 35.235.240.0/20 to establish administrative tunneling without exposing public ingress pathways.
This combination ensures that agent runtime components remain shielded from external ingress while preserving outbound connectivity and administrative accessibility.

4. Least-Privilege Identity Management: IAM Roles and Dedicated Service Account Configurations

Securing an enterprise AI assistant deployment inside an isolated VPC requires establishing granular identity controls alongside private network routing.
Identity and Access Management (IAM) defines the exact operational boundaries for execution runtimes, data grounding sources, and automated infrastructure provisioning.

Dedicated Agent Service Account Scoping

Enterprise deployments must avoid shared or broadly privileged identities by configuring dedicated service accounts for AI agent execution.
Assigning the roles/aiplatform.user role to the dedicated agent service account provides the specific permissions required for execution and prediction invocation on Vertex AI and Agent Platform resources.
Access to grounding data is strictly constrained at the resource level by applying granular Cloud Storage permissions.
Assigning the objectViewer role ensures that the agent runtime can only read from designated internal knowledge base buckets without granting broader storage administrative rights.

Identity Principal	Assigned IAM Role	Functional Scope
Dedicated Agent Service Account	roles/aiplatform.user	Execution and prediction invocation across Vertex AI and Agent Platform resources.
Dedicated Agent Service Account	objectViewer (Storage)	Granular, read-only retrieval scoped strictly to designated internal knowledge base buckets.
Vertex AI Service Agent (service-$projectnumber@gcp-sa-aiplatform.iam.gserviceaccount.com)	roles/compute.networkAdmin	Management and provisioning of Private Service Connect (PSC) interface resources inside the VPC.

Service Agent Networking Privileges for PSC Management

Deploying managed agent infrastructure across isolated VPCs requires delegating networking capabilities to Google-managed service identities.
The platform service agent, formatted as service-$projectnumber@gcp-sa-aiplatform.iam.gserviceaccount.com, requires the roles/compute.networkAdmin role.
This administrative assignment allows the service agent to orchestrate, provision, and manage Private Service Connect (PSC) interface resources directly on behalf of Vertex AI within the target network.

Pairing Identity Controls with Network Boundary Enforcements

IAM policies provide essential identity-based access governance within a defense-in-depth architecture.
These granular role assignments operate in direct conjunction with VPC Service Controls (VPC-SC) boundary controls to ensure authenticated and authorized interactions.
A core architectural limitation is that IAM alone does not restrict physical or logical network paths, nor does it inherently prevent credential reuse from unauthorized external networks.
Consequently, pairing strict IAM principal scoping with VPC-SC perimeter enforcement is mandatory to maintain absolute isolation for managed enterprise agents.

5. Operational Runtime Constraints: Deploying Agent Runtime, Pipelines, and Workbench in VPC-SC

Executing enterprise AI assistants inside an isolated VPC requires addressing runtime dependencies, networking routes, and orchestration boundaries within VPC Service Controls (VPC-SC).
Establishing secure Managed Agents API interactions depends heavily on how runtime environments and developer tooling interact with the service perimeter.

Pre-Enrollment Traps and Perimeter Enrollment Sequencing

A foundational requirement for enterprise agent security is the strict sequencing of resource provisioning relative to perimeter boundary establishment.
Agent Runtime environments deployed inside VPC-SC must be provisioned strictly after the target Google Cloud Platform (GCP) project is joined to the service perimeter.
If an agent execution environment or inference endpoint is created prior to project perimeter enrollment, the resource remains unprotected by the boundary and continues to retain public access pathways.
Retroactive perimeter assignment does not remediate pre-existing public paths, creating severe isolation gaps for enterprise AI agents.

Dependency Ingestion via Private Registries and Egress Proxies

Runtime services and pipelines operating within an enforced perimeter encounter strict networking blocks by default.
Producer services inside VPC-SC have all default internet access blocked, cutting off outbound connections to public package repositories.
Consequently, Vertex AI Pipelines running within VPC-SC cannot download dependencies directly from public PyPI.
Pipeline workflows must instead rely on pre-built custom containers or private VPC Artifact Registry repositories to pull runtime packages securely.
When external internet egress is explicitly needed for external APIs or outbound tool calls, environments must be configured with RFC 1918 proxy VMs—utilizing proxies such as Squid, HAProxy, Envoy, or TinyProxy—alongside Cloud NAT to handle mediated egress routing.

Workbench DNS Peering and Private Endpoint Governance

Interactive development environments and model serving configurations require specialized private networking routing to function within the security perimeter.
Vertex AI Workbench instances utilizing custom kernels under VPC-SC require DNS peering to route *.notebooks.googleusercontent.com directly to private.googleapis.com on IP range 199.36.153.8/30.
Without this DNS peering configuration, Workbench kernels cannot maintain secure internal communication within the perimeter.
Furthermore, standard Model Garden one-click public dedicated endpoint deployments are strictly unsupported in VPC-SC environments.
Agent architectures must be provisioned using private endpoints to ensure that all foundation model inference stays confined to private network paths.