We thought agents were off. Licensing proved us wrong.
When governance and automation meet: scripting sanity into service plan sprawl
It seems straightforward: Turning off access to Copilot agents in the M365 admin center closes the door to custom agent creation, as users don’t see the ‘Agent Builder’ in Teams or the M365 Copilot app anymore. Problem solved, right? Not even close.
The surprise behind the toggle
During a recent internal discussion, we talked about the complexities of managing Copilot features. Taking the agent creation as an example: Even if you configure the “Choose who can access agents” to ‘No users’, users might still be able to access copilotstudio.microsoft.com and build agents. Why? Because the Copilot Studio service plan is still active in their M365 Copilot license. The admin center control only hides the builder, it does not revoke the underlying capability of creating agents. Such gaps have caught more than one stakeholder off guard.
This is not a bug. It is how Microsoft’s licensing model works: features are exposed through service plans, and those plans live inside the license SKU. If the plan is on, the feature is technically available, regardless of what the app interface suggests.
The hidden complexity of service plans
Looking at the Microsoft Licensing service plan reference, the Copilot for Microsoft 365 license includes multiple service plans beyond the obvious productivity features. Some of these plans enable Copilot Studio, Viva Insights, and even components that might look unrelated, such as Audio Conferencing and Sales Copilot, depending on the license SKU variant.
To make matters worse, there are at least two M365 Copilot SKUs with nearly identical names but different service plan bundles. One includes conferencing features whilst the other does not. If you do not know which license you are dealing with and which plans are enabled, you cannot be sure what is actually enabled.
Why this matters for governance
For regulated environments, this is more than an annoyance. If your policy says “no custom agents until we complete a risk review,” you cannot rely on an UI setting. You need to manage service plans at the license level. That means:
Inventory every service plan in your tenant.
Understand what each plan enables (documentation is patchy, so expect to test).
Disable plans that expose capabilities you are not ready to support.
And here is the kicker: new service plans appear over time, and they are on by default regardless of whether you use user-based or group-based licensing. That default is great for small businesses that want everything to “just work.” For an enterprise, it is a governance nightmare.
Our fix: Automate the diff
We built an automation to close the gap. It runs daily, compares the current list of service plans against an approved baseline, and disables any new plans that slipped in. The logic is simple:
Export the current service plan state for each license GUID.
Compare it to the baseline of allowed plans.
If a new plan appears, log it and flip it off.
It might not be elegant, but it works great when using group-based licensing. It also gives us an alert when Microsoft adds something new, so we can review it before users start raising questions and support tickets based on their experimentations. Start managing your license estate today, with the code found on this GitHub repository.
Lessons learned
UI toggles are not governance. If you need to enforce a policy, also be sure to account for the license layer.
Expect silent changes. Service plans evolve without fanfare. Build monitoring into your process.
Document what you disable and why. Future you will thank you when someone asks why Copilot Studio “doesn’t work”.
Communicate early. Users will find these features. If you block them, explain the reason and the timeline for review.