Copilot Managed Runtime (II): everything at the click of a button
ℹ️ In collaboration with Ana Estigarribia
In Part I, we followed the maker’s click as they created a managed app all the way to their Personal Developer Environment (PDE), and we saw how Copilot Managed Runtime applies default governance. But having an out-of-the-box configuration does not mean it is the right one for our organization. That brings us to the next question.
What options do we have to take control?
The short answer is: it depends on what we need to control.
There is no single switch that addresses access, routing, security, and consumption all at once. We have several levers, and each one addresses a different part of the problem.
Option 1: temporarily block the entry point
If we need time to understand the impact, we can disable app creation from Copilot Studio. This entry point is enabled by default and can be managed from the Microsoft 365 admin center.
Apps → Overview → Set up app creation spaces
This stops creation from Copilot Studio, but it does not block other entry points, such as Cowork or the CLI, which are managed separately. The CLI is disabled by default and can be enabled by environment or Environment Group; in Cowork, creation depends on the maker having access to the tool.
Therefore, this option can be a useful containment measure while we review the configuration. But it should buy us time, not postpone the decision indefinitely.
Blocking Copilot Studio is not the same as disabling Copilot Managed Runtime.
Option 2: limit creation to specific groups
If we do not want to open the experience to the entire organization, we can restrict creation from Copilot Studio to Microsoft Entra security groups through the CLI using:
powerPlatform.powerapps.enabledGroupsManagedAppsMcsPreview
Cuando la vía de Copilot Studio está habilitada, solo las personas incluidas en esos grupos pueden crear aplicaciones desde ella. Esto nos permite empezar con un grupo reducido: un piloto, un equipo de innovación o makers que ya hayan pasado por un proceso de acompañamiento. Pero cuidado: estar autorizado para entrar no garantiza tener una regla de routing aplicable.
When the Copilot Studio entry point is enabled, only people in those groups can create apps through it. This lets us start with a small group: a pilot group, an innovation team, or makers who have already completed an enablement process. But be careful: being authorized to enter does not guarantee that an applicable routing rule exists.
The group that grants access to the experience and the group used by Environment Routing serve different purposes:
The first determines who can use the entry point.
The second determines who can get a PDE and where it will be provisioned.
If we do not coordinate both controls, we may allow someone to see the experience while still preventing them from completing app creation.
Option 3: control capacity and consumption
We can also manage Copilot Credits: define which users or groups are covered, set limits, and monitor consumption. And... SURPRISE! Managed apps consume credits! (We will tell you more in the final chapter.)
But controlling the budget does not replace technical governance. Consumption limits do not determine which Environment Group the maker is routed to, which connectors they use, how broadly they share the app, or which security policies apply.
Controlling consumption limits financial exposure. It does not define platform behavior on its own.
Option 4: configure routing and policies to take control
This is the option that allows us to move from containment to a sustainable model. Apps inherit the rules of their environment and Environment Group. Before expanding access, we should review:
Who is covered by each routing rule and the order in which the rules are evaluated
Which connectors, specific actions, and MCP servers are allowed
How internal and guest sharing is configured
Which Content Security Policy applies and whether it is introduced in report-only mode first
How Advanced Connector Policies coexist with existing DLP policies
And, of course, how all of this works alongside the other policies in the governance framework.
Okay, but... which option should we choose?
These options are not mutually exclusive. We can combine all four levers:
Temporarily block creation while we assess the impact
Open access to a small group to validate the scenario
Set consumption limits to control financial exposure
Design routing and policies before expanding adoption
The key is not to confuse them:
Blocking an experience does not design routing
Limiting access does not control consumption
Controlling credits does not replace security policies
Configuring routing does not determine on its own who can use each entry point
Blocking lets us stop. Limiting lets us test. Controlling consumption lets us cap costs. Governing lets us scale.
So, should we block or govern?
Temporarily blocking creation can be a reasonable decision when we do not yet understand the scope, have not reviewed consumption, or need time to configure governance. But it should not be our only strategy.
Because blocking answers only one question: Do we want to stop creation from this entry point right now?
But governing requires us to answer several more:
Who can create, and from which entry points?
Where will their PDE be provisioned?
Which connectors, actions, and MCP servers can they use?
How broadly can they share the app?
How will consumption and the lifecycle be managed?
This is not about allowing everything or blocking everything. It is about understanding what happens after that simple click and taking control of every decision: starting with a small group, configuring routing, reviewing the default governance, setting consumption limits, and expanding access when the model is ready.
When we talk about governance, we mean enabling, not prohibiting: enabling the maker to solve a need without every new app or feature overwhelming the governance team.
Blocking stops creation. Governing enables controlled scaling.
And that concludes Part II. In the third and final chapter, we will cover the two remaining pieces: consumption and monitoring.
Comments