Back to blog

M365 Copilot and the Case for a Permissions Audit

•5 min read

When Microsoft 365 Copilot reached general availability, the question from clients was never really "can it help us?" It was "is it safe to turn on?" My answer was consistent: not without a proper permissions review first.

AI does not create tenant risk from nothing. It makes existing risk visible and reachable in a way that a human clicking through folders for twenty minutes a day never could. Copilot answers questions using whatever the signed-in user already has permission to see across SharePoint, Teams, OneDrive, and Exchange. If that permission model has drifted — and in most tenants I have audited, it has — Copilot will happily surface things that were technically "shared" three years ago and quietly forgotten about.

Why Copilot inherits the sprawl, not just the data

This is the part that gets missed in rollout planning. Copilot is not a new access layer bolted on top of the tenant. It uses the Microsoft Graph and respects existing permissions — which sounds reassuring until you remember that "respecting existing permissions" is exactly the problem when those permissions have never been reviewed.

A document shared with "anyone in the organisation" during a one-off project in 2021 is still shared that way. A SharePoint site set up for a project that wound down eighteen months ago may still have forty people with edit access. Copilot does not know the project ended. It only knows what the access control list says right now, and it will summarise, search, and quote from anything that list allows.

What actually needs auditing before you switch it on

In practice, the audit breaks down into four areas:

  1. SharePoint sites. Check site-level and library-level sharing settings, not just individual file links. Look specifically for sites still set to organisation-wide or "anyone with the link" sharing, and for sites with no obvious owner left in the business.
  2. Teams. Review guest access settings, team membership against current org charts, and any Teams channels bridged to external tenants. Dormant teams with stale membership are a common source of exposure.
  3. Guest and external access. Pull a full list of active guest accounts and check each one is still a live business relationship. Expired projects and former contractors are the usual culprits.
  4. Legacy shares and personal OneDrive sprawl. Old "shared with everyone" links created before anyone thought about AI search surfacing them are the quiet risk — nobody remembers they exist until something finds them for you.

None of this is exotic. It is the usual gap between default settings and an actual security posture, the same gap I have found on every tenant I have reviewed, AI or no AI.

A short stepwise checklist

For an SME preparing to roll Copilot out, the sequence that works is:

  1. Export current sharing links and permissions across SharePoint and OneDrive — most tenants can do this through the admin centre or a scripted report.
  2. Flag anything shared organisation-wide or externally, and route each one to a named owner for a yes/no decision: still needed, or revoke.
  3. Review guest accounts against current contracts and projects; remove anything stale.
  4. Check mailbox forwarding rules and app consents — Copilot surfaces email content too, and forwarding rules nobody reviewed in months are a recurring finding.
  5. Re-run the export after remediation and keep it as your baseline, dated and stored somewhere traceable.
  6. Only then enable Copilot for a pilot group, and treat the first fortnight as a monitoring period, not a victory lap.

Governance that survives contact with users

The audit itself is not the hard part. The hard part is making the resulting policy stick once real people start using the tool day to day. Three things make that more likely:

  • Keep the policy short enough that someone can actually follow it without a training session. "Don't share folders organisation-wide; ask IT for named sharing" beats a twelve-page document nobody reads.
  • Review sharing settings on a schedule, not just once before launch. Permissions drift continuously; a one-off audit is a snapshot, not a control.
  • Make the evidence traceable. If you cannot show, six months later, what was reviewed and when, you do not have governance — you have a memory of having done something once.

The lesson

If Copilot is going to sit on top of the tenant, the tenant needs to be in decent shape first. That means permissions, logging, and a clear, current view of who can actually see what. Skip that step and the tool does not make your organisation smarter — it just gives everyone faster access to a system nobody fully understands.

If you are planning a Copilot rollout and want a straight answer on what your tenant would actually expose, that is exactly the kind of review covered on my services page — get in touch before you flip the switch, not after.