Skip to content

Control 1.20: Network Isolation and Private Connectivity

Control ID: 1.20
Pillar: Security
Regulatory Reference: FINRA Rule 3110, FINRA Regulatory Notice 25-07, SEC Rule 17a-4, GLBA 501(b) Safeguards Rule, OCC Bulletin 2011-12, Federal Reserve SR 11-7, NIST SP 800-53 Rev. 5 SC-7 (Boundary Protection), NIST SP 800-53 Rev. 5 SC-7(11) (Restrict Incoming Communications)
Last UI Verified: April 2026
Governance Levels: Baseline / Recommended / Regulated

Objective

Establish network-layer boundary protection for Power Platform and Copilot Studio environments so that agent traffic to data sources, secret stores, and telemetry sinks is constrained to trusted network paths. The control combines IP firewall, IP-address-based cookie binding, virtual network (VNet) integration via subnet delegation, and Azure Private Link / Private Endpoints for the resources agents call (Key Vault, Application Insights, Azure SQL, Storage). Together these reduce the public attack surface, support segregation of customer data flows, and produce reviewable network evidence for supervisory and audit obligations.

Why This Matters for FSI

  • FINRA Rule 3110 (Supervision): Restricting agent network egress to known network paths supports the firm's supervisory system by making agent activity reviewable from network logs and reducing the population of unmanaged data exfiltration paths a supervisor would otherwise have to evaluate.
  • FINRA Regulatory Notice 25-07 (AI guidance, March 2025): Calls out cybersecurity controls specific to AI tools, including limiting where AI systems can send and receive data. IP firewall, VNet integration, and private endpoints help meet that expectation by removing AI-driven lateral movement paths.
  • SEC Rule 17a-4 (Recordkeeping): When required electronic records and the systems that produce them traverse private network paths, the integrity of recordkeeping flows is easier to demonstrate and the population of network-borne tampering vectors is reduced.
  • GLBA 501(b) Safeguards Rule: Network boundary protection is a recognized administrative and technical safeguard for nonpublic personal information; private connectivity to Key Vault and data services helps support the Safeguards Rule's requirements for protecting customer information.
  • OCC Bulletin 2011-12 / Federal Reserve SR 11-7 (Model Risk Management): Documenting and constraining the network paths a model can use is part of validating the data feeds and operational environment of the model. Private endpoints and VNet evidence support that documentation.
  • NIST SP 800-53 Rev. 5 SC-7 (Boundary Protection): Implements managed interfaces at external boundaries and key internal boundaries through IP firewall and Private Link; SC-7(11) is supported by allowlist-based ingress.

Important caveat. Network isolation is one layer of defense. It does not replace identity, conditional access (Control 1.11), DLP (Pillar 1), encryption (Control 1.15), or audit logging (Control 1.7). Effectiveness depends on accurate IP allowlists, sound DNS configuration, and disciplined change management.

No Companion Automation Solution

No companion automation solution is currently published for this control. Use the PowerShell setup playbook for orchestration patterns, and see the Solutions Index for the broader catalog.

Control Description

This control combines five Microsoft-native network boundary mechanisms:

  1. IP Firewall (Power Platform Managed Environments) — Restrict Dataverse and Power Platform service access to allowlisted IPv4/IPv6 ranges (up to 200 ranges, 4,000 characters in the address field). Available for Managed Environments and supported in Commercial, GCC, GCC High, and DoD clouds.
  2. IP-Address-Based Cookie Binding — When enabled in a Managed Environment, Dataverse session cookies are bound to the originating client IP. A stolen or replayed cookie used from a different IP is rejected, mitigating session hijacking. Reverse proxy headers can be configured for environments that terminate TLS at a proxy.
  3. Virtual Network (VNet) Integration via Subnet Delegation — A Managed Environment is associated with one or more Azure subnets delegated to Microsoft.PowerPlatform/enterprisePolicies. Outbound calls from Dataverse plug-ins, custom connectors, Power Automate flows, and Copilot Studio agents are injected into the customer's VNet. Subnets must reside in the Azure region paired with the Power Platform region (primary and failover) and be appropriately sized (Microsoft guidance for production: a /24 per region).
  4. Azure Private Link / Private Endpoints for Dependencies — Key Vault, Storage, Azure SQL, and Application Insights (via an Azure Monitor Private Link Scope, AMPLS) are exposed only through private endpoints on the same VNet as the delegated subnet. Public network access is disabled on those resources.
  5. Private DNS — Azure Private DNS zones are linked to the VNet so that PaaS FQDNs (e.g., *.vault.azure.net, *.database.windows.net) resolve to private IPs and not to public endpoints.

Together, these mechanisms remove agent traffic from the public internet for the in-scope resources, produce auditable network configuration that can be presented during examinations, and reduce the population of exfiltration paths an adversary or compromised agent could use.

Key Configuration Points

  • Power Platform environment is a Managed Environment (prerequisite for IP firewall, cookie binding, and VNet support).
  • IP Firewall configured under PPAC → Environment → Settings → Privacy + Security → IP firewall with corporate egress CIDRs (proxy / VPN egress IPs, not user RFC1918 ranges unless they actually egress directly).
  • IP Firewall mode set to Audit only during rollout, then switched to Enforce after at least one full business cycle of audit review.
  • IP-address-based cookie binding enabled under the same blade; reverse-proxy IPs and forwarded-for headers configured if applicable.
  • Azure VNet provisioned in the Azure region paired to the Power Platform region (and the failover region) with a subnet delegated to Microsoft.PowerPlatform/enterprisePolicies (recommended /24).
  • Power Platform enterprise policy (network policy) created and linked to the environment via New-PowerAppEnvironmentEnterprisePolicy / New-AdminPowerAppEnvironmentEnterprisePolicy.
  • Private Endpoints created for Key Vault, Storage, Azure SQL, and any other dependency the agent calls; public network access disabled on those resources.
  • AMPLS created and linked to the VNet for Application Insights / Log Analytics private telemetry.
  • Private DNS zones (privatelink.vaultcore.azure.net, privatelink.database.windows.net, privatelink.monitor.azure.com, etc.) linked to the VNet.
  • Network change-control documented in the change record, including a network architecture diagram that names the agents, the delegated subnet, the private endpoints, and the data sources reached.

Zone-Specific Requirements

Zone Requirement Rationale
Zone 1 (Personal Productivity) IP firewall and VNet not required. Default tenant boundary applies. Document this in the zone profile. Personal-productivity agents should not access regulated nonpublic data; cost and complexity of VNet are unjustified. Compensating controls live in identity (Conditional Access) and DLP.
Zone 2 (Team Collaboration) IP firewall enabled (Enforce) with documented allowlists. Cookie binding enabled (with proxy header config if applicable). VNet integration recommended when team agents call Azure-hosted dependencies (Key Vault, Storage, Azure SQL). Private endpoints required for any dependency holding customer or regulated data. Team agents commonly aggregate departmental data; restricting the network surface limits blast radius from credential or session compromise and supports FINRA 3110 supervision evidence.
Zone 3 (Enterprise Managed) Full VNet integration mandatory with delegated subnets in primary and failover Azure regions. Public network access disabled on all dependent resources. Private Endpoints required for Key Vault, Storage, Azure SQL, and Application Insights (via AMPLS). NSG flow logs and Azure Network Watcher / Traffic Analytics enabled. IP firewall Enforce mode with reverse-proxy header validation. Quarterly attestation of network configuration. Customer-facing agents handling NPI / PII require defense in depth: VNet plus Private Link plus DNS hygiene plus flow logging produce the network evidence regulators expect under SR 11-7 and OCC 2011-12, and align with the AI-specific cybersecurity expectations in FINRA 25-07.

Roles & Responsibilities

Role Responsibility
Power Platform Admin Configures IP firewall, cookie binding, and links the environment to the Power Platform enterprise (network) policy.
Entra Security Admin Reviews network architecture and reconciles IP firewall allowlists with conditional access named locations (Control 1.11). Approves changes prior to Enforce.
AI Administrator Coordinates Copilot Studio agent inventory affected by network changes; ensures agents in Zone 2/3 are deployed only into network-isolated environments.
Compliance Officer Approves the network architecture against the firm's regulatory mapping; records evidence in the supervisory file.

Azure VNet, subnet, private endpoint, AMPLS, NSG, and Private DNS configuration is performed by the Azure platform team (typically holding Network Contributor on the relevant resource group). That team is not a directory role in the canonical role catalog but is the operational owner of the Azure-side artifacts referenced above.

Control Relationship
2.1 - Managed Environments Prerequisite — IP firewall, cookie binding, and VNet support require a Managed Environment.
1.15 - Encryption (in transit and at rest) Network isolation plus encryption produces defense in depth; private endpoints do not remove the need for TLS.
1.7 - Comprehensive Audit Logging NSG flow logs and Private Link diagnostic logs supplement Purview audit for network-layer evidence.
1.11 - Conditional Access and Phishing-Resistant MFA IP firewall allowlists should reconcile with Conditional Access named locations to avoid contradictory enforcement.
1.6 - Microsoft Purview DSPM for AI Private endpoints constrain where DSPM-monitored agent data can flow.

Implementation Playbooks

Step-by-Step Implementation

This control has detailed playbooks for implementation, automation, testing, and troubleshooting:

Verification Criteria

Confirm control effectiveness by verifying:

  1. IP firewall Enforce mode rejects connections from a non-allowlisted IP for an in-scope environment, returning HTTP 403 with IPFirewallBlockedRequest (or the equivalent error visible in the Dataverse Web API response).
  2. Cookie binding rejects a session cookie replayed from a different client IP (verified in a controlled test against a non-production environment).
  3. Subnet delegation is present on the configured subnet (Microsoft.PowerPlatform/enterprisePolicies) and the enterprise policy is linked to the Managed Environment (visible in PPAC and via PowerShell).
  4. Private DNS within the VNet resolves dependency FQDNs to private IPs (e.g., nslookup myvault.vault.azure.net returns a 10.x.x.x address).
  5. Public network access is disabled on Key Vault, Storage, Azure SQL, and AMPLS-scoped Application Insights / Log Analytics workspaces in scope.
  6. Diagnostic evidence — NSG flow logs / Traffic Analytics show agent egress traversing the delegated subnet, and Key Vault diagnostic logs show requests originating from the private endpoint NIC.
  7. Change record for the environment includes a current network architecture diagram and a reviewer sign-off within the last quarter (Zone 3) or six months (Zone 2).

Additional Resources

Updated: April 2026 | Version: v1.4.0 | UI Verification Status: Current