Enterprise IT · 19 August 2026 · 6 min
Group hygiene is now budget control
Copilot credits are governed by your security groups — and the conflict rule is fail-open
Until now, an incorrect group membership has been an access problem. Since Microsoft introduced consumption-based billing for AI services in Microsoft 365, it is also a budget problem — and the mechanism that decides who gets to use how much is precisely the mechanism most organizations have the weakest control over.
This is worth going through technically, because the details are counterintuitive.
Spending policies in brief
The Microsoft 365 admin center lets you create spending policies for credit-based consumption. A policy defines who can use credits, which agents and services they can be used on, an overall limit for the policy, and optionally a per-user limit. There is a tenant-wide default policy, and named policies tied to selected groups.
The policies are limit-based, not allocating — Microsoft's own wording is that they "don't allocate or reserve credits". If a user hits the limit, they lose access to agents and services for the rest of the month, until credits reset on the first. The user can ask for more; there is no automatic override.
Note the scope as of August 2026: the functionality is documented for Cowork and the Work IQ API. Other pay-as-you-go consumption is still handled under Billing > Pay-as-you-go.
Point one: you cannot assign to a user
Microsoft's documentation is unambiguous: "At this time, you can only support specific users through security groups. To add specific users to a spending policy, ensure they're in a security group first and then select specific groups from the policy setup."
So there is no direct assignment to individual users. Your AI budget control is a function of your security groups — no better and no worse than the group hygiene behind them.
Whether Microsoft 365 groups and dynamic groups are supported is not documented. The phrasing "only ... through security groups" argues against it, but Microsoft does not say so directly. The same goes for nested groups: the word does not appear in the documentation, and neither support nor lack of support can be claimed.
Point two: the conflict rule is fail-open
This is the technical finding that matters most. If a user ends up in several policies for the same service, a policy is assigned in this order, verbatim from Microsoft:
1. Highest per-user limit
2. If tied, the largest overall policy limit
3. If still tied, the most recently created policy
The most generous policy wins. And the reinforcement: "If a policy doesn't have a per-user limit set, the system uses its overall policy limit as the per-user value for this comparison." A policy where someone forgot to set a per-user limit therefore competes with its entire policy limit — and thus routinely beats a tight policy.
Further: "The chosen policy applies in full and settings from other policies aren't combined", and when a limit is exhausted "the system keeps the user on the assigned policy and doesn't reevaluate the user against other policies".
Practical consequence: a developer who is added to the group AI-Pilot-Unlimited for a three-day proof of concept in March, and who is never removed, will for the rest of the year beat any tight departmental policy they are otherwise covered by. Nobody is notified. The group still looks correct in the Entra portal.
Another scenario: if you delete a policy, users may "continue to have access to usage-based billing through another applicable policy" via other group memberships. Deleting the policy is therefore not the same as stopping the consumption.
Point three: changing groups mid-period splits the bill
"If a user moves from one Entra ID group to another during a billing period, the new group's spending policy becomes effective for that user. Credits consumed before the move remain billed against the previous spending policy." The user's consumption resets against the new policy, while the total for the period is still shown as one figure.
For a group with internal cost allocation, that means one employee who changes department on the 12th of the month generates two charges on two cost centers — and that reconciliation has to be done against the invoice, not against the dashboard. Microsoft is clear on the latter: "Use the monthly billing record for reconciliation, not the usage dashboards."
Point four: the billing method is locked
Microsoft explicitly allows per-department billing — a different billing method per group, per department or per set of users, set by a Global Administrator or Billing Administrator. The order in which sources are drawn down is: capacity packs → pre-purchased P3 credits → pay-as-you-go.
But: "After you set a billing method for a spending policy and create the policy, you can't change it. To update it, you must delete the policy and create a new one." A mistake in setting up the cost structure is corrected by tearing down and rebuilding — with the consequences for group membership and the fail-open rule that follow from that.
The role model is worth noting: AI Administrator and License Administrator can create policies and set limits, but cannot set or change the billing method. Only Global Administrator and Billing Administrator can.
The reporting is near real time, but not real time
The Consumption tab updates every 2 hours, Overview every 4 hours, across three dimensions: Users, Groups, Agents and services. In Azure Cost Management, consumption can take up to 24 hours to show up. Email alerting at a threshold exists and repeats weekly until the end of the month, but the threshold is something you set yourself — Microsoft documents no fixed percentages.
What this means for Entra Logic
The connection is direct and verifiable: Microsoft's AI budget control is implemented on top of security groups, with a fail-open conflict rule. Entra Logic's core claim is governed, approved and verifiable change to exactly those group memberships — with a coherent audit trail of who was added where, by whom, and on what basis.
That gives two concrete arguments. First: group hygiene is no longer just a security measure, it is cost control, and errors in it now hit the bottom line directly. Second: where Microsoft resolves conflict by choosing the most generous option, Entra Logic's starting point is that the action is hidden when the permission cannot be confirmed — secure by default.
Entra Logic today has built-in permission management and measurement tied to licensed products in the M365 estate, with cost allocated per company or customer in the same system that governs the identities behind the cost. Allocation of Copilot credits specifically is on the roadmap, not delivered — and should be described as such, in all customer-facing material.
The open, unresolved space is the cross-vendor perspective: Microsoft governs its credits, Anthropic governs its own (organization limits, limits per seat category and per user on Team and seat-based Enterprise), and neither of them keeps a single ledger across both. For a group with many subsidiaries, "one AI cost line across vendors, allocated per company" is an argument nobody in the competitor matrix covers today.
—
Sources
- Microsoft Learn — Manage AI experiences with usage-based billing and Copilot Credits
- Microsoft Learn — Usage-based billing and Copilot Credits overview
- Microsoft Learn — Compare dashboard views and the Azure bill
- Anthropic — Manage usage credits for Team and seat-based Enterprise plans
RELEVANT SOLUTION
See how this is handled in practice:
Norwegian version: Les artikkelen på norsk
Related reading
- No, NIS2 does not yet apply in Norway
Enterprise IT · 7 min
- After the acquisition: multi-tenant is not a transitional phase
Enterprise IT · 4 min
- One console, many tenants: what MSPs actually need from Entra ID tooling
Practice · 6 min