The Inheritance Problem: Auditing What an AI Assistant Can Reach Before You Switch It On

In many UK organisations, the rollout of an AI assistant is treated as an adoption programme first and an access-control programme second. That ordering is understandable — the productivity case is easy to demonstrate — but it is also where operational risk accumulates. When Microsoft 365 Copilot is enabled for a user, it does not create a new data universe. It reads what that user can already reach. The difficulty is that "already reach" is frequently broader than anyone intended. Shared drives, legacy SharePoint sites, Teams channels with inherited membership, mailboxes with delegated access: the assistant inherits all of it.

The audit question for 2026 is not whether the assistant is capable. It is what the assistant has been given clearance to see.

Inheritance is not a permission model

An AI assistant does not grant new rights. It respects the permissions already in place — group membership, sharing links, mailbox delegation, sensitivity labels and the underlying directory. But respect for existing permissions is not the same as least privilege. Many UK estates have accumulated access over years: project sites that were never archived, Teams channels that grew beyond their original purpose, shared mailboxes that several teams can read. The assistant makes that accumulated access legible. It can summarise a document a user did not know existed, surface an old email thread, or answer a question using content from a site the user had forgotten they could open.

That is not a breach in the conventional sense. It is a discoverability problem that becomes a data protection problem when sensitive content is summarised, quoted or forwarded. The assistant is doing what it was permitted to do. The organisation has to decide whether the permission was appropriate in the first place.

A permission-first audit in four passes

A permission-first audit starts with the pilot population and works outward. It is deliberately narrow: the aim is to prove control in a defined group before scaling.

First pass: define personas, not names. Group pilot users by role, location and data domain — for example, finance business partners, HR advisers, service desk team leaders. Record the groups, sites and mailboxes each persona is expected to need. This becomes the approved content set for testing.

Second pass: map reachable content. For each persona, list SharePoint sites, Teams channels, OneDrive accounts, shared mailboxes and any connected line-of-business systems. Include sharing links and guest access. Do not rely on the assistant's own reporting; use the Microsoft 365 admin centre, Purview and directory group membership as the source of truth.

Third pass: classify what the assistant could expose. Apply existing sensitivity labels, data loss prevention policies and retention rules. If a site contains special category data, financial results before announcement, or individual case notes, it should be marked and its membership reviewed before licensing.

Fourth pass: reconcile expected and actual. Compare the approved content set with what the assistant can actually cite. Any content outside the set is an exception. Exceptions need an owner, a remediation date and a decision about whether to remove access, remove the licence, or accept the risk with a documented rationale.

Testing for over-reach with a short script

A practical test does not require a red-team exercise. It requires a repeatable script that a systems team can run with a test identity. The script below is deliberately simple; the point is the comparison, not the sophistication of the query.

For each pilot persona:
  create a test identity with identical group membership and mailbox delegation
  enable the assistant licence for that test identity
  run five known-item searches, such as:
    "redundancy consultation"
    "salary band"
    "client contract renewal"
    "incident review"
    "board paper"
  record whether each item is returned, cited or summarised
  compare each result against the persona's approved content set
  flag any result outside that set as over-reach
  capture the prompt, response and citation in the audit log

The script should also check mailbox delegation and Teams private channels, because these are common sources of inherited access that line-of-business managers do not see. Where the assistant can summarise content from a private channel the test user should not read, that is a finding. Where it can cite a document from a site with an open sharing link, that is also a finding.

Purview audit logs and eDiscovery can provide the evidence trail. The test should be repeated after remediation to show that the exception has been closed.

What the data protection officer and risk committee need to see

The evidence pack should be short and verifiable. It should include the persona definitions, the access matrix, the test results, the exceptions register, remediation dates and a named sign-off. It should not be a vendor questionnaire or a generic statement that the assistant "respects permissions". The committee needs to see that the organisation has tested the claim.

Under UK GDPR and the Data Protection Act 2018, the relevant questions are familiar: what personal data is processed, on what lawful basis, and what technical and organisational measures control access. The ICO's guidance on AI and data protection reinforces the need for accountability and for understanding how personal data is used. An AI assistant that can summarise HR case notes or finance commentary is processing personal data, even if the user did not explicitly ask for it.

The DPO should also see how prompt and response logs are retained, who can review them, and how employees have been informed. In unionised or regulated environments, that may require consultation before the pilot begins.

Least-privilege pilot checklist

• Define pilot personas by role, location and data domain; record the approved content set for each.
• Review SharePoint site membership and sharing links; remove broad groups such as "Everyone except external users" where they are not justified.
• Check Teams channel membership, including private channels and shared channels with external tenants.
• Review mailbox delegation, shared mailboxes and calendar permissions.
• Apply sensitivity labels and DLP policies before enabling the assistant licence.
• Limit connectors to approved systems; do not connect a pilot to an unclassified data source.
• Log prompts and responses for the pilot period, subject to employment law and consultation requirements.
• Set a stop rule: any confirmed over-reach pauses rollout until the exception is closed.
• Give pilot users a simple route to report a surprising or inappropriate result.

The year-end question

By December 2026, many UK boards will ask for assurance that AI assistants are under control. The weakest answer is a usage dashboard showing prompts per user. The stronger answer is a permission map, a test script with recorded results, and an exceptions register with owners and dates. The assistant's clearance is the organisation's clearance. Auditing it before switch-on is cheaper than explaining it afterwards.