Do we need a Conditional Access policy just for Microsoft Copilot?

You’re right to put identity in front of the AI door. The confusion is whether Copilot needs its own Conditional Access pet policy — or whether you’ve already locked the house.

Here’s what’s going on. Microsoft documents that Microsoft 365 Copilot honors Conditional Access and MFA the same way other Microsoft 365 services do: if your policies require MFA, compliant devices, or risk-based controls for Microsoft 365 access, those signals apply when users sign in to use Copilot. Zero Trust guidance for Copilot Chat (web-grounded work/education chat) says at minimum configure CA for MFA for all users and trusted/healthy devices, and for E5 add risk-based MFA and high-risk user password change. For Microsoft 365 Copilot (work-grounded), the same identity-and-access step applies before you worry about oversharing amplification. Microsoft’s broader CA advice prefers covering All resources / Microsoft 365 with a small, well-named policy set rather than one fragile policy per product — there’s a tenant limit (hundreds of policies) and token behaviour means apps you forget can fall through. Copilot Studio agents can also fail for end users when CA blocks token acquisition for the agent/channel — so “Copilot works for admins” isn’t proof your maker apps are covered. Report-only mode, emergency-access exclusions, and What If remain the safe rollout habits.

Steady before scale is Pane 04 first: identity hygiene beats an AI-branded CA policy that duplicates MFA you already enforce. Schofield’s Third Law (historically attributed) still holds — once authenticated on a weak device, Copilot makes sensitive content easier to find.

Options that actually work:

1. Validate existing M365 / All resources CA covers Copilot sign-in paths, then close gaps (legacy auth block, device compliance, risk) in report-only before enforce. Best Steady default for most tenants.
2. Add a named Copilot/AI-focused policy only if you must carve a different grant (e.g. stricter device rules for a VIP pilot group) — keep it short, owned, and tested with What If. Use sparingly.
3. Create a dozen “Protect Copilot” policies that restate MFA. Policy sprawl; lockout risk; little extra protection.
4. Assume CA stops oversharing inside Copilot. It doesn’t — CA guards who gets in; Graph permissions, labels, DLP, and Restricted Content Discovery govern what grounding sees.

12 Panes action / comms: Tell Security: Copilot inherits Entra CA — prove coverage with sign-in logs and What If, don’t invent parallel theatre. Tell the AI board: Wave 0 identity is MFA + healthy devices; then Purview and oversharing. Users: same sign-in bar as the rest of Microsoft 365 — if your laptop isn’t trusted, Copilot shouldn’t be either.

Benefits / risks: Reusing solid CA avoids AI-exception holes; Copilot Studio and Edge page-summarisation scenarios have extra knobs (Edge policies, channel auth) that a single “Copilot app” target may miss. Exclude break-glass accounts; never block All resources without understanding Graph side effects.

I’d suggest this week: pick a test user, run What If against Copilot/Microsoft 365 sign-in under your current policies, fix any gap in report-only for seven days, then enforce. You’ll have Steady identity under the AI programme without a decorative Copilot-only CA policy.

DIGITAL SKILL WORKS LTD / 12 PANES · You ask, we answer