Skip to content

Control 2.1: Managed Environments

Control ID: 2.1
Pillar: Management
Regulatory Reference: FINRA Rule 3110 (Supervision), FINRA Rule 4511 (Books and Records), FINRA Regulatory Notice 24-09 (Gen AI guidance), SEC Rules 17a-3/17a-4 (Recordkeeping), SOX Sections 302/404 (Internal Controls), GLBA 501(b) (Safeguards Rule), OCC Bulletin 2026-13 (formerly OCC Bulletin 2011-12) (Technology Risk Management), Federal Reserve SR 26-2 (formerly SR 11-7) (Model Risk), NYDFS 23 NYCRR 500.06 (Audit Trail), FFIEC IT Examination Handbook (IT Risk Management)
Last UI Verified: May 2026
Governance Levels: Baseline / Recommended / Regulated

Agent 365 Architecture Update

Agent 365 lifecycle management complements Power Platform Managed Environments by providing cross-platform promotion gates and approval workflows. While Managed Environments continue to govern Microsoft Copilot Studio agents, Agent 365 extends lifecycle governance to Agent Builder, Microsoft Foundry, and SharePoint agents. See Unified Agent Governance for lifecycle management architecture.

Objective

Enable premium governance capabilities for Power Platform environments by designating them as Managed Environments, providing enhanced control over sharing, solution deployment, usage monitoring, and maker onboarding essential for financial services governance.

Why This Matters for FSI

  • FINRA 4511, FINRA RN 24-09 / Rule 3110: Usage insights and activity logs help support books-and-records evidence collection. Managed Environments alone do not satisfy 4511 — pair with retention (Control 1.7) and Purview audit (Control 3.1).
  • SEC 17a-3 (record creation): Solution checker enforcement helps establish change-control evidence for systems that create regulated records. (SEC 17a-4 is the WORM-preservation requirement and is addressed by Control 1.7 retention policies, not by Managed Environments.)
  • GLBA 501(b): Sharing limits and Tenant Isolation help reduce the surface area for unauthorized access to customer information.
  • SOX 302 / SOX 404: Maker welcome content and access reviews aid in documenting policy acknowledgment and access governance for internal controls over financial reporting.
  • Federal Reserve SR 26-2 (formerly SR 11-7) (model risk): Solution checker, sharing limits, and access reviews contribute to the change-control and access-governance pieces of a model-risk framework.

Non-substitution — technical guardrails are not governance

Managed Environments provide technical guardrails (sharing limits, solution-checker enforcement, IP firewall, usage insights). They do not replace:

  • Model-risk governance committee oversight required by OCC Bulletin 2026-13 (formerly OCC Bulletin 2011-12) / Federal Reserve SR 26-2 (formerly SR 11-7) — see Control 2.6. A Managed Environment toggle is not an independent model validation.
  • Supervisory review by an appropriately registered principal required by FINRA Rule 3110 — see Control 2.12. Solution-checker enforcement is not a Series-24 sign-off.
  • Books-and-records retention required by FINRA 4511 / SEC 17a-4 — see Control 1.7 and Control 3.1. The weekly digest is operational telemetry, not a regulated record.
  • Written Supervisory Procedures documenting who reviews what, when, and how. Examiners will hold the firm to its own WSPs.

Treat Managed Environments as the enforcement substrate that makes the human-and-process controls above operable and auditable.

Automation Available

Companion solutions in FSI-AgentGov-Solutions:

Prerequisites

Licensing Requirements

Managed Environments require Power Platform Premium capacity or equivalent licensing. Verify the following before implementation:

  • Managed Environment activation: Requires Power Apps, Power Automate, or Copilot Studio premium licenses, OR Dynamics 365 licenses, OR Power Platform per-app/per-user plans with premium entitlements
  • Advanced security features (IP Firewall, VNet, CMK, Lockbox): Require additional licensing beyond Managed Environment designation
  • Usage insights: Included with Managed Environment; no additional license required
  • Solution checker enforcement: Included with Managed Environment; no additional license required

Consult Microsoft Learn: Licensing overview for current licensing requirements.

Pay-As-You-Go Does NOT Satisfy Managed Environment Licensing

Enabling pay-as-you-go for a Managed Environment is NOT sufficient to meet licensing requirements if:

  • Users without standalone Power Apps licenses are using Power Apps in that environment, OR
  • Users without standalone Power Automate licenses are using flows in that environment

Pay-as-you-go billing alone does not satisfy Managed Environment licensing where users otherwise lack qualifying entitlement. Each active user needs a qualifying premium per-user entitlement, or the environment must have applicable capacity-based license rights. Administrators should also review Managed Environment license-consumption reports (PPAC > Resources > License consumption) and Microsoft's 2026 compliance notifications.

Enforcement timeline (June 2026): Microsoft begins user-facing in-app notifications for unlicensed users in Managed Environments and admin alerts in PPAC + Message Center starting June 2026. Run a license-coverage audit before June 2026 to avoid maker-facing disruption.

Source: Microsoft Learn: Managed Environments Licensing

Pipeline Targets and Managed Environments

Pipeline target environments — verify current Microsoft guidance before relying on auto-enablement

The Power Platform Pipelines feature has historically required (or strongly recommended) that pipeline target environments be Managed Environments. Microsoft has indicated tightening of this expectation through 2026, but the exact mechanism (admin opt-in vs auto-enable) and date have shifted in successive Learn updates.

Verified action regardless of Microsoft's enforcement timing:

  1. Audit all pipeline target environments in your tenant.
  2. Verify premium-licensing coverage for each target environment (Learn — Managed Environment Licensing).
  3. Proactively enable Managed Environment status on all pipeline targets so you control timing and evidence collection.
  4. Use Pipeline Governance Cleanup to discover and remediate personal pipelines.

Sources to re-check before quoting a date:

Control Description

Managed Environments provide premium governance capabilities for Power Platform environments, enabling centralized control over sharing, solution deployment, usage insights, and maker onboarding. When enabled, administrators gain access to governance capabilities including sharing controls, solution checker enforcement, usage insights, maker welcome content, and cross-tenant restrictions. Advanced security features such as IP Firewall, VNet support, Customer Managed Keys, and Lockbox require separate licensing and configuration beyond the Managed Environment designation.

For FSI organizations, Managed Environments are essential for enforcing governance policies at the environment level. The feature enables a "sterile default" strategy where all non-personal environments operate under controlled sharing, monitored usage, and enforced deployment gates.

Key capabilities particularly relevant for regulated financial services include:

  • Manage sharing - Limit how widely apps, flows, and agents can be shared
  • Solution checker enforcement - Block/warn on solution imports with security issues
  • Usage insights - Weekly digest of top apps and flows for compliance monitoring
  • Maker welcome content - Custom onboarding guidance communicating policy requirements
  • Cross-tenant restrictions - Control connector access across tenant boundaries

Customer Lockbox & Data Residency Posture

Sub-control scope. This sub-section consolidates the Customer Lockbox (CL) and data-residency posture for tenants running Microsoft 365 AI agents and Power Platform workloads. It is intentionally implemented as an extension of Control 2.1 rather than a standalone control because Lockbox approval workflow, Multi-Geo placement, and Power Platform CMK / VNet posture all sit on top of the Managed Environment substrate. Cross-references in Controls 1.5, 1.6, 1.13, 1.15, and 3.7 point back here.

Customer Lockbox — what it gates. Customer Lockbox provides an in-tenant approval workflow for Microsoft engineer access to customer data. When a Microsoft support engineer needs to access tenant content to resolve a service request, the Lockbox approver receives an email request that must be approved or denied within a fixed window before access is granted. Lockbox is available for Microsoft 365 (Exchange Online, SharePoint Online, OneDrive for Business, Teams), Power Platform (Dataverse data plane), and selected Azure services (Storage, SQL Database, VMs). Coverage is per-service — verify against Microsoft Learn — Customer Lockbox supported services before asserting Lockbox coverage for a workload.

Agent 365 audit-logging path is NOT covered by Customer Lockbox

Microsoft engineer access to the Agent 365 audit-logging plane (the back-end pipeline that ingests Agent 365 activity events into the unified audit log) is not gated by Customer Lockbox as of GA. Microsoft can access the audit-logging metadata for service-operations and abuse-investigation purposes without an in-tenant Lockbox approval. This is a known gap that customers must document in their Written Supervisory Procedures and vendor-risk register.

Compensating controls:

  • Treat Agent 365 audit-event payloads as service-operations metadata rather than fully customer-controlled records. Where examiners require evidence of who-saw-what, supplement Agent 365 audit data with Control 1.7 Purview Audit (Premium) records and Control 3.9 Sentinel ingestion, both of which surface Lockbox-gated underlying data plane events.
  • Disclose this Lockbox-coverage gap in the firm's Control 2.7 vendor-risk file and the cloud-provider attestation pack pulled from the Service Trust Portal Attestation Guide.
  • Re-verify the Lockbox coverage matrix at each Microsoft service-update cycle; Microsoft has signalled progressive expansion of Lockbox coverage post-GA but no firm date is available.

Data residency — where customer content sits. Three independent residency surfaces affect AI agent grounding sources:

  1. Microsoft 365 Multi-Geo. A licensed feature that allows a single Microsoft 365 tenant to store user mailbox, OneDrive, and SharePoint data in multiple geographies (Geos) under a single tenancy. Required where business units operate under different regional regulators (e.g., a US tenant with EU subsidiary mailbox/OneDrive content pinned to the EU Geo for GDPR reasons). Configure via PPAC + Microsoft 365 Admin Center with the Multi-Geo Capabilities add-on.
  2. Azure regional pinning (for Power Platform / Dataverse). Each Power Platform environment is created in a single Azure region; the Dataverse data, Customer Key vaults, and most stateful Power Platform services remain in that region. Use Environment Routing (Section 4 above) to direct new environments into the correct regional bucket per business-unit residency rules.
  3. EU Data Boundary (EUDB). Microsoft's commitment to store and process customer data and personal identifying data for EU/EFTA customers within the EU Data Boundary, including Microsoft 365, Dynamics 365, Power Platform, and most Azure services. As of January 2025, EUDB Phase 3 covers Professional Services data and most service-generated logs. EUDB is the right answer for FSI subsidiaries operating in EU member states; for US-only tenants it is not directly applicable, but the EUDB documentation is the authoritative source for Microsoft's residency commitments and incident-notification posture.

FSI implications.

  • GLBA 501(b) (Safeguards Rule). Customer Lockbox helps support the "administrative safeguards" element of 501(b) by giving the firm a documented, in-tenant approval point for any Microsoft engineer access to non-public customer information. The Lockbox approval/denial record (M365 Admin Center → Customer Lockbox history) is retained as part of the firm's vendor-access evidence pack. Lockbox alone does not satisfy 501(b) — pair with Control 1.7, Control 2.7, and the firm's written information security program.
  • FINRA Rule 4511 (Books and Records) record-residency. FINRA does not currently mandate a specific geographic residency for electronic records, but firms with multi-jurisdictional operations must be able to produce records on demand in the jurisdictions in which they operate. Multi-Geo and Azure regional pinning aid in establishing that the firm can satisfy a non-US regulator's records-production request without breaching local data-export rules. Document the residency mapping in the records-retention schedule that accompanies Control 1.7.
  • NYDFS 23 NYCRR 500.05 / 500.06 (Penetration Testing & Audit Trail). New York-licensed firms must maintain audit trails of access to non-public information. Lockbox approval evidence is a required input to the firm's 500.06 audit-trail evidence pack. Where Agent 365 audit-logging is in scope, document the Lockbox-coverage gap above as a compensating-control note in the 500.06 audit narrative.
  • State-level AI / privacy laws. Several US state AI laws (Colorado SB24-205, Texas TRAIGA, NYC LL144) and consumer-privacy laws (CCPA/CPRA, VCDPA) include vendor-access disclosure and data-localization elements that can be partially evidenced by Lockbox approvals and Multi-Geo placement. Map specific obligations against the residency posture in the firm's privacy-impact assessment.

Key Configuration Points

Managed Environment Settings

  • Enable Managed Environment status for all non-personal environments
  • Configure sharing limits per resource type (Power Apps, Power Automate, Copilot Studio)
  • Set solution checker enforcement level: None (Zone 1), Warn (Zone 2), Block (Zone 3)
  • Enable usage insights with Compliance team as additional recipients
  • Configure maker welcome content with governance policy summary and policy links
  • Apply cross-tenant restrictions (disable inbound/outbound for regulated environments)
  • Configure the IP Firewall (Zone 3) to restrict access to Power Platform services from allow-listed CIDR ranges
  • Configure IP cookie binding (Zone 3) to bind user sessions to source IP, reducing session-token-replay risk
  • Configure Customer-Managed Keys (CMK) for environments that hold regulated data, where your KMS posture requires it (additional licensing applies)
  • Enable Customer Lockbox for in-tenant approval of any Microsoft engineer access to environment data (additional licensing applies)

Customer Lockbox Enablement (per Sub-Control above)

  • M365 tenant surface: M365 Admin Center → Settings → Org settings → Security & privacy → Customer Lockbox → toggle Require approval for all data access requests to On and assign the Customer Lockbox access approver role group to the named approvers (minimum two named individuals + one role mailbox; treat as a privileged role, segregated from day-to-day administration).
  • Power Platform surface: PPAC → Tenant Settings → confirm Customer Lockbox is enabled for Power Platform (per-environment scope where supported). The Power Platform Lockbox toggle is independent from the M365 toggle — both must be on for Dataverse data-plane Lockbox coverage.
  • Azure surface: For Azure-resident workloads (Azure Storage hosting agent grounding sources, Azure SQL evaluation databases), enable Customer Lockbox in the Azure portal under each subscription's Customer Lockbox blade and assign approvers per subscription.
  • Approver hardening: Enforce phishing-resistant MFA on every approver account (Authenticator + FIDO2 minimum), require Conditional Access named-location restrictions on Lockbox approval mailbox sign-in, and route Lockbox-decision audit events into Sentinel (Control 3.9) for SOC visibility.
  • Quarterly Lockbox-path test: Coordinate with the Microsoft FastTrack / CSAM contact to initiate a benign Lockbox test request each quarter; capture the approval evidence and retain in the privileged-access governance pack. Document approver-rotation cadence in the firm's Written Supervisory Procedures.

Data Residency Configuration (per Sub-Control above)

  • Microsoft 365 Multi-Geo: Enable the Multi-Geo add-on (separate license SKU) and assign each user to the appropriate PreferredDataLocation (PDL) at the time of license assignment. Verify Multi-Geo placement via Microsoft 365 Admin Center → Setup → Multi-Geo Capabilities and per-user via Get-MgUser -UserId <UPN> -Property PreferredDataLocation | Select PreferredDataLocation (Microsoft Graph PowerShell; the MSOnline module is retired). Document PDL assignment rules in the firm's data-residency policy and re-verify annually.
  • Azure / Power Platform regional pinning: Use Environment Routing to direct new environments into the Azure region(s) that align with the firm's residency rules. For environments holding regulated content, pin Customer Key vaults (Control 1.15) to the same region (and a paired region for redundancy) — cross-region key custody complicates regulator records-production scenarios.
  • EU Data Boundary applicability: Where the firm has EU/EFTA subsidiaries or processes EU customer data, document EU Data Boundary applicability per Microsoft's published EU Data Boundary commitment and map the in-scope Microsoft services to the firm's GDPR records-of-processing inventory.
  • Residency exception register: Maintain an exception register for any agent grounding source, Copilot Studio environment, or Power Platform connector that does not align with the firm's primary residency rules. Each exception must carry a documented business rationale, a compensating control, and an annual re-validation date.

Environment Provisioning Governance

  • Restrict environment creation to authorized admins: In Power Platform Admin Center > Tenant Settings, configure the following to "Only specific admins" for each environment type:

    • Developer environment assignments
    • Production environment assignments
    • Trial environment assignments

    This prevents uncontrolled environment sprawl where trial or developer environments may expose sensitive data or bypass compliance controls

  • Configure environment routing: In PPAC > Tenant Settings > Environment Routing, configure routing rules to ensure new environments are created in the correct region aligned with data residency requirements and organizational governance policies. This supports compliance with data locality regulations and optimizes resource management

  • Enable tenant isolation: In PPAC > Security > Identity and access > Tenant Isolation, enable "Restrict Cross-Tenant Connections" to prevent data from moving into or out of the tenant via Power Platform connectors. Configure explicit exceptions (by Tenant ID and direction) only for trusted partner tenants. Unrestricted cross-tenant connectivity increases risk of unintended data exchange and regulatory non-compliance

  • Configure environment security groups: In PPAC > Security > Identity and access > Environment Security Groups, assign a security group to each environment to control user access. Without security groups, environment access may default to broad access, increasing risk of unauthorized access to sensitive data and applications

Zone-Specific Requirements

Zone Requirement Rationale
Zone 1 (Personal) Apply baseline minimum; document exceptions for personal agents; environment creation restricted to admins Reduces risk from personal use while keeping friction low
Zone 2 (Team) Enable managed environment governance; require identified owner and approval trail; security groups required; tenant isolation enabled Shared agents increase blast radius; controls must be consistently applied
Zone 3 (Enterprise) Require strictest configuration enforced via policy; treat changes as controlled; security groups required; tenant isolation enforced; environment routing configured for data residency compliance Enterprise agents handle most sensitive content and highest regulatory risk

Roles & Responsibilities

Role Responsibility
Power Platform Admin (or Dynamics 365 Admin) Only these tenant-level roles can enable / edit Managed Environments per Learn — Permissions. Configure environment settings, sharing limits, IP Firewall, CMK
Environment Admin Environment-level user management; cannot change Managed Environments property
Delegated Admin Delegated administration; cannot change Managed Environments property
Compliance Officer Reviews usage insights; approves governance zone classifications; receives weekly digest
IT Governance Defines sharing-limit policy, solution-checker enforcement level, IP-allow-list standards
AI Governance Lead Configures agent-specific sharing settings within managed environments
Control Relationship
1.20 - Network Isolation VNet support implementation for private connectivity
2.2 - Environment Groups Group-level governance rules that complement environment settings
2.15 - Environment Routing Automatic maker placement into governed environments
1.4 - Advanced Connector Policies Data policies enforced within managed environments
2.3 - Change Management Solution deployment controls using solution checker
2.22 - Inactivity Timeout Enforcement Inactivity timeout policies operate within managed environment framework
1.5 - DLP and Sensitivity Labels Sensitivity-label-driven encryption is the only supported AI-app encryption path; Lockbox/CL caveats interact with label-based DLP for Copilot
1.6 - DSPM for AI Agent 365 audit-logging Lockbox-coverage gap (see Customer Lockbox & Data Residency Posture sub-section) affects DSPM for AI evidence narrative
1.13 - Sensitive Information Types SITs that detect NPI/MNPI inherit the residency posture configured here
1.15 - Encryption (Data in Transit / at Rest) Customer Key vaults must be regionally co-located with the Power Platform environment per the data-residency configuration here
3.7 - PPAC Security Posture Assessment Lockbox approval evidence and audit-logging-coverage gaps surface in the PPAC security-posture review pack

Implementation Playbooks

Step-by-Step Implementation

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

Advanced Implementation: Configuration Hardening Baseline

This control is covered by the Configuration Hardening Baseline, which consolidates SSPM-detectable settings across all 7 mapped controls into a single reviewable checklist with automation classification and evidence export procedures.

Verification Criteria

Confirm control effectiveness by verifying:

  1. Managed Environment status shows enabled in PPAC environment details
  2. Sharing limits block attempts to share beyond configured thresholds (test with non-admin user)
  3. Solution checker blocks non-compliant solution imports (if Block mode enabled)
  4. Weekly usage insights digest arrives at configured recipient addresses
  5. Maker welcome content displays for new users accessing the environment
  6. Environment creation is restricted to authorized admins only (PPAC > Tenant Settings > verify "Only specific admins" is set for Developer, Production, and Trial environment assignments)
  7. Environment routing is configured for correct region (PPAC > Tenant Settings > Environment Routing)
  8. Tenant isolation is enabled (PPAC > Security > Identity and access > Tenant Isolation > "Restrict Cross-Tenant Connections" is on)
  9. Security groups are assigned to all Zone 2/3 environments (PPAC > Environment details > Security group)
  10. License-entitlement coverage verified for every active maker (PPAC > Resources > License consumption)
  11. IP Firewall allow-list reviewed against current corporate egress ranges (Zone 3)
  12. Inactive-environment / quarantine notifications routed to the governance distribution list

Additional Resources

Advanced Implementation: Environment Lifecycle Management

For automated environment provisioning with Managed Environment status enabled from creation, see Environment Lifecycle Management.

Deployable Solution: environment-lifecycle-management provides Python automation scripts for Dataverse schema creation, security roles, and evidence export.

Agent 365 Blueprint Lifecycle (Preview)

Agent 365 GA — May 2026

Microsoft Agent 365 reached general availability on May 1, 2026 (bundled in Microsoft 365 E7 or available as a standalone Microsoft Agent 365 per-user license). Agent Essentials category definitions and SDK feature scope continue to mature post-GA — verify current feature availability against Microsoft Learn before implementing production controls dependent on specific Agent 365 capabilities.

Agent 365 Blueprints introduce 3-phase lifecycle management that aligns with Managed Environment promotion paths:

  • Phase 1: Design - Define agent requirements and governance zone
  • Phase 2: Build - Develop in development Managed Environment

  • Phase 3: Deploy - Promote to production Managed Environment via Blueprint registration

  • Microsoft Learn: Agent 365 Blueprint (Preview) - 3-phase deployment framework

Implementation Note

Organizations should verify that their implementation meets their specific regulatory obligations. This control supports compliance efforts but requires proper configuration and ongoing validation.

Updated: May 2026 | Version: v1.6.2 | UI Verification Status: Current