Microsoft now draws a line between the Microsoft 365 Copilot features your licence covers and the ones billed on usage. If you plan to set up a Copilot spending policy, do it before your users start running into locked features. Below I go through what the release notes and Message Center say has changed and how I would handle it in a tenant.
Usage-billed Copilot features stay locked without a policy
The everyday Copilot capabilities remain part of the Copilot user licence. Newer and more extensive features such as "Code" and "Autopilot" in the Microsoft 365 Copilot app are billed on usage through Copilot Credits. Having a licence is not enough to use them. Until an administrator has defined a spending policy, those features stay locked for users.
That keeps unplanned costs out of your bill, but it also means licensed users will hit a locked feature and ask your help desk why. The official Microsoft 365 Copilot release notes summarise the changes. Read them once before you configure anything, since some labels in the interface have moved around in the past few weeks.
The spending policy lives in the Microsoft 365 admin center
You manage this in the Microsoft 365 admin center. The release notes place it under "Copilot" and then cost management. My assumption is that you need an admin role with access to billing and Copilot settings, for example Global Administrator or Billing Administrator. I don't guess here, though; I check in the admin center which role actually works.
A policy sets which group of users may consume credits and how much budget they have. Security groups in Microsoft Entra ID fit well, and you likely use them for licence assignment already. I wrote about making that scale in Copilot group-based licensing. Those same groups can form the basis of your spending policy.
I set up the policy in six steps in the admin center
This is my own routine. Menu names may look slightly different depending on how far the rollout has reached your tenant.
- Sign in to the Microsoft 365 admin center as an administrator and open the "Copilot" area.
- Open cost management and check whether a policy already exists.
- Create a new spending policy and assign a pilot group from Entra ID.
- Set a budget and, if the option is there, the allowed model families.
- Sign in with a test account from the pilot group, open the Copilot app and see whether "Code" and "Autopilot" show up.
- After a week, look at consumption in the dashboards and widen the group gradually.
Admins decide what users see at a locked feature
For users who aren't covered by a policy, you can reportedly choose what appears when they hit a locked feature. It's either a "Request access" button or just a "Learn more" link. The setting rolls out in stages, from October 2026 for standard customers and from November 2026 for deferred customers. If there's a clear approval path, I go with the request button. Otherwise I use the link.
Combined with the new licence requests page in the admin center, you get the flow I've sketched below. A user request goes to IT, IT decides on group membership, and only after that does the feature become available.
flowchart TD
A["User opens Code or Autopilot"] --> B{"Spending policy in place?"}
B -->|"No"| C["Feature locked"]
C --> D["Request access or Learn more"]
D --> E["IT reviews the request"]
E --> F["Add user to the policy group"]
B -->|"Yes"| G["Credits are consumed"]
F --> G
G --> H["Check usage in the dashboard"]
From opening a paid Copilot feature to approval and usage tracking.
Tip: Begin with a small pilot group and a low budget. Within a few days you'll see which features people really use, before the costs spread across the whole tenant.
The cost dashboards show where credits go
Microsoft has expanded its AI cost reporting. The Copilot and consumption dashboards now show figures on Cowork adoption, and they cover Copilot Code, Copilot Studio and advanced work in SharePoint and OneDrive. Copilot Studio even shows costs in agent evaluations, so makers know what their test runs cost.
That's why I block a fixed slot in my calendar to review usage per group, once a week for the first few months. Agents follow the same rule as governance in general: if you give them system access, watch the cost as well. My article on Copilot Studio agent flows and governance deals with that side. For the licensing basics, Microsoft's documentation on assigning Copilot licences is the place to look.
Two other Copilot settings come with deadlines
Put two dates in your calendar. First, the existing PowerShell settings for opting out of the SharePoint Copilot preview are honoured only until 1 November 2026. After that, availability is controlled through the AI settings of each SharePoint site. Second, community sources report that from 25 October 2026, uploading advanced packages such as declarative agents or MCP servers will be allowed by default unless you restrict it before then.
So far I've only seen the second point in community sources, so I check the setting directly in the Copilot controls of the admin center before I change anything. If you manage agents and integrations, start with the page on Copilot agents and integrated apps in the admin center.
I work through the tenant in a fixed order
When I look after a tenant, I stick to this sequence. I read the release notes first and write down which features matter to my customers. Next I create Entra ID groups for the pilot users and a spending policy with a small budget. Then I test with a single account and document what users will see.
Last, I send users a short note explaining why some features are locked and how they can request access. It cuts down on questions considerably. With this groundwork in place, you won't get surprises on the invoice, and you won't have frustrated users who pay for a licence but can't use what they expected.
