When Microsoft Provisioning Quietly Changes Who Owns Security Copilot

The quarterly access review had reached the part everyone usually treats as routine. The identity lead pulled the owner list for Security Copilot, expecting to see the two names from the original onboarding ticket.

There were eight.

She recognized most of them. The Security Administrator made sense, as did the two Global Administrators. The Intune Administrator was less obvious, although there was at least a reasonable connection to the platform. One name did not fit at all. It belonged to the Billing Administrator, whose work was Microsoft licensing renewals, and who had never used Security Copilot.

There was no approval record for his access. No request, ticket, or change record showed that someone had decided he should become an owner. His name appeared because of the way the platform had been provisioned.

A licensing change had resulted in owner rights over an AI system used by the security operations team.

What does an access-control model record when the platform itself creates the entitlement?

Microsoft documents the mechanism. Under the inclusion model for Microsoft 365 E5 and E7, eligible tenants are automatically provisioned for Security Copilot. No separate manual provisioning step is required. Microsoft also documents a set of existing Microsoft Entra and Microsoft Purview roles that inherit Security Copilot access as part of this model.

As currently documented, the Entra roles with owner access include Billing Administrator, Compliance Administrator, Global Administrator, Intune Administrator, and Security Administrator. Purview adds Compliance Administrator, Data Governance Administrator, and Organization Management. In Intune, the Intune Administrator role receives owner access, while other built-in and custom RBAC roles receive contributor access to Copilot in Intune. Microsoft describes these role mappings in Understand authentication in Microsoft Security Copilot, last updated June 4, 2026, and in Understand how Security Copilot is auto provisioned for eligible Microsoft 365 E5 and E7 customers, last updated June 18, 2026.

Microsoft's auto-provisioning guidance publishes a different list, which includes Conditional Access Administrator and does not include Billing Administrator. Validate the effective assignments in your own tenant rather than either published list.

Microsoft gives a practical reason for the design. Security Copilot is intended to retain at least two owners, which reduces the risk that an organization loses administrative access to the platform. The same documentation points administrators toward emergency access guidance.

The reasoning is understandable. The governance consequence is still significant.

A person whose job is to reconcile Microsoft licensing can end up with owner rights over the AI platform used by security analysts to investigate incidents.

Many organizations have spent the past year writing separation-of-duties rules for AI systems. Billing Administrator is unlikely to have been the role those discussions focused on.

Owner access does not, by itself, provide access to the underlying security data. It does provide control over parts of the platform, including capacity, plugin availability, tenant data-sharing settings, and workspace configuration.

Auto-provisioning also creates a default workspace and links it to the Security Copilot capacity. If workspaces already exist, Microsoft states that the earliest-created workspace becomes the default. Security Copilot experiences embedded across Defender, Entra, Purview, and Intune then use that workspace.

That matters in a tenant where someone created a workspace months earlier to test the product.

The test workspace can become the production default.

Its customer data storage location is preselected from the tenant's Entra geography during auto-provisioning. Microsoft also states that the data storage location cannot be changed after the workspace is created.

So an earlier test workspace can become the production default while carrying a data storage location that cannot later be changed and may never have gone through a production governance decision.

Every part of that behavior can be documented and deliberate at the platform level. The resulting ownership and configuration can still exist without a corresponding decision inside the organization.

The entitlement exists. The approval record does not.

That gap matters because most access-governance processes assume that a decision happened somewhere upstream. Someone requested access, someone approved it, and the entitlement was later reviewed to determine whether it was still appropriate.

Inherited platform access does not always follow that sequence.

During recertification, the reviewer sees an entitlement attached to a legitimate enterprise role. The role itself may be completely appropriate for that employee, so the entitlement passes review. The campaign closes successfully.

What may still be missing is any record showing that someone considered whether this person should own Security Copilot.

That is the Accountability Assumption in one of its cleanest forms. The control appears to be working because the entitlement is visible and reviewed. What the process does not establish is whether the organization ever made the decision that the entitlement represents.

The Tenant Agent Reconciliation Framework can be applied here to platform ownership as readily as it can to agents.

The exercise takes relatively little time. Pull the current Security Copilot owner and contributor list from the Security Copilot portal, then retrieve whatever your organization treats as the approved ownership record for the platform. In many tenants, that may be little more than the original onboarding ticket.

Put the two lists beside each other.

Every person who appears in the current configuration but not in the approval record needs a documented disposition. The access can be confirmed if someone with appropriate authority reviews it and accepts it. It can benarrowed where the inherited administrative role is broader than the person's actual need, using a more limited assignment or security group where appropriate. Microsoft itself recommends using groups rather than assigning administrative roles solely to provide Security Copilot access. The access can also be removed.

Record the disposition, the date, and the person who made the decision.

That reconciliation creates the artifact that was previously missing: evidence that the organization knowingly accepted the current ownership model.

The same exercise should be performed against the default workspace. Someone should be able to explain why that workspace is the default and who accepted its data storage location. If either setting resulted from automatic provisioning rather than an explicit production decision, that should be recorded as well.

Your recertification campaign may have closed last quarter with a clean result. It may have confirmed that the entitlement was still acceptable without ever establishing whether anyone intentionally granted that entitlement in the first place.

If the access arrived through licensing or platform provisioning, the same entitlement can pass the next review without that question ever being asked.