Hi
@KL-27081825-0,
For this scenario, I wouldn't try to solve everything by removing Environment Maker from the Default environment. That would likely disrupt the Power Automate/Power Apps maker scenarios you still need.
I would separate the governance controls into authoring, publishing, sharing, and environment placement.
1. Block publishing first
Microsoft now provides a tenant-level control to disable publishing of agents that use generative AI features in the Power Platform admin center. This is useful as an immediate safety control while the additional licenses are being rolled out.
This is different from removing Environment Maker, so your users can retain their existing low-code maker capabilities.
2. Use DLP/data policies to block specific channels
If the requirement is specifically:
"Users can build agents, but they cannot publish them to Teams/M365, websites, WhatsApp, etc."
then use Copilot Studio data policies.
Microsoft documents channel-level controls for blocking:
- Microsoft Teams + M365
- Direct Line/web channels
- Facebook
- Omnichannel
- SharePoint
- WhatsApp
If all available publishing channels are blocked, the agent cannot be published through those channels.
This is much cleaner than removing Environment Maker from the Default environment.
3. Don't use the Default environment as the long-term Copilot environment
For a deployment of this size, I'd move toward a zoned model:
Default Environment
│
├── Existing Power Apps
├── Power Automate
└── Low-code maker scenarios
│
└── Keep working
Personal / Developer Environments
│
└── Personal experimentation
└── Maker-owned agents
Controlled Copilot Environments
│
├── Approved makers
├── Approved data sources
├── DLP policies
├── Controlled sharing
└── Controlled publishing
Microsoft's current Copilot Studio governance guidance explicitly recommends zoned governance and using developer environments for personal-use agents, while keeping production/organizational agents in controlled environments.
Environment routing can also automatically send makers into their own Developer environment instead of the Default environment when they enter Power Apps, Power Automate, or Copilot Studio.
That would be particularly attractive here because you want to preserve personal agent creation without allowing thousands of users to create everything in the shared Default environment.
4. Control who can author agents
Copilot Studio has environment-level security controls for agent permissions. Microsoft documents controlling who can create/read/update/delete agents through Dataverse security roles.
So I'd create something like:
Agent Makers
↓
Approved security group
↓
Controlled Copilot environment
↓
Agent Author permissions
while normal users retain their existing Power Platform maker access elsewhere.
5. Sharing should also be governed separately
If the concern is users creating personal agents and then sharing them broadly, there are now Managed Environment sharing controls for Copilot Studio agents.
These can restrict who can receive Editor/Viewer permissions and how makers can share agents.
That gives you another control point without having to remove their general maker permissions.
What I would implement for your immediate 15-day window
I would use a temporary lockdown first:
Tenant
└── Disable GenAI agent publishing
+
Environment
└── DLP restrictions on Teams/M365 + other production channels
+
Default environment
└── Keep Environment Maker
Then, once the licensing rollout is complete:
Default
↓
Keep for existing Power Apps / Power Automate maker scenarios
Developer environments
↓
Personal agents / experimentation
Controlled Copilot environments
↓
Approved agent makers
↓
DLP + sharing controls
↓
ALM / approval process
↓
Production publishing
I would not try to achieve the whole requirement with one permission change. Microsoft has deliberately separated these governance layers: environment access/security roles control who can work in an environment, data policies control what agents can use/publish to, tenant settings can control publishing, and Managed Environment controls can restrict sharing.
One important caveat: if by "personal Copilot agents" you mean agents created in the Microsoft 365/Copilot experience rather than Copilot Studio agents, don't assume that disabling Copilot Studio authoring will disable those as well. They are governed through different Microsoft 365/Copilot controls.
For a 15,000-user rollout, I'd also avoid making the Default environment the strategic home for Copilot agents. Microsoft specifically recommends using a non-default production environment for agents intended for production.
