Microsoft Copilot security:
the pre-flight checks to run before you switch it on

Microsoft Copilot for Microsoft 365 is a significant capability — and a significant risk if it's enabled in an environment where data permissions haven't been reviewed. The fundamental issue is straightforward: Copilot surfaces information based on what a user can access. If a user can access something they shouldn't — a SharePoint library they were added to three years ago, a Teams channel they joined once and forgot about, an email thread they were CC'd onto — Copilot will happily surface it in response to a query.

The risk isn't hypothetical. It's been observed in early deployments: a staff member asks Copilot to summarise "recent documents about the restructuring" and receives a summary that includes a confidential HR document they technically had access to but weren't meant to see. The permissions were technically correct; the access was practically wrong.

Before you enable Copilot — or if you've already enabled it and haven't done this work — here are the checks that matter.

1. Identity and access foundations

Copilot's output is bounded by a user's permissions. If your access control is weak, Copilot amplifies that weakness — it makes over-permissioned access much easier to exploit, even accidentally. The first check is your identity baseline.

Multi-factor authentication: Copilot is available wherever a user is authenticated. If MFA is absent or inconsistently applied, a compromised credential gives an attacker not just email access, but an AI-assisted data trawl of everything that user can reach. MFA — particularly phishing-resistant MFA using FIDO2 keys or Microsoft Authenticator — must be in place across all users before Copilot is deployed.

Conditional Access policies: Check that Conditional Access policies are configured to restrict Copilot to managed, compliant devices. An unmanaged personal device with a user's credentials is a meaningful risk — Copilot outputs can be copied, shared, or screenshot in ways that a traditional document access might not be.

Privileged accounts: Ensure that high-privilege accounts have restricted Copilot access. There's no reason for a Global Administrator to use Copilot from their administrative account. Check your Privileged Identity Management (PIM) configuration.

2. SharePoint and OneDrive permissions

This is typically the largest gap. SharePoint permissions accumulate over time — libraries shared broadly at initial creation and never reviewed, sites with Everyone access applied, documents shared externally that no longer need to be. Copilot doesn't distinguish between "has permission" and "should have permission".

Broadly shared sites and libraries: Run a SharePoint access review. Look specifically for sites shared with "Everyone" or "Everyone except external users" — these grant access to all authenticated users in your tenant. Any sensitive content in these locations is effectively accessible to Copilot for every user.

Abandoned site collections: Project sites, team sites, and SharePoint spaces created for one-off purposes but never decommissioned. These often contain significant information — HR data, financial projections, strategic documents — with permissions that reflect the situation at the time of creation rather than now.

External sharing: Review which content has been shared externally and whether those sharing links are still required. External sharing links don't affect Copilot's behaviour directly, but they represent content that may be insufficiently controlled — a useful signal that the overall permissions picture needs attention.

3. Data classification and sensitivity labels

Microsoft Purview sensitivity labels are the primary mechanism for applying persistent, policy-enforced classification to content in Microsoft 365. If you don't have a working sensitivity label taxonomy in place, Copilot will have no basis on which to treat different content differently.

Labels should be configured to encrypt the most sensitive content automatically — so that even if a user has access to a document, Copilot cannot summarise or extract from it without the appropriate permissions being explicitly granted through the label policy. This provides a meaningful backstop when access controls are imperfect.

Review your label taxonomy before enabling Copilot. If you have labels that are applied inconsistently or only to a small fraction of your content, the protection they offer is limited. A label-first approach to Copilot deployment is significantly more defensible than retrofitting labels after a data exposure event.

4. Data Loss Prevention policies

DLP policies in Microsoft 365 can be configured to restrict what Copilot does with certain content — preventing it from summarising or including sensitive information in outputs sent outside a defined boundary. Review your existing DLP policies and consider what additional policies you need specifically for Copilot-generated outputs.

Common additions include policies preventing Copilot from including content classified as Highly Confidential in outputs shared to external recipients, or policies that flag when Copilot outputs contain personal data or financial information above a defined threshold. These policies don't replace good permissions management, but they provide a meaningful control layer on top of it.

5. Audit logging and monitoring

Before you enable Copilot, verify that your Microsoft 365 audit logging is switched on and that you have a process for reviewing Copilot-specific events. Microsoft logs Copilot interactions — what was prompted, what data was accessed, what was returned — and this log data is critical for incident investigation.

If you have a SIEM or security monitoring capability, make sure Copilot audit events are flowing into it. An organisation that enables Copilot without monitoring has made itself harder to investigate if something goes wrong, because the evidence of what happened is in a log that nobody's watching.

6. Copilot-specific configuration

Microsoft provides administrator controls for Copilot that allow you to restrict certain plugins, control which connectors are enabled, and configure the scope of data that Copilot can access. Review these settings in the Microsoft 365 Admin Centre and the Copilot admin settings before enabling broad rollout.

Consider a phased rollout — start with a pilot group of users who have a well-understood data access profile, and use the first phase to validate that your permissions and DLP configuration is working as expected before extending access organisation-wide.

The order of operations matters

The temptation is to enable Copilot quickly — the business case is compelling, the technology is impressive, and the pressure to deploy AI tools is real. But enabling Copilot before completing these checks doesn't just create a data exposure risk; it creates one that's difficult to detect and difficult to remediate, because by the time you know something has gone wrong, the exposure has already occurred.

The right order is: identity controls first, then data classification, then permissions remediation, then DLP, then monitoring, then Copilot. It's more work upfront. It's substantially less work than explaining a data incident to your board.