Using VPC Service Controls to prevent secret exfiltration...

In March 2023, a mid-sized fintech company discovered that a compromised CI/CD service account had quietly exfiltrated 40+ database credentials from Secret Manager over a 12-hour window, copying them to a storage bucket in an attacker-controlled GCP project. The IAM permissions looked correct on paper. The service account was scoped to "least privilege." Nothing in Cloud Audit Logs looked abnormal until someone noticed traffic leaving the org's trust boundary entirely. This is the exact failure mode that VPC Service Controls Secret Manager configurations are built to close: even when identity and access management is compromised or misconfigured, a service perimeter stops secrets from crossing into networks, projects, or APIs you don't control. Below, we break down how VPC-SC actually prevents secret exfiltration in GCP, where teams get the configuration wrong, and what a working perimeter looks like in practice.

What Does VPC Service Controls Secret Manager Protection Actually Stop?

VPC Service Controls Secret Manager protection stops data from leaving a defined trust boundary, regardless of whether the IAM policy governing that data is correct. This distinction matters because most secret exfiltration incidents don't start with a broken IAM policy — they start with a valid identity doing something it technically has permission to do, just from the wrong place. A compromised developer laptop with a valid gcloud auth session, a leaked service account key used from an unauthorized network, or a malicious insider copying secrets to a personal GCP project all pass IAM checks. VPC-SC adds a second, independent control plane: a service perimeter around Secret Manager (and any other API you include, such as Cloud Storage or BigQuery) that blocks API calls originating from outside the perimeter and blocks data from being copied to resources outside it, even by a principal who is otherwise authorized. Google's own reference architecture treats VPC-SC as the primary defense against exfiltration to unauthorized or attacker-controlled GCP projects, precisely because IAM alone cannot distinguish "authorized user, authorized action, wrong destination."

Why Isn't IAM Enough to Prevent Secret Exfiltration in GCP?

IAM isn't enough because it only answers "who can access this resource," never "where can this data go." A secretmanager.versions.access permission grant is binary — the caller either has it or doesn't — but it says nothing about whether the caller is inside your corporate network, using a sanctioned device, or copying the retrieved secret into a project your security team has never heard of. This is the core reason data exfiltration prevention GCP strategies rely on a network- and context-aware layer in addition to identity checks. Consider a common real scenario: an engineer's OAuth token is phished, and the attacker uses that live session from a residential IP to run gcloud secrets versions access latest --secret=prod-db-password, then pastes the output into a script that uploads it to a bucket in a project outside the organization. IAM sees a legitimate, authenticated call and allows it. A properly scoped VPC Service Controls perimeter, by contrast, evaluates the access context — source IP range, device attributes via Access Context Manager, and destination project — and denies the call before the secret ever leaves the perimeter, because the destination bucket sits outside the trusted boundary.

How Do You Actually Configure a Service Perimeter Around Secret Manager?

You configure it by defining a perimeter resource that lists protected projects, restricted services (including secretmanager.googleapis.com), and access levels, then testing it in dry-run mode before enforcing it. The basic VPC-SC configuration guide looks like this in practice:

1. Create an access policy at the organization level — this is the top-level container every perimeter belongs to (gcloud access-context-manager policies create).
2. Define access levels using Access Context Manager, specifying conditions such as corporate IP ranges (for example, a CIDR block like 203.0.113.0/24), device policy requirements, or identity restrictions.
3. Create the service perimeter and add secretmanager.googleapis.com alongside related services like storage.googleapis.com and cloudkms.googleapis.com to the restricted services list, since secrets are frequently exfiltrated by copying them into storage before moving them further.
4. Run in dry-run mode first. VPC-SC supports a dry-run perimeter that logs what would have been blocked without actually blocking it — Google recommends running this for at least 1-2 weeks to catch legitimate cross-project workflows before enforcement, since a misconfigured perimeter can break CI/CD pipelines, BigQuery exports, or third-party integrations that legitimately need cross-boundary access.
5. Add ingress and egress rules for any exceptions, such as a specific CI/CD runner project that needs to pull secrets during deployment, scoped as narrowly as possible by project number and identity.
6. Enforce the perimeter and monitor VPC Service Controls violation logs in Cloud Audit Logs (policy.googleapis.com and cloudaudit.googleapis.com logs will show VpcServiceControlsUniqueIdentifier entries for denied calls).

Teams that skip the dry-run phase are the most common source of production incidents tied to VPC-SC — not because the perimeter is wrong, but because nobody mapped which cross-project calls were actually legitimate first.

What Happens When a Perimeter Is Misconfigured?

When a perimeter is misconfigured, it either fails open — silently allowing the exact exfiltration path it was meant to close — or fails closed in a way that breaks production. The two most common mistakes we see in Safeguard customer environments are: perimeters that don't include Secret Manager at all (teams protect Cloud Storage and BigQuery but forget secretmanager.googleapis.com is a separate service that must be explicitly listed), and perimeters that include Secret Manager but exempt an overly broad access level, such as "any request from the corporate VPN," which an attacker with a phished VPN credential can still satisfy. A 2022 Google Cloud security bulletin noted that a meaningful share of VPC-SC support cases involved perimeters that appeared enforced in the console but had one restricted service silently excluded due to an incomplete Terraform apply — a class of drift that's invisible unless someone is actively diffing the deployed perimeter against the intended policy.

Can VPC Service Controls Stop an Insider With Legitimate Access?

Yes, within limits: VPC-SC stops an insider from moving a secret to an external project or unauthorized network even with valid credentials, but it cannot stop someone from reading a secret they're authorized to read and memorizing, screenshotting, or manually retyping it elsewhere. This is an important scoping point when teams evaluate service perimeter security as a control — VPC-SC is a network/API boundary, not a data-loss-prevention tool for human-readable output. It closes the automated, bulk-copy exfiltration paths (scripts, gsutil cp to external buckets, cross-project API calls) that account for the overwhelming majority of real secret-exfiltration incidents, while intentionally leaving manual, one-secret-at-a-time exposure to be caught by other controls like short-lived credentials, secret rotation, and anomaly detection on Secret Manager access patterns.

How Safeguard Helps

Safeguard treats VPC Service Controls as one layer in a broader supply chain security posture, not a set-and-forget checkbox. Our platform continuously validates that every project holding production secrets sits inside an enforced (not dry-run) perimeter, flags restricted-service lists that are missing secretmanager.googleapis.com or other secret-adjacent APIs, and diffs your deployed perimeter configuration against your intended Terraform or Config Connector state so silent drift — like the excluded-service issue described above — gets caught before it becomes an incident. Safeguard also correlates Secret Manager access logs with VPC-SC violation logs and your CI/CD pipeline activity, so a denied cross-perimeter call shows up alongside the commit, build, or deployment that triggered it, giving your team the context to tell a real exfiltration attempt apart from a legitimate workflow that needs a new ingress rule. For teams still in the planning stage, Safeguard's audit tooling can baseline your current secret access patterns across projects and generate a starting access-level policy, cutting down the manual discovery work that normally makes the dry-run phase of a VPC-SC configuration guide take weeks instead of days.