Blog series: Power Platform Security & Zero Trust — Part 2 of 4
Most organizations have no governance. Or only halfway there.
A DLP policy here, a handful of environments there, but no coherent model. The Default environment is used for experiments and business-critical processes alike. Maker rights have been assigned to everyone with a license. And nobody knows exactly what is running — including which AI agents have been built and who can reach them.
Zero Trust demands explicitness. Everything that has not been deliberately configured is a gap. This blog lays out the governance framework that serves as the foundation for everything that follows.
Where do you stand? The Power Platform Maturity Model
Before you start configuring, it helps to know where you are today. Microsoft has developed the Power Platform Adoption Maturity Model for exactly this purpose. It classifies organizations into five maturity levels (100 through 500) based on their security posture.
| Level | Characteristics |
|---|---|
| 100 — Initial | Basic authentication via Entra ID, no DLP policies, no monitoring |
| 200 — Repeatable | Default environment covered by DLP, tenant isolation configured |
| 300 — Defined | DLP strategy across all environments, Conditional Access for admins, security score tracked |
| 400 — Capable | Advanced Entra ID features (PIM, CAE), clear environment strategy with RBAC, Sentinel integration |
| 500 — Efficient | Mature identity governance, Microsoft Purview for data classification, proactive threat detection |
Most organizations without explicit governance sit at level 100 or 200. The goal of this blog series is to get you to level 300 or higher. In Blog 4, you can use the assessment script to objectively measure where you stand.
Power Platform is not exempt from Zero Trust
Within the Zero Trust model, trust is never implicit. Access is continuously evaluated based on identity, context, and risk. This principle applies equally to Power Platform.
Power Apps and Power Automate are fully-fledged application and integration platforms. With the addition of Copilot Studio, Power Platform has also become an AI platform where users can build agents that access business data, trigger processes, and interact with end users. All of these capabilities — apps, flows, and agents — must be treated as enterprise workloads.
The core governance question is not who is technically capable of building a Power App, a Flow, or an AI agent. The question is how you prevent the platform from unintentionally becoming a bypass route around existing security, data, and AI principles. Without explicit configuration, applications, automated workflows, AI interactions, and their dependencies emerge outside the visibility of IT and security.
Identity as the primary control point
Within Zero Trust, identity is the primary control point. The right to use any capability within the Power Platform — whether that is building a Power App, configuring an automated flow in Power Automate, or publishing an AI agent via Copilot Studio — is not an automatic consequence of a license. It is an explicit entitlement.
Within Power Platform, this is technically enforced through the Environment Maker role. Governance only takes effect when this role is not assigned directly to individual users, but managed through Entra ID security groups. This brings maker access into the identity governance process, including joiner/mover/leaver workflows and periodic access reviews. This applies to all capabilities within the platform — apps, flows, and agents alike.
The question is not: can this user build something on the Power Platform? The question is: has this user been explicitly authorized to do so, and is that authorization reviewed periodically?
Environments as trust boundaries
Power Platform environments function as trust boundaries. An environment is not merely an organizational container — it is a security context that determines:
- Who can build — apps, flows, and agents
- Which data and connectors are available
- Which AI capabilities are enabled
- What level of monitoring and compliance applies
Production environments carry a higher trust level than development or experimentation environments. This limits the impact of mistakes and aligns with the Zero Trust principle of segmentation. For AI agents, segmentation is especially relevant: an agent running in a production environment has access to different data than one running in a sandbox.
| Environment | Purpose | Trust level | Who can build? |
|---|---|---|---|
| Default | Personal productivity, low-risk experimentation | Low | Restricted group via Entra ID |
| Development | Building approved solutions | Medium | Approved makers via Entra ID |
| Test / Acceptance | Validation before production | Medium-high | Limited, via change process |
| Production | Business-critical apps, flows, and agents | High | Only via ALM pipeline |
The Default environment: a deliberate risk decision
The Default environment is an explicit exception within Power Platform — and therefore a deliberate risk decision. Microsoft has made this environment available to all users in the tenant by default, including maker rights for all Power Platform capabilities. Without clear governance, the Default environment automatically becomes the home for experiments, departmental solutions, and sometimes even business-critical processes — including AI agents published without any review.
Within a Zero Trust model, the Default environment is therefore assigned an explicitly low trust level. The environment remains available for personal productivity and low-risk experimentation, but is not intended for shared solutions, business-critical processes, or published AI agents. Functional and technical restrictions, combined with monitoring, ensure this environment does not become a structural risk.
The Default environment is not ignored or locked down — it is explicitly classified and governed.
DLP as a second line of defense
Zero Trust assumes that even authorized users can make mistakes. Data Loss Prevention (DLP) policies therefore serve as a second line of defense. DLP policies restrict which connectors and data flows are permitted per environment. This limits the impact of misconfiguration or misuse, even when maker rights have been correctly assigned.
The same DLP logic applies to Copilot Studio agents: an agent can only use the connectors that the DLP policy for that environment permits. This means DLP also controls which data sources and external services an agent can reach — regardless of how the agent itself is configured.
A practical DLP framework looks like this:
- Tier 1 — Tenant-wide baseline policy: Blocks the highest-risk connectors (HTTP, social media, consumer services) across all environments. This policy always applies, regardless of any other policies in place.
- Tier 2 — Environment-specific policy: Permits approved business connectors in development and department environments, based on the trust level and business need of that specific environment.
- Tier 3 — Production policy: The most restrictive tier. Contains only the minimal set of connectors explicitly required for the solution or agent running in that production environment. Nothing more.
Microsoft Purview: data classification as an additional layer
DLP in Power Platform restricts which connectors can be used. But it does not automatically protect the data itself. This is where Microsoft Purview comes in as an additional governance layer.
Microsoft Purview Information Protection makes it possible to classify and label sensitive data based on content — such as financial records, personal data (social security numbers, credit card numbers), or confidential documents. These sensitivity labels apply to data in Dataverse, SharePoint, and other Microsoft data sources accessed by Power Platform.
For Copilot Studio agents, this is especially relevant: through sensitivity label support in Copilot Studio, labels can be surfaced in agent responses when an agent accesses classified data. This means the end user knows what type of data the agent is working with, and admins can enforce autolabeling policies via Purview on Dataverse columns.
This makes Purview relevant not just for compliance, but for managing the AI footprint: which sensitive data can an agent access, and is that visible to both the user and the administrator?
Monitoring as accountability
Zero Trust requires continuous verification and demonstrable accountability. Power Platform provides central insights into makers, apps, flows, agents, and connector usage via the Power Platform Admin Center and the CoE Starter Kit.
These insights make it possible not just to define governance, but to demonstrate its enforcement to auditors and compliance teams. Think about: who built what, which connectors are actively in use, which apps or agents have been inactive for months but are still running, and — specifically for AI — which agents are published and who can reach them.
Summary: the governance framework
Power Platform is not an exception to Zero Trust — it is an integral part of the application ecosystem, including the AI layer:
- Maker rights are a controlled capability for all Power Platform functionality, assigned via Entra ID security groups
- Environments function as trust boundaries with an explicitly defined trust level
- DLP works in layers — from a tenant-wide baseline to environment-specific and production policies — limiting the impact of mistakes and misuse
- Microsoft Purview adds data classification and sensitivity labels as an additional layer on top of DLP
- The Default environment is not ignored — it is explicitly classified and governed
- Monitoring ensures continuous verification and accountability across all Power Platform resources
➡️ Next in the series — Blog 3: Power Platform Technical Configuration: Silos, Policies, and Managed Environments.
From governance model to concrete configuration: which settings do you change, in what order, and why?
Leave a Reply