Blog series: Power Platform Security & Zero Trust — Part 3 of 4
From model to configuration
In the previous blog, we laid out the governance framework: environments as trust boundaries, maker rights via Entra ID, and DLP as a second line of defense. But governance on paper solves nothing. The question is: how do you technically implement it — for apps, flows, and AI agents? Which settings do you change, in what order, and why?
This blog moves from model to configuration. Concrete, layer by layer.
Step 1: Environment strategy in practice
A solid environment strategy is the foundation of everything. Without clear segmentation, DLP is toothless and maker rights are meaningless. The practical breakdown looks like this:
| Environment | Purpose | DLP level | Access | ALM required? |
|---|---|---|---|---|
| Default | Personal productivity | Strict (Microsoft connectors only) | Restricted Entra ID group | No |
| Shared Dev | Development by approved makers | Extended (approved connectors) | Makers via Entra ID | Recommended |
| Department / Team | Department-specific apps, flows, and agents | Aligned to department needs | Per department via Entra ID | Yes |
| Production | Business-critical solutions and published agents | Minimal (only what is needed) | Only via pipeline | Mandatory |
Each environment has its own Entra ID group for Environment Makers. Nobody gets the role assigned at the individual user level. Group membership is managed through identity governance — including access reviews. This applies equally to makers of apps and makers of Copilot Studio agents.
Step 2: Enable Managed Environments
Managed Environments is the enterprise governance layer on top of standard Power Platform. It is the switch that turns an environment into a truly managed and controlled context. Without Managed Environments, you are missing a significant portion of the available security controls — including specific AI governance controls.
What Managed Environments adds:
- Sharing limits: Restricts how many users a canvas app can be shared with
- Solution checker enforcement: Blocks importing solutions that have not passed the solution checker
- Pipeline integration: Mandates the use of deployment pipelines for production
- IP Firewall: Restricts environment access based on IP range
- Generative AI features: Controls which AI capabilities are available in the environment — including Copilot Studio agent publication and access to external knowledge sources
- Customer-managed keys: For organizations with strict data requirements
- Maker welcome message: Directs new makers straight to your governance documentation
Managed Environments are enabled per environment in the Power Platform Admin Center. For production and department environments, this is not optional — it is a requirement.
Step 3: DLP policies layer by layer
DLP works in layers. The outermost layer is the tenant-wide baseline policy — it applies to all environments, always. On top of that come environment-specific policies that permit more or less based on the trust level of each environment.
Tenant-wide baseline policy
The baseline policy is the safety net for everything that has not been explicitly permitted. At a minimum, configure the following:
- Block the HTTP connector and HTTP with Microsoft Entra ID — these are the highest-risk connectors because they allow unrestricted API calls
- Place all consumer connectors (Gmail, Dropbox, Twitter/X, etc.) in the blocked category
- Allow only Microsoft connectors in the Default environment
Custom connectors
Custom connectors are a blind spot in many DLP configurations. By default they fall into the ‘Non-Business’ category, meaning they cannot be combined with business connectors. Make sure custom connectors are explicitly classified and reviewed — and only permitted in environments where they are genuinely needed. The same applies to connectors used by Copilot Studio agents.
Step 4: Enforcing identity and access controls
No personal accounts for automated flows and agents
One of the most common risks: Power Automate flows running under the maker’s personal account. If that person leaves the organization or changes their password, flows stop — or worse, keep running with expired credentials. The same risk applies to Copilot Studio agents configured with personal connections.
In production, always use service principals or service accounts for automated processes and agent connections. Link these to an Entra ID App Registration with the minimum required permissions (least privilege).
Conditional Access for Power Platform
Power Platform supports Conditional Access via Entra ID. Minimum requirements for makers and administrators:
- MFA required for all access to Power Platform
- Compliant device required for access to production environments
- Restrict or block access from unmanaged devices
Step 5: AI governance for Copilot Studio agents
Copilot Studio agents require a dedicated governance layer on top of the general Power Platform controls. The technical configuration includes:
- Publication policy: Define which channels agents may use (internal vs. external, Teams vs. web). Restrict public publication via Managed Environments.
- Knowledge sources: Explicitly control which SharePoint sites, documents, or external sources an agent may query. Use Entra ID groups to segment access to knowledge sources.
- Generative AI features: Use Managed Environments to control which AI capabilities are available per environment — and block them in the Default environment.
- Agent monitoring: Use the CoE Starter Kit and the Power Platform Admin Center to track which agents exist, who built them, and through which channels they are reachable.
Step 6: ALM as a security control
Application Lifecycle Management (ALM) is not just a DevOps best practice — it is a security control. Without ALM, makers can deploy solutions and agents directly to production, bypassing any review or approval process.
With Power Platform Pipelines, you enforce that:
- Every deployment to production — including agents — goes through a controlled process
- The Solution Checker runs automatically on every import
- Environment variables and connections are managed per environment — no hard-coded credentials
- There is an audit trail of who deployed what and when
If a maker can deploy an app or agent directly to production, you do not have governance — you have a policy document.
Checklist: technical configuration at a glance
| Component | Action | Priority |
|---|---|---|
| Environments | Define environment strategy and create environments | High |
| Maker rights | Remove Environment Maker from all users in Default, assign via Entra ID groups | Critical |
| Managed Environments | Enable for all environments outside Default, including AI controls | High |
| DLP baseline | Create tenant-wide policy, block HTTP and consumer connectors | Critical |
| DLP per environment | Configure environment-specific policies based on trust level | High |
| Service principals | Replace personal accounts in production flows and agent connections | High |
| Conditional Access | MFA required, compliant device for production | Critical |
| AI governance | Restrict agent publication channels, control knowledge sources, block generative AI in Default | High |
| ALM Pipelines | Implement deployment pipelines for production environments including agents | High |
➡️ Next in the series — Blog 4: Power Platform – Security Assessment: How mature is your tenant?
With a PowerShell script that automatically checks 10 domains — including AI governance — and generates a clear HTML report.
Leave a Reply