Copilot Managed Runtime (I): everything at the click of a button

In collaboration with Ana Estigarribia

An ordinary day at work.

A maker opens Copilot Studio and there it is: that new button labelled App, whispering to their subconscious, ,«click it, click it, click it». In the end... they click it. After all... «what could possibly go wrong?»... And then they tell other makers about it.

That same day, the person responsible for Power Platform governance (if that role even exists in the organisation) opens the admin centre and... SURPRISE! Personal Developer Environments (PDEs) have multiplied as if by magic.

The result? 🚨PANIC ON: «Where did all this come from?»

But... do not panic! Admins, step right up! Let us welcome Copilot Managed Runtime (CMR)! Let us take it one step at a time...

What is Copilot Managed Runtime?

Copilot Managed Runtime, or CMR, currently in preview, is the Microsoft-managed platform that hosts and runs the new managed apps. These apps use Microsoft Entra identity, are subject to the tenant’s governance policies, and appear in the app inventory in the Microsoft 365 admin centre (MAC) and in the resource inventory in the Power Platform admin centre (PPAC), where they can be monitored and managed.

Where makers see a simple app-building experience, admins see a new surface that must be governed. Behind that apparently simple experience lie identity, environments, routing, connectors, MCP servers, data policies, sharing, capacity, consumption, and inventory. That is where CMR comes in.

These apps must be created within the organisation’s governance framework, so the admin team can apply controls and maintain a centralised view. To achieve this, CMR checks a series of governance measures and, if they are not configured in the tenant, applies a default configuration. But, does that configuration meet your organisation’s needs?

Microsoft provides a baseline; we still have to decide who can create, where they will do it, what they can use, and how much we are willing to consume (because it is not free).

So, if we are responsible for administering the platform, questions such as these will arise:

• «Do we allow the App button in Copilot Studio?»

• «What actually happens after someone clicks it?»

• «How are we going to incorporate this into our governance model?»

Right then, get your magnifying glass ready and let us look for those answers.

Different entry points, one runtime

Our maker in the example only clicked a button in Copilot Studio. Is that all? Not quite, because there are several entry points for creating these apps: Cowork, Copilot Studio, Copilot Code, and the CMR SDK/CLI. All these routes converge on CMR. The maker creates their app from one of these entry points and, from that moment, the platform has to decide where it will be built. The chosen location is the maker’s Personal Developer Environment (PDE).

Returning to our opening scene: the PDEs had not multiplied by magic.

Environment Routing was behind it all.

Environment Routing: from one click to a PDE

At this point, you may be wondering: «Why is Environment Routing activated if we have not enabled it in our tenant?»

If the maker already has a PDE when they click the button, it is reused. Otherwise, the platform provisions a new one according to the organisation’s Environment Routing rules. If you have not configured any, a default rule is activated automatically. These PDEs are Managed Environments without Dataverse (which can be added later).

This leaves us with two scenarios:

If no Environment Routing rules exist

If there are no Environment Routing rules, CMR creates one for Everyone, routes each maker to their PDE, and applies default governance through an Environment Group.

Therefore, not configuring Environment Routing does not mean that routing does not exist; it means that the Microsoft-defined routing is used. This may be valid, but it must be a conscious decision: the Everyone rule can only be deleted after another rule with the same scope has been configured.

If Environment Routing rules are already configured

If you had already done your homework and configured Environment Routing in your tenant, CMR retains the existing rules, their priority, and the destination Environment Groups. When a maker matches a rule, their PDE is created or reused in the corresponding group. If they do not match any rule, their PDE is not created and they cannot create managed apps until they are covered by a rule.

Governance out of the box

CMR includes default governance from the outset. Apps inherit a policy that controls what they can connect to, how broadly they can be shared, and how they behave at runtime. This governance is applied alongside the organisation’s existing Power Platform policies; it does not replace them.

The baseline is based on four rules:

Routing

Determines who gets a PDE, which Environment Group it is routed to, and which rules it inherits.

Routing positions the maker; the other rules define what they can do.

Connectors and MCP servers

An Advanced Connector Policy (ACP), applied to the Environment Group created by default, establishes a default list of Microsoft connectors and MCP servers that the apps can use.

There is an important nuance here: allowing a connector does not mean allowing all its actions. Some actions, such as making HTTP requests, running scripts, or invoking certain platform operations, remain blocked even when the connector is allowed, although an administrator can control both the available connectors and the specific actions the apps are permitted to execute.

So ask yourself: Do we need the entire connector, or only certain actions?

Sharing

The sharing rule defines, for the Environment Group, whether makers can share apps within the organisation and with guests. The default values are:

• Anyone in the organisation can open the app through the shared link

• Disabled for guest users

  
  

And one very important point: sharing an app does not automatically grant access to the data it uses. These are separate permissions. For someone to use the app, we must also manage their access to that data.

Content Security Policy

The Content Security Policy (CSP) controls where the app loads resources from and where it can be embedded. The baseline restricts scripts, images, fonts, connections, forms, and embedded content, although an administrator can authorise specific origins.

CSP supports two modes:

• Enforced: blocks resources that do not comply with the policy.

• Report-only: does not block them, but reports which resources it would reject.

  
  

Report-only makes it possible to assess the impact before blocking and prevents a poorly tuned change from disrupting the app.

And that concludes Part I: makers can build managed apps within a governed perimeter without an administrator having to define everything from scratch.

But remember, the default governance may not be the most appropriate for your organisation. Choosing to keep it as-is is, in itself, a governance decision, but that decision is made by the product on our behalf.

To be continued...