Copilot Studio environments need a strategy and routing from day one

With Copilot Studio in production, I run into the same pattern again and again. Users start building agents in the Default environment, mostly because nothing stops them. Whether they open Copilot Studio from Office.com or just click a link someone sent, hardly anyone asks where their agents and data end up. What you get is a free-for-all: no governance, little monitoring and very few data protection controls. If Copilot Studio is going to support real use cases in your tenant, you need a clear plan for environments from the start.

The Default environment puts Copilot Studio agents at risk

The Default environment in Power Platform has a reputation for good reason. Out of the box, almost anyone can build apps, flows and now Copilot Studio agents there without restrictions. DLP (Data Loss Prevention) is often missing or far too loose, and connector controls are rare. I regularly see tenants where sensitive data is connected to agents sitting in the Default environment, simply because that's where users land unless someone sends them elsewhere. Things get worse fast once agents pull in data from Microsoft 365 or external sources.

After agents have been published in the Default environment, adding governance retroactively is hard. Sharing spreads, connectors pile up, and your compliance team ends up chasing the situation. To avoid data chaos and shadow IT, make sure the Default environment never becomes your production zone for Copilot Studio. Set up dedicated environments per team, per department or even per scenario instead.

Environment routing sends makers to the right place

One feature here makes a real difference: environment routing. In the Power Platform admin center (Settings → Product → Features → Environment routing), you decide where makers land when they open Copilot Studio or other Power Platform tools. Rather than everyone ending up in the Default environment, you can route users to their own personal developer environment or, in more mature setups, straight into a managed environment with tighter controls.

Routing can be tailored to specific user groups by licence, role or Azure AD group. Regular users might get their sandbox developer environment, for example, while power users or IT land in a team or managed environment. Tying makers to managed environments that already have DLP and compliance policies in place shifts a lot of the burden off your team. Once routing is in place, the Default environment becomes a legacy catch-all rather than the starting point for new projects.

A quick diagram shows how the flow works:

graph TD
    User["User launches Copilot Studio"] --> Routing["Environment routing applies"]
    Routing --> Dev["Personal developer environment"]
    Routing --> Team["Team environment (Managed)"]
    Routing --> Default["Default environment (Legacy)"]
    Dev --> DLPDev["Own DLP policies"]
    Team --> DLPTeam["Strict DLP & Compliance"]
    Default --> Risk["Little control"]

Figure: Environment routing decides which Copilot Studio environment users enter, and each one comes with its own protections.

Managed environments, ALM and DLP keep agents structured

Once Copilot Studio spreads to more teams or scenarios, you can't really do without managed environments. The benefits are practical ones: central monitoring, connector limits, custom DLP policies per environment and clear agent ownership. For anything past basic experimentation, I always recommend managed environments with strict connector governance. Keep test and production in separate environments and use solutions for application lifecycle management (ALM). That way deployments and upgrades are auditable and safe, and nobody has to guess who built what.

Managed environments also let you set data policies per environment. This matters a lot, because if a test agent tries to reach production data, your DLP policy can block it. Auditing works better here than in the Default environment, too. Microsoft's managed environments overview goes into more detail.

Only a small group should create Copilot Studio environments

Uncontrolled environment creation is a risk many people overlook. By default, Power Platform admins (and, depending on configuration, other roles) can create new environments. If you want real governance, limit environment creation to a small, trusted group and put a formal request process in place. In larger tenants especially, this is what keeps shadow environments from slipping past oversight. I've worked with setups where every new environment has to be requested and approved centrally through the admin center, and it works surprisingly well for visibility and compliance.

My field tip: Maintain a central inventory of Copilot Studio environments, their purpose, owners, and DLP policies. It’s invaluable for audits and keeps you one step ahead of compliance questions.

None of this is unique to Copilot Studio. Power Apps and Power Automate raise very similar issues. For more background, see my earlier post on Copilot Studio governance risks and controls in 2024.

This model for Copilot Studio environments works well in practice

No single setup fits every tenant, but this is the model I see working best:

• Strict DLP in the Default environment, with no real data allowed.
• Environment routing for all users, plus personal dev environments for experimentation.
• Production agents only in managed environments, with a clear test/production split and ALM.
• Central control over who creates environments and who is responsible for them.
• Good documentation, regular reviews and transparency about DLP and compliance per environment.

With your Copilot Studio environments set up along these lines, you're far better placed on governance and compliance, and Power Platform sprawl stays under control.