🧱 Designing VPC Service Controls With AI: Perimeters and Dry-Run

VPC Service Controls is the GCP feature with the largest gap between “sounds simple” and “blast radius.” The pitch is reasonable: draw a perimeter around your sensitive data services so that even a leaked credential can’t pull BigQuery or Cloud Storage data out to an attacker’s project. The reality is that a perimeter governs every API call to the services inside it, so the first time someone enables one in enforce mode without measuring it, they discover which legitimate pipelines they just severed — usually CI/CD and a few analytics jobs, all at once, in production. I have a simple rule for VPC-SC that I never break: dry-run first, always. AI helps me design the perimeter and, just as importantly, triage what dry-run mode reveals before anything gets enforced.

Scope the perimeter deliberately

The first decision is what goes inside: which projects, and which restricted services. Add too little and the perimeter protects nothing; add a service that’s needed cross-project and you break a legitimate flow the moment you enforce.

Prompt: “We want a VPC Service Controls perimeter to stop exfiltration from BigQuery and Cloud Storage across these three projects. Here are the projects and the services each uses. Recommend which projects and restricted services belong inside the perimeter, and flag any service that, if restricted, would break a needed cross-project data flow we should handle with an ingress/egress rule instead.”

The model is good at reasoning about scope because the question is structural: which API calls cross the boundary you’re drawing. It surfaces the flows that will need an explicit allowance before you find them the hard way.

Access levels sized to real sources

Access levels define the conditions under which a request from outside the perimeter is allowed in — IP ranges, identities, device policy. The temptation is to make them broad so nothing breaks, but a wide-open access level defeats the perimeter. They should match the real legitimate sources and no more.

Prompt: “Define VPC-SC access levels for our perimeter. Legitimate external access comes from: our CI/CD ranges, the analytics team’s office IPs, and an on-prem network over Interconnect. Write access levels scoped to exactly those sources — not wider — and explain how each maps to a real access pattern so I can justify it in an audit.”

Tying each access level to a named pattern keeps the design honest and makes the audit trivial: every condition exists because a specific legitimate caller needs it.

Ingress and egress rules, kept narrow

For controlled paths across the boundary — a partner project that’s allowed to read one dataset, a protected resource that’s allowed to call out — ingress and egress rules carry the load. Each should be as narrow as the requirement allows, and the bridge-versus-rules choice for cross-perimeter access matters.

Prompt: “We need a partner project to read one specific BigQuery dataset inside our perimeter, and one service inside the perimeter must write to a bucket in another perimeter. Design the narrowest ingress and egress rules for each, specifying the identity, the operation, and the resource. Explain when a perimeter bridge is appropriate versus ingress/egress rules, and which is safer here.”

The narrowness is the security. A broad ingress rule is the hole the perimeter was supposed to close, so I push the model to specify identity, operation, and resource on every rule rather than leaving any dimension wide.

Dry-run is non-negotiable

This is the heart of it. A new or expanded perimeter goes into dry-run mode (enforced=false), where it logs what it would block without blocking anything. Then I read those logs and decide, violation by violation, whether each is a legitimate path to allow or actual exfiltration to stop.

Prompt: “We’ve created the perimeter in dry-run mode. Here’s the log query for dry-run violations. Walk me through triaging the results: for each blocked request, how do I tell whether it’s a legitimate flow that needs an ingress rule or access level, versus genuine exfiltration the perimeter should block? Give me a decision checklist.”

Dry-run turns perimeter design from a leap of faith into a measurement. Only after the violations over a representative period are all accounted for — every legitimate path allowed, every real block confirmed — do I flip to enforce, and even then with a rollback ready.

The honest division of labor

AI is strong at the design and triage work VPC-SC demands: scoping projects and services, writing narrowly-scoped access levels and ingress/egress rules, and classifying dry-run violations. Those are structural problems with clear rules, and the model handles them well. What it can’t see is your full inventory of legitimate callers — the obscure batch job, the partner integration nobody documented — which is exactly why dry-run exists and exactly why I never skip it.

The one rule I hold above all others: never go straight to enforced. The blast radius is every API call to the protected services, and a single missed legitimate path takes down data pipelines instantly. The reusable prompts live in my prompts library, and the GCP with AI series covers the broader governance layer this sits within, including Org Policy and Security Command Center triage for the org-wide guardrails around the perimeter. Done right, VPC-SC is a strong exfiltration control; done in a hurry, it’s an outage.