VPC Service Controls (VPC-SC) is Google Cloud's data-exfiltration defense: you draw a service perimeter around projects and services, and data covered by those services cannot leave the perimeter. For Vertex AI, Google documents that a perimeter keeps online-inference requests and batch-inference results from leaving, and lists "Online inference", "Batch inference", and "Generative AI" as perimeter-supported services. When the perimeter includes Vertex AI, all public internet access to the instance is automatically blocked unless callers are allowlisted through access levels or ingress rules. For an enterprise running Claude on Vertex AI with sensitive data, it's a natural control to reach for.
But Google's VPC-SC documentation for Vertex AI carries a limitation that surprises many teams: request-response logging isn't available with VPC Service Controls.
Why this particular gap stings
Request-response logging is Vertex AI's mechanism for capturing prompts and model completions — the content-level record of what your applications sent to Claude and what came back. It matters more than it might sound: Anthropic recommends enabling 30-day rolling prompt/completion logging on this platform to track any model misuse, and notes that turning it on gives neither Google nor Anthropic access to your content. Many AI governance programs have adopted exactly that kind of content log as standard evidence.
So the collision is direct. The organizations most likely to want a VPC-SC perimeter — those handling sensitive data — are often the same organizations whose AI policy calls for content logging. Enable the perimeter, and the documented content-logging mechanism goes away.
What still works inside a perimeter
The gap is specific to content capture, not to auditability in general. Within the documented feature set you still have:
- Cloud Audit Logs. Online prediction calls (
endpoints.predict,endpoints.rawPredict) are recorded as Data Access (DATA_READ) audit-log operations once you enable them — who called which model endpoint, when, from which identity. That's metadata, not prompts, but it answers most access-review questions. Setup and the required reader role are covered in the audit-logs article. - Application-side logging. Your calling code sees every prompt and completion before and after Vertex AI does. Logging content from your own application into storage you control (inside the same perimeter) is architecture work rather than a checkbox, but it is not blocked by VPC-SC and gives you full control over retention and redaction.
- Private connectivity best practices. Google's documented private-path guidance — the restricted VIP with Private Service Connect for Google APIs, or Private Google Access — still applies for routing traffic to Vertex AI without touching the public internet.
Plan the trade-off before you lock down
The expensive failure mode is sequencing: a team ships Claude on Vertex AI with request-response logging enabled, governance signs off on that basis, and months later a security initiative wraps the environment in a perimeter — silently ending the log that governance depends on. To avoid it:
- Decide the logging question and the perimeter question together, in the same design review, before production sign-off.
- If the perimeter wins (it usually does for regulated data), record the compensating controls explicitly: enabled Data Access audit logs, application-side content capture if required, and ingress/access-level configuration.
- If content logging is non-negotiable and must be platform-side, that constraint belongs in your platform-selection notes — logging mechanics differ across Bedrock, Vertex AI, and Foundry (see the audit logging overview).
- Re-check Google's VPC-SC limitations page at review time; documented limitations change.
Where to go next
For the wider Vertex AI lockdown toolkit, pair the perimeter with the regional-endpoint org policy, and see prompt-log content privacy for how content logs should themselves be protected.