Copilot and Conditional Access Application Filters: Safe Setup

Official documentation checked October 14, 2026.

Microsoft Entra application filters can help manage Conditional Access scope, but there is no built-in “Copilot app filter” containing a universal list of Copilot clients. The documented filter uses custom security attributes assigned to resource service principals. It is not an appId equals condition for individual Copilot buttons in Word or Teams.

Use this guide to choose a defensible resource scope and, where appropriate, configure an attribute-based filter. Do not paste application IDs from an unverified example into a production security policy.

Distinguish Resources, Clients and Application Filters

Conditional Access targets resources that clients request, rather than directly applying to every native client application. Microsoft 365 services also have dependencies. Microsoft recommends the Office 365 resource grouping for consistent coverage of those services; it is not a Copilot-only selector.

The Client apps condition distinguishes client types such as browsers and mobile/desktop clients. A Filter for devices evaluates device attributes. Neither is the application filter described here. These controls answer different questions and should not be substituted for each other.

Record the actual resource and application identifiers from a representative sign-in. A similarly named enterprise app is not sufficient evidence that it covers every feature your users need.

Decide Whether an Attribute Filter Is Appropriate

Microsoft’s application-filter documentation uses string-valued custom security attributes. Attribute-definition and assignment permissions are separate from Conditional Access administration; Global Administrator alone does not automatically grant these attribute permissions.

If you want to protect the whole Microsoft 365 environment, start from the organization’s established resource-scope design instead of constructing a narrower Copilot exception. The Office 365 grouping itself is not a normal tenant service principal to which you can simply attach a custom attribute.

For a justified targeted policy, list the specific resource service principals, the reason each is included, its dependencies and the owner responsible for maintaining the list. Confirm Conditional Access licensing, any risk-based feature entitlement and the intended grant controls before configuration.

Create a Small Attribute-Filtered Pilot

1. Define the attribute. An authorized attribute administrator creates an approved string attribute and controlled value for this policy purpose. Use your organization’s naming standard, not a supposed Microsoft-reserved Copilot attribute.
2. Assign it to verified resources. In Entra enterprise applications, inspect each selected service principal and assign the approved custom security attribute. Keep a record of the object IDs and assigned values.
3. Create the policy. Under Conditional Access, create a named policy for a limited test group. Under Target resources, select resources and use Edit filter to match the attribute and value.
4. Set the intended controls. Choose the approved platform/client conditions and grant controls. Begin in report-only mode and retain the organization’s existing emergency-access arrangements.

Microsoft’s attribute assignment guide explains the enterprise-app management workflow. New apps are not covered merely because their names contain “Copilot”; your attribute assignment and policy match must actually include the relevant resource.

Test Coverage and Device Requirements

Test the required tasks separately: opening chat, using Copilot inside an Office app and opening a cited organizational file. Include an approved compliant device and an approved negative test that should be denied. Record which policy and resource were evaluated for each case.

If the policy requires a compliant device, check the actual compliance result and supported authentication flow. Enrollment, local domain membership and compliance are not interchangeable. Use the documented device-compliance policy guidance, including its lockout precautions.

A report-only result is evaluation evidence, not enforced protection. After the authorized owner enables the pilot, repeat the tests and verify both allowed and blocked cases before expanding scope.

Investigate Failures Without Adding Broad Exceptions

If the expected policy did not apply, check the resource, user assignment, attribute value and conditions against the event. If it applied and blocked access, inspect the unmet requirement. These are different failures.

Do not remove device compliance or MFA merely to make Copilot work. A second permissive policy does not override an applicable blocking policy. Follow Microsoft’s event-based troubleshooting procedure and have the policy owner approve any scope correction.

The goal is verified protection of the intended resources, not a policy that happens to contain “Copilot” in its name. If a targeted filter leaves an unexplained access path, keep the broader approved protection in place while investigating.