The problem: a default environment that became a junk drawer
Every Power Platform tenant starts with a default environment. Makers land there automatically and everyone in the organization can reach it. That made onboarding easy. It also meant apps, flows and connections piled up in one place. Many were shared too broadly, and many were abandoned when their authors changed roles.
Microsoft says its corporate tenant now holds hundreds of thousands of low-code agents and other resources that touch company data. The case study names the risks: over-shared apps can expose information, and ownerless workflows leave unmanaged resources behind. The article gives no incident counts, data-loss figures or measured risk reduction. Its numbers describe scale and adoption, not security outcomes.
Naveen Jangir, a Microsoft Digital principal architect, frames the philosophy. Microsoft's answer is not to hide data from agentic tools. It is to govern the data and restrict access appropriately.
The fix: one owner, one workspace
Employees who open Copilot Studio, Power Apps or Power Automate now land in their own personal developer environment (PDE), not the shared default. Microsoft says employees have created more than 170,000 PDEs since 2024. Each has a single owner who is responsible for what is built there.
Microsoft compares the model to OneDrive:
- The workspace is individually owned.
- Sharing is constrained.
- Anything built there stays subject to the maker's existing permissions and organizational policies.
A PDE does not grant extra access to company data. Apps and agents run within the maker's own permissions.
The company uses three tiers:
- Personal: individually owned, with limited sharing.
- Sandbox: where teams build together.
- Production: for company-wide solutions. These must pass security and responsible-AI reviews first.
Sandbox and production have grown much more slowly than personal environments, which Microsoft says is intentional. Ownership also helps with cleanup. When an employee leaves, lifecycle processes identify that person's environments and resources. The article gives no retention or deletion timelines.
Connectors: the real data highways
Connectors are how apps and agents reach email, files, databases and other services. Microsoft decides in advance which connectors each environment type can use, and those rules apply automatically when an environment is created.
In personal environments, makers can use almost any Microsoft connector, with two conditions:
- The connector must sign in with the maker's own work account.
- It cannot send company data to services outside Microsoft.
Sandbox and production environments get more oversight and fewer limits. Each is registered to a team and tagged with the type of data it handles. Makers there can build custom connectors. When a new connector appears, Microsoft Digital and the Office of the CISO decide whether all makers can use it or only makers in higher-risk environments.
Microsoft is careful to say these controls don't make every use of accessible data appropriate. Identity and permissions, data governance, monitoring and, where needed, privacy, legal or responsible-AI review still apply.
Detection and agents
Preventive rules don't catch everything. When someone builds a resource in the default environment, Microsoft Sentinel flags it, alerts the maker and suspends the resource so it can be moved. A third-party detection tool adds more signals. Microsoft says alerts spiked when enforcement began and then tapered off. It gives no counts or dates, and nothing independently validates that trend.
For agents, Copilot Studio inherits Power Platform connector policies. Each agent stays tied to the environment where it was built, so the team can see who owns it and what it connects to. Microsoft stresses that this is only a foundation. Agents also need controls over identity, permissions, data access and runtime activity. The Office of the CISO assesses agent configurations and monitors for policy violations. It also meets weekly with the Microsoft Defender product group, as Customer Zero, to share findings and test new capabilities.
Microsoft admits the work is unfinished. Some product features still rely on the default environment, and agents keep introducing new risks beyond environment configuration.
What admins can do themselves
The mechanism behind PDEs is a feature any tenant can use. Microsoft Learn describes environment routing as a premium governance feature that lets Power Platform admins direct new or existing makers into their own personal developer environments in Copilot Studio, Power Apps, Power Automate or Power Automate for desktop.
Key facts from Microsoft's documentation:
- Off by default. A Power Platform admin turns it on in the Power Platform admin center under Manage, then Tenant settings, then Environment routing. Admins pick portals, create rules for everyone or specific security groups, choose a target environment group and order the rules by priority.
- First match wins. If no rule matches, or routing is off, the maker lands in the default environment.
- Managed by default. Environments created through routing are managed, and makers get the admin security role in them. Creating or previewing apps doesn't need a premium license, but running them does.
- Preconfigured settings. Sharing is limited to five individuals, Solution Checker is set to Warn and usage insights are on.
- Existing environments. A maker who already owns a developer environment is routed there. Otherwise a new one is created.
- Scope. Routing covers Copilot Studio, Power Apps, and Power Automate cloud and desktop flows, but not Power Pages.
- Deprecation date. Learn says unmanaged developer environments are deprecated and suspended starting December 15, 2026. Routing creates managed environments, so it isn't affected.
Environment groups carry the governance. Pointing routing at a group means new developer environments inherit its published rules. Only published rules are enforced. Changing the group later affects only new environments, and existing ones stay where they were unless moved manually.
Connector policy: don't oversell it
Microsoft Learn lists limits on connector controls:
- Classic data policies sort connectors into Business, Non-Business or Blocked. Connectors in different groups can't share data in the same app or flow.
- Some core connectors, such as Dataverse, Approvals and Notifications, can't be blocked by classic policies.
- Advanced connector policies use a strict allowlist and can restrict any certified connector. But custom, HTTP and virtual connectors aren't supported there yet. HTTP and custom connectors stay under classic data policies.
So "connector restrictions" is not one switch that closes every data path. Microsoft's own Inside Track piece effectively concedes this by pairing policies with monitoring and remediation.
Can't route makers into PDEs yet?
Microsoft's guidance still says to harden the default environment:
- Use managed environment features such as sharing limits.
- Track connector use, including core connectors that can't be blocked.
- Find ownerless and unused apps. Learn mentions apps without valid owners and apps unused for 60 days.
- Move high-value apps out through solutions.
Takeaways
Microsoft's recommended principles are:
- Run governance and security as one operating model.
- Keep an accurate, fresh inventory.
- Migrate off the default environment on a clear timeline, with gradual connector restrictions.
- Pair guardrails with monitoring.
- Review agents by risk.
The caveat is that Microsoft supplies adoption figures but no before-and-after exposure data. The model is sensible and the tooling is documented. Whether it actually reduced risk rests on Microsoft's word. IT teams should copy the architecture and measure their own results.