Google Cloud VPC-SC Updates: Folders, PSC Endpoints & Remediation

Autonomous AI agents act as high-speed non-human identities (NHIs), querying APIs and moving data across Google Cloud projects far faster than human operators. While IAM Deny and Organization Policies govern who can act and how resources are configured, VPC Service Controls (VPC-SC) enforces the service-level data perimeter so stolen credentials, misconfigured IAM bindings, or compromised agents cannot exfiltrate data outside your boundary.

Historically, running VPC-SC at enterprise scale meant maintaining brittle project-by-project lists, hitting ingress/egress attribute quotas, and spending days debugging Request is prohibited by organization's policy denials. On October 16, 2026, Google Cloud highlighted five VPC-SC capabilities—available at no additional cost—that align perimeters directly with your resource hierarchy and private networking architecture.

What Changed at a Glance

1. Folder-Level Perimeter Membership

Instead of updating perimeter definitions every time a platform pipeline vends a new project, you can now attach folders/FOLDER_ID directly to a service perimeter (both enforced and dry-run). Every child project and nested subfolder inherits the perimeter policy automatically, and moving a project into or out of a folder updates its coverage dynamically.

Figure 1: Simplified perimeter authoring in VPC-SC.

Pragmatic CLI Usage

Add a folder to an enforced or dry-run perimeter with gcloud:

# Add a folder to an enforced perimeter
gcloud access-context-manager perimeters update prod_data_perimeter \
  --add-resources="folders/789012345678" \
  --policy=POLICY_ID

# Verify which perimeter a project inherits from its folder hierarchy
gcloud access-context-manager lookup-configured-perimeter \
  --resource="projects/345678901234"

The lookup command returns both explicit project bindings and inherited folder bindings (restrictedResource and restrictedResourceDryRun).

Operational caveat: When migrating existing project-scoped perimeters to folder-based perimeters, wait for the 48-hour hierarchy propagation window to complete before removing explicit project bindings so workloads do not experience transient coverage gaps.

2. Folders and Organizations in Ingress and Egress Rules

Multi-project environments and agentic AI workflows frequently hit VPC-SC rule size and attribute limits when authorizing shared services across hundreds of projects. Ingress and egress rules now accept folders/FOLDER_NUMBER and organizations/ORGANIZATION_NUMBER in both the sources and target resources blocks.

Figure 2: Simplified authoring of ingress and egress rules.

Operational caveat: When specifying egressFrom.sources, you must set sourceRestriction: SOURCE_RESTRICTION_ENABLED (otherwise VPC-SC ignores the sources block). Also note that specifying a folder or organization in ingress/egress rules permits access for resources parented at that hierarchy node that cannot themselves be enclosed in a service perimeter.

3. Private Service Connect (PSC) Endpoints in Ingress and Egress Rules

Enterprises standardizing on Private Service Connect (PSC)—including endpoints propagated across spokes via Network Connectivity Center—can now authorize traffic based on the exact PSC forwarding rule (pscEndpoint) rather than a broad VPC network or project.

Figure 3: Supporting Private Service Connect endpoints with ingress and egress rules.

Ingress & Egress YAML Example (Folders + PSC Endpoint)

- title: Allow AI Agents Folder via Dedicated PSC Endpoint
  ingressFrom:
    identities:
      - serviceAccount:[email protected]
    sources:
      - resource: folders/112233445566
      - pscEndpoint:
          forwardingRule: //compute.googleapis.com/projects/net-hub-prod/global/forwardingRules/psc-vpcsc-endpoint
  ingressTo:
    operations:
      - serviceName: bigquery.googleapis.com
        methodSelectors:
          - method: google.cloud.bigquery.v2.JobService.InsertJob
    resources:
      - folders/998877665544

Operational caveats for PSC endpoints in VPC-SC:

• Create the PSC endpoint using the vpc-sc target API bundle for restricted services.
• Only newly created PSC endpoints are supported in ingress/egress rules; legacy PSC endpoints created before this feature must be recreated to be referenced in perimeter rules.
• sources entries (resource, accessLevel, pscEndpoint) are evaluated as an OR condition among themselves, and AND-ed with identities/identityType.

4. Service Patterns in VPC Accessible Services

Classic VPC accessible services require routing traffic to the restricted VIP (restricted.googleapis.com), which blocks all non-VPC-SC-supported Google APIs. Conversely, routing to the private VIP (private.googleapis.com) or a PSC all-apis bundle allows access to unsupported Google APIs by default—creating an exfiltration path if left unchecked.

Service patterns close that gap on the private VIP path (GOOGLE_APIS_VIA_PRIVATE_PATH). You can allow RESTRICTED-SERVICES alongside explicit URL patterns (API_NAME.googleapis.com/*, www.googleapis.com/API_NAME/*, or *.appspot.com/*) and inject organization-restriction headers (X-Goog-Allowed-Resources or X-GoogApps-Allowed-Domains) without running a custom egress proxy.

Figure 4: Granular control over Google APIs with service patterns in VPC accessible services.

Service Patterns YAML Example (vpc_accessible_services.yaml)

enableRestriction: true
servicePatternsEnforcementScopes:
  - GOOGLE_APIS_VIA_PRIVATE_PATH
allowedServicePatterns:
  - service: 'RESTRICTED-SERVICES'
  - service: 'logging.googleapis.com'
  - pattern: 'maps.googleapis.com/*'
  - pattern: 'appengine.googleapis.com/*'
    modifiers:
      - addRequestHeader:
          key: 'X-Goog-Allowed-Resources'
          value: 'YOUR_BASE64_ORG_RESTRICTION_HEADER'

Apply it to your perimeter:

gcloud access-context-manager perimeters update prod_data_perimeter \
  --set-vpc-accessible-services=vpc_accessible_services.yaml \
  --policy=POLICY_ID

Operational caveats:

• If you are migrating from restricted.googleapis.com to private.googleapis.com, apply the service patterns configuration to the perimeter before switching your DNS and routing to private.googleapis.com.
• addRequestHeader modifiers only attach headers to unsupported services and do not inject headers when the perimeter is only in dry-run mode.

5. Guided Violation Remediation in Violation Analyzer

When a legitimate workload or agent hits a perimeter block, administrators are often pressured to open an overly broad rule just to restore service. Guided Violation Remediation (in Preview inside VPC-SC Violation Analyzer) evaluates a denial’s unique troubleshooting token against your perimeter configuration and generates a least-privilege policy change:

• Ingress violations: Recommends reusing an existing matching Access Level (or creating a scoped new one) and appends an ingress rule pinned to the caller identity, service, method selector, and target resource.
• Egress violations: Proposes a scoped egress rule for the specific caller, external resource, and API method.
• VPC accessible services violations: Suggests adding the blocked service to the perimeter’s allowlist.

Figure 5: VPC-SC Violation Remediation for faster turn-around.

Required IAM roles and limits:

• Viewing recommendations requires roles/accesscontextmanager.policyReader on the access policy and roles/logging.viewer on the projects holding Cloud Audit Logs (within the 30-day default retention window). Applying changes in one click requires roles/accesscontextmanager.editor.
• If caller identities or internal IPs are redacted in audit logs, the engine falls back to broader attributes (such as ANY_USER_ACCOUNT or project numbers), so always review the diff in Dry-Run mode before enforcing.

Pragmatic Rollout Checklist

To deploy these controls safely across your Google Cloud Zero Trust architecture and SAIF AI perimeters:

1. Map perimeters to folders: Group production, development, and agentic AI workloads into dedicated folders and attach dry-run perimeters at the folder level (--perimeter-resources="folders/FOLDER_ID").
2. Collapse project lists in rules: Replace sprawling project arrays in ingress/egress policies with folders/FOLDER_NUMBER and bind private API paths to explicit pscEndpoint forwarding rules.
3. Lock down private.googleapis.com: If workloads require specific unsupported Google APIs over the private VIP, enforce GOOGLE_APIS_VIA_PRIVATE_PATH service patterns with X-Goog-Allowed-Resources headers.
4. Triage denials with Violation Analyzer: Use Guided Violation Remediation to turn dry-run audit log denials into method-scoped ingress/egress rules, then promote the dry-run spec to enforced mode (gcloud access-context-manager perimeters dry-run enforce).

To further enhance your cloud security and implement Zero Trust on Google Cloud, contact me on LinkedIn or [email protected].

Resources

• Google Cloud Blog: Modernizing perimeter security: Scalable perimeters with VPC Service Controls (Pratik Bhangale, October 16, 2026)
• Folder membership docs: Configure folders in service perimeters
• Ingress and egress reference: Ingress and egress rules for VPC Service Controls
• PSC endpoints in VPC-SC: Configure Private Service Connect endpoints in service perimeters
• Service patterns docs: Limit access by using service patterns
• Guided remediation docs: Resolve access denials with remediation suggestions