AI Access Exposure Review: Copilot Readiness and SharePoint Oversharing, Measured

Most enterprise file estates have a second layer of protection that nobody designed and nobody documented. Finding a document required knowing it existed, knowing roughly where it lived, and being willing to scroll. Keyword search was poor and folder names were opaque. That practical difficulty did real work. It kept a large amount of content effectively out of reach of people who were, on paper, entirely permitted to open it.

Microsoft has now written this down more plainly than any security vendor has. Its Core Infrastructure and Security Blog, published on 23 July 2026, states that the friction of manually locating and correlating documents “was never designed as a formal security control,” but that it “did create a practical limit on how quickly users could surface and act on organizational data at scale.” The same article supplies the sentence this whole subject turns on: “Copilot makes data once hidden by volume discoverable by intent.”

That is the platform vendor describing its own product removing a protection that its customers did not know they were relying on. It is worth putting in front of a board precisely because it is not a consultant’s opinion. The same post is equally careful about what does not change. Copilot “does not grant new permissions,” and is instead “a force multiplier that makes existing access faster and easier to discover, aggregate, and act on.” Both halves matter, and a page that claims an assistant breaks permissions will lose a security architect in its first paragraph.

The underlying idea is much older than generative AI, and its pedigree is useful in a room that is tired of AI-specific alarm. Saltzer and Schroeder set out the open design principle in 1975: “The mechanisms should not depend on the ignorance of potential attackers, but rather on the possession of specific, more easily protected, keys or passwords.” Content that was safe only because it was hard to find was depending on exactly that ignorance. Their least privilege principle, that “every program and every user of the system should operate using the least set of privileges necessary to complete the job,” is the actual remedy, and it is a permissions remedy rather than an AI one.

This is why the engagement is a measurement rather than a policy exercise. Nobody currently knows how much of the estate was protected by obscurity, because obscurity leaves no audit trail and appears in no report. The only way to find out is to ask, as each kind of user, and record what comes back.

Nothing in the permission model changes when you connect an assistant. What changes is how much of it one person can exercise in an afternoon.

It helps to be exact about which layer moves. The access control list on a file is unchanged. The group memberships are unchanged. What changes is the cost, in seconds and in prior knowledge, of converting an entitlement into a document on screen. An assistant is an index plus a natural-language interface over that index, and an index is indifferent to how obscure a folder name is.

The OWASP GenAI LLM Top 10 for 2026 states the mechanism without euphemism in its sensitive information disclosure entry: “unscoped drives, legacy permissions, and knowledge bases feed RAG with sensitive data the model then retrieves as designed.” The phrase worth dwelling on is “as designed.” Nothing is malfunctioning. That is the problem, and it is why the remedy has to be a permissions and content-location remedy rather than a guardrail bolted onto the output.

MITRE ATLAS records the same behaviour as an observed adversary technique rather than a theoretical risk. AML.T0085, Data from AI Services, notes that agents “may be configured to have access to tools and data sources that are not directly accessible by users,” and its RAG Databases sub-technique observes that a prompted retrieval “can include the majority of an organization’s internal documents.” ATLAS also names the repositories explicitly: its Data from Information Repositories technique lists SharePoint and Confluence by name.

Microsoft is candid that the starting position is permissive rather than restrictive. Its Copilot readiness documentation says that “by default, SharePoint sets sharing settings to the most permissive option,” and its own worked example of the problem is an unsecured budgeting site that Copilot surfaces because “most people don’t know about this site, so the site owner hasn’t set up proper permissions.” That example is instructive because it is mundane. It is not an attack. It is a site that worked fine for years for exactly one reason.

The practical consequence for a deployment plan is that readiness cannot be assessed from the licensing side. A tenant can be perfectly configured from an identity, device and data-loss-prevention standpoint and still have an assistant that returns the wrong document to the wrong person on day one, because the defect was written into a folder in 2019 by someone who has since left.

This is the first thing a competent IT director says, and it deserves a serious answer rather than a rhetorical one. The statement is true. The assistant surfaces only content the signed-in user is already permitted to open. Two things make it an insufficient defence.

The first is exercisability. A permission that is theoretically available and practically dormant is not the same risk as a permission that can be exercised in one sentence, at scale, across every repository at once. Risk models are built on likelihood as well as impact, and this change moves likelihood by orders of magnitude without moving a single access control entry. Microsoft describes the same effect from its own side: years of accumulated oversharing “can turn long-standing governance debt into immediate exposure.”

The second is aggregation, and it is the argument that actually settles the discussion. OWASP’s 2026 entry treats synthesis across individually-permitted sources as a disclosure event in its own right: combining budget, hiring and diligence material into a pending acquisition target “is a disclosure when policy prohibits the synthesized conclusion.” NIST reaches the same place from the privacy direction, warning in its Generative AI Profile that models “may be able to correctly infer PII or sensitive data that was not in their training data nor disclosed by the user by stitching together information from disparate sources.”

There is a governance corollary that closes the last escape route. A common response is that a summary is not the document, so a summary of restricted material is a lesser event. The joint CISA, NSA and FBI guidance on AI data security says the opposite, and says it as a design rule: “the output of AI systems should be classified at the same level as the input data (rather than creating a separate set of guardrails).” If the input was restricted, the summary is restricted. Treating the summary as a workaround is precisely the pattern that produces a disclosure nobody logged.

For a clinical-stage company the aggregation case is not abstract. A persona who can legitimately see the study-team site and the corporate-development site can ask a single question that touches integrity of the blind and material non-public information at the same time. Neither entitlement was wrong on its own. The combination was never assessed, because until now nobody could perform it in one step.

The assistant only shows people what they can already see. That is a true sentence and it is not a reassuring one.

Permission sprawl is not one failure. It is six that compound, and Microsoft documents every one of them. Understanding which of the six dominates in your tenant determines whether remediation is a two-week clean-up or a structural project, which is why the review classifies findings by cause rather than only by severity. Microsoft’s own summary of the phenomenon is worth keeping in mind throughout: “most internal oversharing stems from configuration issues rather than malicious user intent.”

Inheritance is the root of most of it. Permissions flow from site to library to folder to file, and the moment anyone breaks inheritance a new independent scope exists that no site-level review will ever surface. This is not a hypothetical: Microsoft’s indexing documentation describes computing an effective access control list for each individual file, gathering identifiers at every level, precisely because the declared hierarchy is not the real one.

Link-based sharing then creates access outside the group model entirely. Microsoft describes three link types, and is blunt about the sharpest of them: people using an “Anyone” link “don’t have to authenticate, and their access can’t be audited.” That single sentence should end any discussion about whether such links belong in a regulated tenant. The same document notes that external sharing is turned on by default for the organisation.

The built-in “Everyone except external users” claim, usually shortened to EEEU, is the quietest of the six because it can be invisible at site level. Microsoft warns that “sharing with EEEU can lead to unintended data exposure because it grants access to all current and future employees,” and explains that setting a single file or folder as public “makes it accessible to your entire organization, while keeping the rest of the site private.” A site that looks correctly restricted can contain a file that everyone hired next year will also be able to read.

The remaining three are structural. Nested groups accumulate and decay, and Microsoft notes that nested security groups “can cause performance issues and are not recommended.” Over-entitlement builds up over a career: Microsoft’s risk-surface post describes users accumulating “access far beyond their current role through leftover project permissions, broad temporary group memberships, and inherited rights.” And ownerless sites are so normal that Microsoft ships an entire policy family for them, covering site ownership, inactive sites and attestation, which is the strongest evidence available that they are the ordinary state of a mature tenant rather than an anomaly.

Before anyone is engaged, Microsoft publishes a checklist that costs nothing to apply and that will tell a competent administrator whether this page describes their tenant. These are the six signals Microsoft uses to classify a site as high risk in its Copilot readiness guidance. Reproduced here because they are a better starting point than any vendor questionnaire, and because a company that finds none of them may genuinely not need this engagement.

Applying the list is a matter of running the Data Access Governance reports that ship with SharePoint Advanced Management, which is bundled with the Copilot licence. The report family includes the site permissions baseline, site permissions for individual users, EEEU activity and sharing-link activity. Microsoft describes the baseline report in exposure language of its own: it “helps you understand your organization’s overall access exposure.” The Content Management Assessment provides the guided version of the same exercise.

Two honest caveats belong with the checklist. The first is coverage. The default Purview data security posture management assessment runs weekly against only the top 100 SharePoint sites by usage, with item-level scanning capped at 10 sites and 200,000 items per location. Buyers routinely mistake this for tenant-wide, and the sites that matter most in a biotech are often not the busiest.

The second is counting. Microsoft’s permissioned-user figures are not deduplicated. Its own documentation states that “if the same user has both direct and indirect permissions, they’re counted multiple times,” and gives a worked example totalling 80 permissioned users for a folder with 40 group members, 10 direct grants and 20 link-based grants, with no deduplication applied. Microsoft’s own 2025 blog claims the report deduplicates group membership; the product documentation contradicts the marketing post, and the documentation is what the product does. Any headline figure of the form “N users can see this” has to be resolved against actual transitive group membership before it goes near a report or a board.

Generic data-security material talks about “sensitive documents.” That abstraction is why these conversations stall. In a clinical-stage or newly commercial life-sciences company the exposed material has names, owners and regulatory consequences, and naming it is usually the moment the discussion becomes concrete for a chief executive who has just been asked whether the assistant is safe.

On the clinical side: unblinded interim analyses and randomisation schedules held in a study-team site; correspondence with contract research organisations and investigator sites containing subject identifiers; serious adverse event narratives and pharmacovigilance case files; data safety monitoring board materials. Each of these has a defined audience that is much narrower than the site membership that has grown around it, and integrity of the blind is not a control you can restore after it has been queried.

On the manufacturing and regulatory side: batch records, deviations and corrective actions; specifications and technology transfer packages; investigational new drug and clinical trial application content; correspondence with health authorities; pre-publication data. This is the material where a permission finding becomes an inspection finding, because the applicable rules require both restriction and evidence of restriction rather than intent.

On the corporate side, and this is the layer a Part 11 auditor cares about least and a board cares about most: term sheets, diligence rooms, headcount and reduction plans, compensation bands, and the employee-information files that a human resources team keeps in the same platform as everything else. At a clinical-stage biotech client, during a first engagement, connected AI reached employee-information files in Box through existing user permissions. No control was bypassed and no vendor defect was involved. Existing permissions, existing files, a new way to ask.

The pattern worth noticing is that the highest-consequence findings are rarely in the systems that receive the most governance attention. Validated systems are usually well controlled, because they were built under a quality system and someone signs for their access lists. The exposure sits in the general-purpose collaboration layer beside them, where study teams, regulatory affairs and corporate development all put working copies of the same material.

Nothing starts until there is a signed authorisation letter naming the systems in scope, the personas, the date window, the approver, and an explicit statement that no production content leaves the tenant. Testing is performed only against systems the client owns or is explicitly authorised to test. Professional liability and cyber insurance are in force.

The scope document is deliberately short, because a scope nobody reads is not a control. It names the repositories, the assistant or assistants under test, the persona list, the date window, the named approver, the escalation contact for an unexpected finding, and the handling rule for anything discovered that falls outside scope. That last item matters more than it sounds: an exposure review reliably finds one thing nobody expected, and the time to agree what happens then is beforehand.

There is also a structural constraint that shapes the whole engagement, and it comes from Microsoft rather than from us. Its site access review documentation states that “compliance reasons prevent IT administrators from accessing file-level or item-level details.” If your own administrators are correctly barred from item-level detail, an external consultant reading files is not a superior arrangement. The method therefore has to prove reach without reading content, which is what step four is for.

The engagement makes no changes to your environment. Remediation is a separate, deliberate step that your team approves and executes, and the re-measurement afterwards is what demonstrates it worked.

The first pass costs nothing and uses tooling you already have. Run the Content Management Assessment, the Data Access Governance report family, and a Purview data risk assessment. This produces the site shortlist, and it does so without a single query being issued.

The report family is specific: the site permissions baseline, site permissions for individual users, Everyone-except-external-users activity, and sharing-link activity. Microsoft describes the baseline in exposure terms itself, saying it “helps you understand your organization’s overall access exposure.” Where SharePoint Advanced Management is licensed, which it is with a Copilot licence, this is available today and most tenants have never run it.

Then the correction that almost nobody applies. Microsoft’s permissioned-user counts are not deduplicated. Its documentation states that “this number isn’t unique. If the same user has both direct and indirect permissions, they’re counted multiple times,” and provides a worked example totalling 80 for a folder with 40 group members, 10 direct grants and 20 link-based grants. Microsoft’s own 2025 blog claims the report deduplicates group membership. The product documentation contradicts the marketing post. We trust the documentation and resolve every headline count against actual transitive group membership before it appears in a finding.

This step also establishes the coverage boundary honestly. The default Purview risk assessment covers only the top 100 SharePoint sites by usage, item-level scanning caps at 10 sites, and each location caps at 200,000 items. In a biotech, the sites that matter are frequently not the busiest. Where the platform cannot see, we say so in the report rather than implying the absence of a finding is the absence of a problem.

The agreed list is four to six roles for a standard engagement. They are selected to span the three variables that actually change what an assistant returns, rather than to cover the organisation chart evenly.

Tenure is the first axis, and the eight-year veteran is almost always the interesting case rather than the new starter. Microsoft describes the mechanism: users accumulate “access far beyond their current role through leftover project permissions, broad temporary group memberships, and inherited rights.” A persona representing someone who has changed function twice inside the company will usually out-reach a director hired last year.

Function is the second. Clinical operations, chemistry manufacturing and controls, regulatory affairs, quality, finance or corporate development, IT, and an external contract research organisation guest each traverse a different part of the estate. The guest persona matters disproportionately, because guest access is one of the sharing constructs the permission-aware indexer does not support, and it is where the mismatch between the declared and enforced model is widest.

Group topology is the third and least obvious. Someone who is a member of many nested groups behaves differently from someone in few, and nesting is where both over-reach and silent under-reach originate. We also include at least one departed-employee-shaped account where the client can provide one: still enabled, still in its groups. Wherever possible we use dedicated test accounts provisioned into the same groups as the persona rather than impersonating real staff, which keeps the evidence clean and keeps a named person’s audit trail out of the report.

The most exposed persona in a life-sciences company is rarely an executive. It is usually the long-serving operations manager who has been added to everything and removed from nothing.

Every prompt lives in a versioned file, and the same prompts run against every persona so that results are comparable rather than anecdotal. There are three tiers, each answering a different question, and the distinction between them is what makes the output a measurement rather than a demonstration.

Canary queries ask for material that provably should not be reachable by that persona. Summarise the unblinding plan for a named study. Find the current quarter headcount plan. What is in the diligence folder. A hit is the finding, and because the expected answer was defined before the query ran, there is no interpretive argument about whether the result is significant.

Category sweeps are non-leading prompts across the regulated categories: subject identifiers, serious adverse event narratives, batch deviations, health authority correspondence, term sheets, salary bands, and credentials held inside documents. That last one is worth its own mention. MITRE ATLAS records credential harvesting from retrieval databases as an observed technique, noting that credentials “may be stored in internal documents which can inadvertently be ingested into a RAG database, where they can ultimately be retrieved by an AI agent.” Sweeps find the categories nobody thought to protect because nobody thought they were there.

Aggregation probes deliberately ask for a synthesis across sources the persona is individually entitled to see. This is the tier that tests the case OWASP added, and it is the tier that most often produces the finding a chief executive reacts to, because the individual permissions are all defensible and the conclusion is not. It is also the hardest tier to remediate, which is a good reason to know about it before deployment rather than after.

The prompt set is shared with the client in advance. There is no value in surprising your own security team, and a prompt set that has been reviewed by the people who know the business produces better canaries than one written by an outsider.

This is the part that makes the method defensible in a regulated tenant, and it uses a documented Microsoft capability that most practitioners have never read. It is also the direct answer to the question every general counsel asks first: how do you test this without your consultants reading our data?

Purview audit records for the CopilotInteraction operation carry an AccessedResources property containing, in Microsoft’s words, “references to all resources (files, documents, emails, etc.) which Copilot accessed in response to the user’s request.” For each resource the record holds an identifier, a Name, a SiteUrl described as “the URL of the resource that was accessed. This could be the URL of a SharePoint site, full file path of a file,” an Action, a Status, a SensitivityLabelId, PolicyDetails where a policy blocked or restricted access, and XPIADetected indicating whether a cross-prompt injection was detected from that resource.

The consequence is that we can prove which regulated file a given persona retrieved, and what sensitivity label it carried, from the audit log alone. No file is opened. No content is exported. No screenshot of protected health information is taken. Microsoft even notes that its own documentation labels the SensitivityLabelId field as “helpful in identifying whether Copilot accessed any sensitive information while generating its response,” which is precisely the use we are making of it.

Two further fields make the evidence attributable in ways a report needs. AgentId and AgentName mean that agent-mediated retrieval can be attributed to a specific agent rather than to a general assistant, which matters as organisations deploy department-specific agents. And AISystemPlugin.Id carrying the value BingWebSearch separates public web grounding from tenant grounding, so a response that looks alarming is not misattributed to internal content it never touched.

Prompts, audit records and resource metadata are recorded. Response bodies are redacted. Where a hit requires human confirmation that the retrieved item is what the metadata suggests, that confirmation is delegated to the content owner inside your tenant, which is also the compliance-correct route given that administrators are barred from item-level detail.

The audit record is the evidence. The document stays closed.

Conflating these is the most common analytical error in this work, and the reason many internal attempts produce a list that cannot be acted on. Every hit falls into exactly one of three categories, and Microsoft’s own documentation supplies the language to tell them apart.

A permission defect means the persona genuinely holds access control list access it should not have. The fix is in SharePoint, Box, Egnyte or the identity provider, and it belongs to a content owner rather than to IT. This is the category people expect, and in a mature tenant it is frequently not the largest.

Index staleness means the source permission was already corrected but the index still serves the old access control list. The fix is a resync with the permissions option, and the verification is a re-run of the identical prompt afterwards. Reporting this as a permission defect sends a site owner to look at an access list that is already correct, which destroys their trust in the entire report.

Discoverability-only means retrieval is currently blocked but the item remains indexed and would return again if a discovery control were removed or expired. This is the category that most needs to be flagged rather than closed, because it will silently reopen. It is also where the Restricted Content Discovery propagation window bites: a control applied last week on a large site may not be in effect yet.

There is a fourth observation that is not a hit at all but belongs in the report. Agent-mediated reads do not appear in SharePoint’s user-facing accessed-by and recent-files surfaces. Any internal process that relies on those surfaces to detect unusual access has a blind spot for exactly the access pattern being introduced. That is a HIPAA §164.312(b) audit-controls observation with a named remedy: use the Purview audit record as the evidence source.

The measurement is only half the value. The other half is a delta: the same prompt set, the same personas, run again after remediation, so that the organisation can say what changed rather than what was recommended.

Remediation is delegated to site and content owners through site access reviews, which is both the scalable path and the compliance-correct one, because owners can see the item-level detail an administrator cannot. There are limits to plan around and they are published: reviews can be initiated for up to 100 sites directly from the report interface, with PowerShell required above that, and up to 1,000 site access reviews per calendar month from the site-permissions report. An estate with several thousand sites needs a prioritisation model, not an intention.

Where a discovery control is the right answer rather than a permission change, the propagation window has to be respected. On a site with more than 500,000 items, Microsoft says a Restricted Content Discovery update “could take more than a week to fully process.” We schedule the re-measurement after the window, not before it, and we say so in the plan.

Then the same versioned prompt set runs again. The delta is the deliverable: findings closed, findings still open, findings that changed category, and new findings introduced by the remediation itself, which does happen when a permission change moves content rather than restricting it. This is also the artefact that makes the work repeatable annually, or before each new assistant or agent is connected, which is the point at which the whole measurement becomes an operating practice rather than a project.

What we do not do is leave you with a monitoring tool to buy. The output is a state of the estate at a date, a set of closed findings, and a repeatable method. If continuous posture management is the right answer for your size and risk, the report says so and names what it would need to cover, including the coverage limits documented above.