Official documentation checked October 14, 2026.
To restrict Copilot for a security group, first decide whether you mean Copilot Chat, paid Microsoft 365 Copilot capabilities, or a particular application’s AI feature. These are not one interchangeable entitlement or one universal Entra enterprise application. Blocking an application found by name is not a reliable way to disable every Copilot surface while leaving all other Microsoft 365 services unaffected.
Plan a pilot with the relevant Microsoft 365 and identity administrators. Record the target group’s object ID, direct membership, current assignments, intended blocked experiences, and an unaffected control user before making changes.
1. Define the restriction and its coverage
Use an explicit acceptance statement, such as “members of the restricted group must not use work-account Copilot Chat, while other staff retain it,” or “remove the paid Copilot add-on from this licensing group.” Do not use “hide the button” as the acceptance test for either requirement.
Microsoft’s Copilot Chat management guidance distinguishes access restrictions from pinning. Unpinning does not revoke access, and a blocked user may still see a Chat entry that displays a policy message. The guide also advises against selective network blocking as a Copilot control because integrated Microsoft 365 applications can fail unpredictably.
List separately any requirements concerning personal-account Copilot, GitHub Copilot, custom agents, or AI features in other products. A work-account Chat restriction should not be represented as a complete prohibition of every service bearing the Copilot name.
2. Configure supported Chat and app access controls
Use the current Microsoft 365 admin controls applicable to your tenant. Microsoft documents group-specific Chat access restrictions, including for licensed users, across supported Chat experiences. Confirm that you are editing an access control, not merely deployment, pinning, or an agent’s availability. If the documented control is unavailable in your cloud or tenant, resolve that with Microsoft support rather than inventing an equivalent enterprise-app block.
For app assignments managed through Settings > Integrated apps, review the Copilot entry, its supported hosts, and both existing deployments and availability. The cross-application app guidance makes important distinctions:
- Edit users on a deployed app changes its preinstallation audience.
- The availability controls determine which users can install and use the app themselves; existing administrator deployments are not automatically removed.
- Block app is an organization-wide action for that app, not a deny rule for one selected group.
- Generic Integrated apps controls have host-specific scope; Teams settings require separate attention. Do not confuse these with a dedicated Copilot Chat access policy.
If a control asks for an allowed audience, enter the people who should retain access, not the group you intend to block. Review overlapping deployments and group memberships so the restricted users are not still included through another assignment.
Check group compatibility before relying on it. The Integrated apps documentation lists restrictions on nested groups and non-mail-enabled security groups. Do not assume that a security group accepted for licensing or Conditional Access is automatically accepted by every app-management control. Use a supported, reviewed audience without changing an established group’s purpose casually.
3. Remove paid Copilot entitlement separately when required
Removing a paid add-on is a licensing change, not proof that eligible baseline Copilot Chat access has also been blocked. Preserve the users’ underlying Microsoft 365, Exchange, SharePoint, and Office entitlements unless removing those is a separately approved goal.
If the target group is the actual source of the paid Copilot license:
- In the Microsoft 365 admin center, open Billing > Licenses and select the relevant Copilot product.
- Locate the exact licensing group and verify its affected users. Do not select a similarly named base-suite product.
- Following the group-license procedure, use the group’s more-actions menu to unassign that product only after reviewing the impact.
- Check processing results and each pilot user’s effective licenses. A separate direct assignment or another licensing group may still provide the add-on.
If the restricted group is only an organizational grouping, do not unassign a larger licensing group’s product from everyone. Have the licensing administrator design the intended assignment change and check overlaps first. Direct user assignments can be reviewed under Users > Active users > Licenses and Apps; Microsoft’s license-management instructions distinguish user and group sources.
Do not use “unassign all,” remove the base Microsoft 365 suite, or disable every connected experience as a shortcut. Those actions can affect services beyond the requested Copilot restriction. Licensing and membership processing are not guaranteed to finish in a fixed fifteen-minute window.
4. Validate the affected surfaces and preserve a rollback
After the intended changes have processed, test a restricted user and an allowed control user with their own accounts. Save work before starting fresh sessions. Check the actual operation, not just whether an icon remains visible.
- Try work-account Chat in the browser, Copilot app, Outlook, and Teams where those clients are in scope.
- Test the specific licensed Office capabilities named in your requirement separately from Chat.
- Confirm ordinary document access, email, and required business apps still work.
- Record mobile, Edge, personal-account, or custom-agent surfaces that need separate controls rather than claiming they were tested by implication.
When a result differs from the plan, inspect the user’s effective assignment, actual account, supported control scope, and applicable sign-in event. Do not escalate to a broad block on all Microsoft 365 resources. Restore the recorded pilot configuration if unrelated services are disrupted, then resolve the scope with the appropriate administrator.
Document the exact control, audience, exceptions, test results, and rollback owner. This produces a verifiable group restriction instead of an apparent success based only on a missing button or a single failed request.