Skip to content

Control 2.15: Environment Routing and Auto-Provisioning

Control ID: 2.15
Pillar: Management
Regulatory Reference: OCC 2011-12, FINRA 3110, FINRA 25-07, GLBA 501(b), SOX 302/404
Last UI Verified: April 2026
Governance Levels: Baseline / Recommended / Regulated

Objective

Configure Power Platform environment routing so that new and existing makers are automatically directed into personal developer environments inside a governed environment group, helping reduce ungoverned "shadow AI" creation in the tenant's default environment.

Why This Matters for FSI

  • OCC 2011-12: Routes makers to governed environments for operational risk management
  • FINRA 3110, FINRA 25-07: Enforces routing rules based on role/group membership for supervision
  • GLBA 501(b): Directs makers to environments with proper data policies for customer protection
  • SOX 302/404: Provides audit trail of routing decisions for internal controls

Automation Available

See Environment Lifecycle Management in FSI-AgentGov-Solutions for automated Power Platform environment provisioning with zone-based governance.

Control Description

Environment routing is a tenant-level Power Platform governance setting (Premium / Managed Environments). When enabled, makers visiting Copilot Studio, Power Apps, or Power Automate (cloud and desktop) are auto-provisioned into a personal developer environment that is attached to an admin-defined environment group. The group's published rules (sharing limits, AI features, ALM, data retention) are then enforced on that personal environment.

This control combines four elements:

  1. Product Scope — Turn routing on for the maker portals you want to govern: Copilot Studio, Power Apps, Power Automate (cloud), and Power Automate for desktop. Power Pages is not currently in scope.
  2. Routing Rules (PPAC → Manage → Tenant settings → Environment routing) — Each rule maps either Everyone or a specific Microsoft Entra security group to a target environment group. Rules are evaluated top-down; the first matching rule wins.
  3. Target Environment Group(s) — The destination groups are created separately (PPAC → Manage → Environment groups) and carry the policy rules that govern routed personal dev environments. Groups can only contain Managed Environments.
  4. Default Environment Hygiene — Routing does not restrict access to the default environment; makers can still switch to it. Pair this control with default-environment cleanup, DLP (Control 1.4), and publisher restrictions (Control 1.1) to actually contain shadow AI.

Important constraint: Routing always provisions personal developer environments owned by the maker. It does not route makers into shared production environments. For shared/production placement, use access control on those environments directly.

Key Configuration Points

  • Configure routing in PPAC → Manage → Tenant settings → Environment routing (not under Environment groups → Rules — those are policy rules, not routing rules).
  • Enable routing for each product portal in scope: Power Apps, Power Automate (cloud and desktop), Copilot Studio.
  • Create one or more target environment groups in advance, all populated with Managed Environments and configured with the policy rules (sharing limits, AI features, ALM, retention) that should be inherited by routed personal dev environments.
  • Define routing rules using either Everyone or specific Microsoft Entra security groups. Order rules from most specific to least specific; the first match wins.
  • Decide whether routing applies to all makers (new and existing) or new makers only (environmentRoutingAllMakers flag); document the choice in your supervisory procedures.
  • Track the default environment with a recurring inventory job (Control 2.16 / 3.x reporting) — routing does not block the default environment, it only changes the maker's initial landing target.
  • Capture the published configuration as immutable evidence (PPAC export + Get-TenantSettings JSON with SHA-256) per SEC 17a-4(f) record-keeping expectations.

Zone-Specific Requirements

Zone Requirement Rationale
Zone 1 (Personal) Routing enabled for all makers; single "Everyone" rule targeting a Personal-Productivity environment group with sharing limits and DLP applied Gives every maker a Managed personal dev env instead of dropping work into the default environment
Zone 2 (Team) Multiple routing rules keyed to LOB security groups; each LOB group targets its own env group with stricter sharing/AI rules; documented rule order and approval Shared agents warrant controlled placement aligned to business unit
Zone 3 (Enterprise) Routing enabled with security-group rules, formal change control, exported evidence, and supervisory review of rule changes per FINRA 3110 / 25-07; default environment quarantined via DLP and access reviews Regulated workloads require auditable routing decisions and zero tolerance for unmanaged maker activity

Roles & Responsibilities

Role Responsibility
Power Platform Admin Enable environment routing, author and prioritize routing rules, own target environment groups
Environment Admin Operate routed environments; surface anomalies to Power Platform Admin
Entra Security Admin Maintain the security groups referenced by routing rules; approve membership changes
Compliance Officer Approve routing policy, review evidence exports, attest configuration during supervisory review
Control Relationship
2.1 - Managed Environments Routed environments should be managed
2.2 - Environment Groups Routing targets environment groups
1.1 - Restrict Agent Publishing Complements routing with publishing controls
1.4 - Advanced Connector Policies DLP policies apply in routed environments

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. Get-TenantSettings returns powerPlatform.governance.enableDefaultEnvironmentRouting = True and product scope matches policy.
  2. PPAC → Tenant settings → Environment routing lists routing rules in the documented order; each rule targets a Managed environment group.
  3. A test user signing in to Copilot Studio is auto-provisioned into the expected environment group (capture environment ID + group ID).
  4. Each target environment group has its policy rules published (not draft); routed dev environments inherit them.
  5. A user not matching any specific security group rule is routed by the catch-all "Everyone" rule (or, if absent, lands in the default environment — flag as gap).
  6. Evidence package contains SHA-256 manifest of Get-TenantSettings JSON and PPAC screenshots dated within the supervisory review window.

Additional Resources

Advanced Implementation: Environment Lifecycle Management

For conversational intake that routes environment requests to appropriate zones with automated classification, see Environment Lifecycle Management.

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