Blogserie: Power Platform Security & Zero Trust — Part 1 of 4
A scenario that happens more often than you think
An employee installs Power Apps through their Microsoft 365 license. In an afternoon, they build an app that pulls customer data from SharePoint and automatically forwards it to an external partner via an HTTP connector. They share the app with their team. No ticket raised, no security review, no IT approval.
Technically, they did nothing wrong. The tenant allowed it.
This is not a hypothetical scenario. This is exactly how Power Platform behaves without explicit governance. The Default environment is open to all licensed users. Everyone is automatically an Environment Maker. No DLP policies are active. Connectors to external services are available by default.
Power Platform is designed for fast adoption. Microsoft has deliberately lowered the barrier so that business users can get started quickly. That is also precisely what creates the risk from a Zero Trust perspective.
Power Platform is not a hobby platform
Power Apps and Power Automate are often treated in organizations as “citizen development tools” — low-threshold, outside the normal IT domain, not really enterprise. That assumption no longer holds.
Power Platform connects to your CRM, your ERP, your SharePoint, your Exchange, your Dataverse, your Azure SQL. Through custom connectors and the HTTP connector, it can call virtually any API. Power Automate flows run 24/7, automated, and often under a personal user account.
And it goes further than apps and flows. With Copilot Studio, users can now build AI agents directly on the Power Platform — agents that interact with users, call APIs, access business data, and trigger automated processes. These agents are subject to the same governance gaps as any other Power Platform resource: built quickly, outside IT visibility, and with access to data that may not be appropriate for an unmanaged AI interaction.
If a flow fails or is misconfigured, it does not draw attention the way a crashing server does — it quietly does something other than intended. If an app shares data that should not be shared, there is no firewall log registering it. If an agent is trained on the wrong data source or exposed to the wrong audience, the impact can be significant — and hard to trace.
Key point: Power Apps, Power Automate flows, and Copilot Studio agents are all fully-fledged application, integration, and AI capabilities. They must be treated as enterprise workloads — not as shadow IT that happens to be delivered by Microsoft.
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.
The three Zero Trust principles translated to Power Platform
Zero Trust is not a product or feature — it is a security philosophy. The core principle: trust is never implicit. Access is continuously evaluated based on identity, context, and risk. Three principles form the foundation:
| Zero Trust Principle | Translation to Power Platform | |
|---|---|---|
| 🔐 | Never Trust, Always Verify | Maker rights are not an automatic consequence of an M365 license. Access must be explicitly granted and continuously evaluated — for apps, flows, and agents alike. |
| 🎯 | Least Privilege | Not every user needs access to all connectors, environments, or AI capabilities. Rights are kept as narrow as possible. |
| 🛡️ | Assume Breach | Assume a flow is misconfigured, a connector is misused, or an agent accesses data it should not. DLP, segmentation, and monitoring limit the blast radius. |
What is enabled by default — and what can go wrong?
Microsoft has configured Power Platform to be immediately usable after purchasing a license. That is good for adoption. From a security perspective, the default settings are concerning:
- Default environment: Available to all users in the tenant. Automatically accessible, no explicit request or approval required. Every new user signing up for Power Apps is automatically added to the Maker role of the Default environment.
- Environment Maker role: Assigned by default to all users in the Default environment. Everyone can build apps, flows, and agents.
- DLP policies: No tenant-wide DLP policy is active unless you create one yourself. All connectors — including HTTP — are available.
- Connector access: Hundreds of out-of-the-box connectors are available, including connections to Dropbox, Twitter/X, Gmail, and other external services.
- AI & Copilot Studio: Users with the right license can build and publish AI agents without any governance controls in place by default. Agents can access business data, trigger flows, and interact with users — all outside IT oversight.
- Monitoring: Without the CoE Starter Kit or additional configuration, there is little visibility into what is being built and by whom — apps, flows, or agents included.
A note on Environment Routing
Microsoft has introduced Environment Routing as a premium governance feature that automatically directs makers into their own personal developer environment instead of the Default environment when they visit Power Apps, Power Automate, or Copilot Studio. This is a meaningful step forward — but it is important to understand what it does and does not cover.
Environment Routing is turned off by default and must be explicitly enabled by a Power Platform Administrator in the admin center. When not configured, all makers still land in the Default environment. Even when enabled, makers can still manually switch back to the Default environment. The Default environment itself remains accessible and does not disappear. This means that Environment Routing reduces the problem but does not eliminate the need for explicit governance of the Default environment. Configuring routing is a quick win — but it is the beginning of the solution, not the end.
The default settings of Power Platform are designed for adoption, not for security. That is a deliberate choice by Microsoft. The responsibility for a secure configuration lies with the organization.
The three layers of a Zero Trust approach
Layer 1 — Identity & Access: Who can build?
The right to create a Power App, a Flow, or a Copilot Studio agent is an explicit capability, not an automatic consequence of a license. Maker rights are granted through the Environment Maker role, and that role should be managed via Entra ID security groups — not assigned directly to individual users. This brings maker access into the identity governance process: joiner/mover/leaver workflows and periodic access reviews.
Layer 2 — Data & Connectors: What can flow through?
DLP policies determine which connectors are available per environment. They form the second line of defense: even if maker rights are correctly configured, DLP limits the impact of mistakes or misuse. A tenant-wide baseline policy is the starting point — supplemented by environment-specific policies for more sensitive contexts. For AI agents, this also means controlling which data sources and knowledge bases are accessible.
Layer 3 — Environments & Governance: Where can it run?
Environments are not organizational containers — they are trust boundaries. Per environment, you define who can build, what data and connectors are available, and what level of monitoring applies. Production has a different trust level than development, and development has a different trust level than the Default environment. This applies equally to apps, flows, and AI agents.
Five steps you can take today
| # | Action | Effort | Impact |
|---|---|---|---|
| 1 | Remove the Environment Maker role from all users in the Default environment | Low | High |
| 2 | Create a tenant-wide baseline DLP policy | Low | High |
| 3 | Enforce MFA for all makers via Conditional Access | Low | Critical |
| 4 | Enable Environment Routing to redirect makers to personal developer environments | Low | High |
| 5 | Deploy the CoE Starter Kit for immediate visibility | Medium | High |
| 6 | Block the HTTP connector in the Default environment | Low | High |
What is the CoE Starter Kit?
The Power Platform CoE Starter Kit is a free, open-source collection of apps, flows, and dashboards built by Microsoft that gives administrators immediate visibility into what is happening across their Power Platform tenant. It answers questions like: How many apps exist? Who built them? Which connectors are in use? Are there flows running under personal accounts? Are there agents that nobody has reviewed?
Three key components make up the kit:
- Core components: Inventory sync across all environments, Power BI dashboard, DLP impact analysis, and admin tools for daily governance tasks.
- Governance components: Compliance processes, inactivity notifications, and maker audit workflows — including tools to deal with orphaned or non-compliant resources.
- Nurture components: Onboarding emails for new makers, training templates, and community-building tools to guide makers toward compliant development.
You can download it from the official GitHub repository or follow the setup documentation on Microsoft Learn.
Implementation tip: Removing the Environment Maker role in the Default environment has direct impact on users who have already built apps or flows there. Communicate this in advance and ensure an alternative environment is available for legitimate use cases.
What’s next?
This blog has laid the foundation: why Power Platform must be treated as an enterprise workload, how Zero Trust principles translate to the platform, and which steps you can take immediately.
In the next blog, we go deeper into the governance framework. We look at environments as trust boundaries, maker rights via Entra ID, DLP as a second line of defense, and how to explicitly classify the Default environment rather than ignore it.
➡️ Next in the series — Blog 2: Power Platform Governance: Environments as Trust Boundaries.
How to build a coherent governance model that aligns with the Zero Trust framework.
Leave a Reply