VPC Service Controls Perimeter Design Prompt
Design or debug a VPC Service Controls perimeter to stop data exfiltration from managed services like BigQuery and Cloud Storage, using dry-run mode and access levels so you don't lock out legitimate access.
- Target user
- Security and platform engineers protecting GCP data services from exfiltration
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior security engineer who has rolled out VPC Service Controls without breaking production. You understand that a service perimeter restricts API access to managed services (BigQuery, Cloud Storage, etc.) based on the request's origin, that ingress/egress rules and access levels govern allowed paths, and that the only safe way to enable a perimeter is dry-run mode first to measure what it would block. I will provide: - The goal: [STOP EXFIL FROM BIGQUERY/GCS / PASS A DATA-RESIDENCY AUDIT / RESTRICT ACCESS TO A CONTEXT] and the projects/services to protect - The current setup: [existing perimeter config if any, access levels, the access policy, and the services in scope] - The legitimate access patterns: [which identities, networks, and other projects must reach the protected services — CI/CD, analysts' IPs, partner projects, on-prem via Interconnect] - Any dry-run violation logs: [if a perimeter exists, the blocked requests it logged] Your job: 1. **Scope the perimeter** — list which projects and which restricted services belong inside the perimeter and why. Flag services that, if added, would break a needed cross-project flow. 2. **Access levels** — define the conditions (IP ranges, device policy, identity) under which access from outside the perimeter is allowed, sized to the real legitimate sources, not wide open. Tie them to the access patterns I provided. 3. **Ingress/egress rules** — design the specific ingress rules (who from where can call into the perimeter) and egress rules (which protected resources can call out, e.g., to a partner project), each as narrow as the requirement allows. Call out the bridge vs. ingress/egress trade-off for cross-perimeter access. 4. **Dry-run first** — require the perimeter be created in dry-run (enforced=false) and provide the log query to surface what it would block. Map each expected violation to whether it's a real path to allow (add an ingress/access level) or actual exfil to block. 5. **Enforcement rollout** — give the sequence: dry-run, analyze violations for a representative period, add the legitimate paths, then enforce — with a rollback note. Output: (a) the perimeter scope (projects + restricted services), (b) access-level definitions with their conditions, (c) ingress/egress rules, (d) the dry-run log query and how to triage violations, (e) the dry-run-to-enforce rollout plan. Default to dry-run mode for any new or expanded perimeter. Never recommend going straight to enforced — the blast radius is every API call to the protected services, and a missed legitimate path takes down data pipelines instantly.
Why this prompt works
VPC Service Controls is one of the highest-blast-radius features in GCP: a service perimeter governs every API call to the managed services inside it, so enabling one carelessly can sever access to BigQuery, Cloud Storage, and the pipelines that depend on them in a single change. This prompt makes dry-run mode non-negotiable, treating the perimeter as something you measure before you enforce. By requiring the model to map each dry-run violation to either a legitimate path to allow or genuine exfiltration to block, it turns perimeter design from a guess into an evidence-driven process.
The design steps reflect how VPC-SC actually controls access. Access levels define the conditions under which outside requests are permitted, and the prompt insists they be sized to the real legitimate sources rather than left wide open — the difference between a perimeter that protects data and one that’s theater. The ingress/egress rules carry the same discipline, kept as narrow as each requirement allows, with the cross-perimeter bridge-versus-rules trade-off surfaced explicitly because that’s where teams accidentally create the hole the perimeter was meant to close.
The guardrails encode the one rule that prevents a VPC-SC rollout from becoming an outage: 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. By defaulting to dry-run, providing the violation-triage query, and sequencing enforcement only after analysis, the prompt produces a perimeter you can actually ship to a live data platform without holding your breath.