When your application calls Claude on Vertex AI, the request goes to a Google API hostname such as aiplatform.googleapis.com (or a regional variant like LOCATION-aiplatform.googleapis.com). These are public endpoints: reachable from anywhere with valid credentials, and reached from your VPC via routes that many enterprise network policies treat as "internet egress" even though the traffic stays on Google's network. For workloads under strict network controls — no public egress, all API traffic inspectable and attributable — Google Cloud provides private connectivity options, and Private Service Connect (PSC) for Google APIs is the modern centerpiece.
What PSC for Google APIs actually does
PSC lets you create an endpoint inside your own VPC — an internal IP address you choose — that fronts Google's APIs. Your DNS then resolves Google API hostnames to that private IP, so a Claude request from a VM, GKE pod, or Cloud Run service with VPC connectivity never needs a route to the public internet at all. From the application's perspective nothing changes: the AnthropicVertex client still calls the same hostname; the network path underneath is what moved.
Google's Vertex AI security guidance frames the recommended pattern explicitly: use the restricted VIP (the locked-down virtual IP range for Google APIs that supports VPC Service Controls) with Private Service Connect for Google APIs, or Private Google Access, to establish a private network route to Google APIs. Private Google Access is the older, simpler mechanism — it lets resources without external IPs reach Google APIs — while PSC adds the per-VPC endpoint and naming control that hub-and-spoke and on-premises designs usually need.
PSC alone is a network control, not a data control
A private route stops traffic from traversing the public internet; it does not, by itself, stop an authorized-but-compromised identity from sending data to some other Google project's APIs over that same private route. That is the job of VPC Service Controls (VPC-SC), which Google positions precisely as mitigating data exfiltration risk. A service perimeter that protects Vertex AI keeps protected artifacts — including requests for online inferences and results from batch inference — from leaving the perimeter, and once Vertex AI is in a perimeter, all public internet access to it is automatically blocked unless callers are explicitly allowlisted through access levels or ingress rules. Perimeter-supported capabilities include online inference, batch inference, and generative AI.
Setup walkthrough (shape, not clicks)
- Decide the API surface. Choose the restricted VIP bundle if you are pairing with VPC-SC. Confirm the Vertex endpoint style your Claude code uses (global, multi-region, or regional hostname) so DNS covers it.
- Create the PSC endpoint in your VPC with a reserved internal IP targeting Google APIs.
- Wire up DNS so the relevant
*.googleapis.comnames resolve to that IP for your VPC (and, via hybrid DNS, for on-premises callers if needed). - Close the public path. Remove default internet egress routes or block them with firewall policy, so the private path is the only path.
- Add the perimeter. Put the project in a VPC-SC perimeter protecting Vertex AI, then test both directions: legitimate calls succeed, out-of-perimeter access fails.
The precise commands and supported hostname sets change over time — follow Google's current PSC and VPC Service Controls documentation for the authoritative steps.
Two gotchas worth knowing before the design review
First, request-response logging isn't available with VPC Service Controls. That is the Vertex feature that records prompt and completion payloads (the one Anthropic recommends enabling on a 30-day rolling basis for misuse tracking). Inside a perimeter you keep Cloud Audit Logs — who called what, when — but not payload capture, so plan application-level logging if your governance requires content retention. Second, test your endpoint-type choice early: private routing and perimeter rules interact with global versus regional endpoints and with org policies like constraints/gcp.restrictEndpointUsage (see org policy constraints), and it is far cheaper to discover a mismatch in a sandbox than in a production cutover.
Where to go next
Read the VPC Service Controls deep dive for perimeter design, and EU data residency if your motivation for private routing is regional control rather than exfiltration defense.