Maynor in the Cloud / Beyond the Tenant

Copilot does not have its own permission model. It answers using content the signed-in user is already entitled to open. That single fact is both the reassurance and the risk.

Part One — Leadership and Architecture

The business problem

For years most organizations have relied on a control nobody ever approved: discovery friction. A finance workbook sitting in a site with broken inheritance was technically readable by three thousand people, but nobody found it because finding it required knowing it existed.

Copilot removes that friction. A question in plain language returns whatever the user is permissioned to see, in seconds, with citations.

In the readiness work I have done across health care and financial organizations, the finding is consistent. In one financial organization assessment, overall readiness scored at roughly half of target. The weakest areas were data governance, information protection and content sharing. Identity and access controls were partially implemented. Exchange and core services were mature.

None of that was caused by Copilot. All of it was made visible by it.

Why the obvious approach did not work

“Turn it on for a pilot group and see what happens.” This assumes the blast radius is the pilot group. It is not. The blast radius is everything that group is permissioned to reach, which in most tenants is far wider than anyone has documented.

“Fix the permissions first, then deploy.” Directionally correct, practically fatal. A complete permissions remediation in a large tenant is a multi-year programme. Treat it as a prerequisite and Copilot never ships.

“Buy the security add-ons.” Licensing enables controls. It does not configure them. A label that is never applied protects nothing.

The approach that works is narrower: scope the surface, remediate what is in scope, prove it, then widen. Restricted SharePoint Search exists to make exactly this possible.

Figure 1. Discover, Classify, Protect — the readiness framework

Architecture decisions and trade-offs

Scope by container, not by user. Restricting which sites can ground responses is deterministic and reversible. Restricting licences is neither, because users share findings with colleagues.

The trade-off is that an allow-list creates a queue. Every business unit that wants their site added goes through a review. That queue is the control, but it needs an owner and a turnaround commitment, or it becomes the reason the programme is called a failure.

Labels before DLP. Rules that key off sensitivity labels are more stable than rules relying on content inspection alone. Labels also carry encryption, which continues to protect content after it leaves the tenant. The trade-off is that label rollout is change management, not configuration.

Ownerless content is a blocker, not a backlog item. A site with no owner has nobody to make an access decision. In every assessment I have run, ownerless collaboration spaces have been a meaningful share of the estate.

Audit before enablement. If the first interaction you can investigate is the one that caused the incident, you have no baseline.

Stakeholder alignment

Copilot readiness is not an IT project, and treating it as one is the most common cause of a stalled initiative. IT can configure controls. IT cannot decide whether the organization accepts the risk of a clinical or member-facing dataset being summarized on demand.

The most valuable artefact is the exception register. Every deviation with a named owner, a compensating control and a review date. Exceptions without those three fields are permanent by default.

Measurable outcomes

• Reduction in locations with organization-wide or anonymous sharing links
• Ownerless container count, driven toward zero
• Label coverage in scoped locations
• Scope growth rate, meaning how many locations move from blocked to permitted per month
• Copilot interaction audit coverage
• Adoption within scope, so security is not the only story

Lessons learned

The assessment is the easy part. Producing a readiness score takes days. Converting findings into funded, owned remediation takes months, and that conversion is where programs succeed or fail.

“Copilot found it” is a governance win if you frame it correctly. The first time Copilot surfaces something it should not, the instinct is to call it a product failure. It is not. It is a control gap being reported by the only system that was ever going to find it at scale.

Readiness scores age. A tenant that scored well six months ago has since accumulated new sites, new sharing links and new departures.

Do not let licensing drive sequencing. Licences purchased ahead of readiness gates create pressure to enable before controls are in place, and that pressure always wins.

Part Two — Deep Technical Layer

Current state and target state

Most tenants before remediation look the same. Sites created on demand with inheritance broken at library, folder and item level over several years. OneDrive accounts holding business-critical content shared through links nobody has audited. Teams-created sites whose membership has diverged from the underlying site permissions. Labels published but applied to a small fraction of content. DLP thorough in Exchange and partial everywhere else. Audit at default retention with no investigation runbook.

The target state for a controlled enablement is grounding restricted to an explicit allow-list of curated locations, every in-scope location with a named owner and a completed access review, labels applied through a combination of default policy, auto-labelling and user action, DLP scoped to the same locations, and audit retention aligned to the investigation requirement.

Dependencies and prerequisites

1. Licensing. Copilot, plus the compliance licensing required for auto-labelling, endpoint DLP and extended audit retention. Confirm which controls depend on which SKU before committing to a sequence.
2. Identity. Conditional Access enforcing MFA and device compliance for the resources Copilot reaches. Copilot honours the session, it does not create a separate one.
3. Container ownership. Ownerless sites must be resolved before they can be scoped.
4. Audit. Unified audit logging enabled, retention aligned to the investigation requirement.

Permission inheritance

The behaviour that causes most surprises is the interaction between three permission surfaces: the Microsoft 365 group behind a team, the SharePoint groups on the site, and item-level unique permissions created whenever someone shares a single document.

The failure pattern is consistent. A document is shared with a broad link for a legitimate short-term reason. The link is never revoked. The item now carries unique permissions that no longer inherit from the site. A later site-level tightening does not touch it, and site-level remediation reports show the site as clean.

Two things follow. Auditing at site level is insufficient, so item-level sharing reports are required. And “People in your organization” links are the ones that quietly widen Copilot’s reach, because every licensed user qualifies.

Labels, encryption and DLP

Labels operate at two levels and the distinction is frequently missed.

Item labels apply to files and emails and can enforce encryption and usage rights that travel with the content. Copilot honours those rights. If the user does not have EXTRACT rights on an encrypted document, its content will not be used to ground a response.

Container labels apply to sites, groups and teams and control privacy, external sharing and unmanaged-device access. They do not encrypt content and do not apply a label to items within.

The recommendation is a small taxonomy of three to five labels, container labels on all in-scope sites, auto-labelling run in simulation before enforcement, and DLP rules built on labels first and sensitive information types second.

The usage right that determines Copilot’s behaviour is EXTRACT. A label whose encryption grants a user VIEW but not EXTRACT allows that user to open the document and prevents its content being used to ground a response. This is the only mechanism that stops content the user can legitimately open from being summarized, and it is why encryption — rather than classification alone — is the load-bearing control.

Connect-IPPSSession
# Inspect which labels actually apply encryption, and with which rights.
Get-Label | Select-Object DisplayName, Name,
    @{n='Encrypted';e={ $_.EncryptionEnabled }},
    @{n='RightsDef';e={ ($_.EncryptionRightsDefinitions |
        ForEach-Object { "$($_.Identity):$($_.Rights)" }) -join ' | ' }},
    ContentType | Format-Table -AutoSize

A rights definition granting VIEW,VIEWRIGHTSDATA,DOCEDIT,EDIT,PRINT,EXTRACT,REPLY includes EXTRACT, so Copilot will use the content. Removing EXTRACT from the definition is what excludes it — at the cost of also preventing legitimate copy and paste, which is a business decision rather than a technical one.

Restricted SharePoint Search and scoped deployment

Restricted SharePoint Search limits organization-wide search and Copilot grounding to an explicit allow-list of sites, while users retain access to their own OneDrive content and to sites they have used recently. It is the single most useful control for shipping a governed pilot.

Connect-SPOService -Url "https://<tenant>-admin.sharepoint.com"
# Enable the restriction, then build the allow-list from reviewed sites only.
Set-SPOTenantRestrictedSearchMode -Mode Enabled
Import-Csv .\gate1-approved-sites.csv | ForEach-Object {
    Add-SPOTenantRestrictedSearchAllowedList -SitesListFileUrl $_.Url
}
# Confirm the effective mode and the current allow-list.
Get-SPOTenantRestrictedSearchMode
Get-SPOTenantRestrictedSearchAllowedList

Two behaviours to communicate before enablement. Users retain search over their own OneDrive and over sites they have interacted with recently, so the experience is not as restrictive as the configuration sounds. And content in excluded sites will be genuinely undiscoverable through Copilot, which users will report as a fault unless it has been explained as a deliberate control.

Identifying overshared and ownerless locations

Start with the built-in data governance and sharing reports for a baseline, then supplement where the native reports stop.

# Sites with no valid owner. These cannot be scoped until resolved.
Connect-PnPOnline -Url "https://<tenant>-admin.sharepoint.com" -Interactive
Get-PnPTenantSite -IncludeOneDriveSites:$false | ForEach-Object {
    $owners = @()
    if ($_.GroupId -ne [guid]::Empty) {
        $owners = Get-PnPMicrosoft365GroupOwner -Identity $_.GroupId -ErrorAction SilentlyContinue
    }
    if (-not $owners) {
        [pscustomobject]@{
            Url          = $_.Url
            Title        = $_.Title
            Sharing      = $_.SharingCapability
            StorageMB    = $_.StorageUsageCurrent
            LastModified = $_.LastContentModifiedDate
        }
    }
} | Sort-Object StorageMB -Descending | Export-Csv .\ownerless-sites.csv -NoTypeInformation
# Confirm Copilot interactions are being recorded before enablement, not after.
Connect-ExchangeOnline
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
    -RecordType CopilotInteraction -ResultSize 500 |
    Select-Object CreationDate, UserIds, Operations |
    Export-Csv .\copilot-interactions.csv -NoTypeInformation

The Graph equivalent for the ownership sweep, where the PowerShell modules are restricted:

GET https://graph.microsoft.com/v1.0/groups?$filter=groupTypes/any(c:c eq 'Unified')
    &$select=id,displayName&$expand=owners($select=id,userPrincipalName)&$top=999

Filter the response for groups where the owners collection is empty, then correlate with the connected site URL.

Failure conditions and troubleshooting

Investigation

The investigation runbook needs to answer four questions: what was surfaced, to whom, from where, and under what permissions. The audit record answers the first two directly; the third and fourth require correlation.

Connect-ExchangeOnline
# Retrieve interactions for a specific user over an incident window,
# and expand the accessed-resource detail from the audit payload.
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
    -RecordType CopilotInteraction -UserIds "user@corporate.example" -ResultSize 1000 |
    ForEach-Object {
        $d = $_.AuditData | ConvertFrom-Json
        foreach ($r in $d.CopilotEventData.AccessedResources) {
            [pscustomobject]@{
                When        = $_.CreationDate
                User        = $_.UserIds
                App         = $d.CopilotEventData.AppHost
                Resource    = $r.Name
                SiteUrl     = $r.SiteUrl
                Sensitivity = $r.SensitivityLabelId
                Action      = $d.Operation
            }
        }
    } | Export-Csv .\incident-interactions.csv -NoTypeInformation

Then correlate each SiteUrl against the sharing report to establish why the user had access. In practice the answer is almost always a sharing link or an item-level permission rather than a site-level grant, which is what makes the item-level sharing report the second half of the runbook.

Validation and rollback

The recommendation is a canary approach. Place synthetic content carrying representative sensitive patterns in locations with known permission configurations. Run a scripted prompt set as a scoped test user and record which canaries are surfaced. Confirm every surfaced canary produced an audit record, and that labelled and encrypted canaries were excluded as designed.

Re-run after each scope change. This becomes the regression suite.

Rollback must be defined before enablement, in this order:

5. Remove the location from the allow-list. Fast, and does not alter permissions.
6. Remove the user from the licence group.
7. Revoke sharing links and restore inheritance. Most invasive, most likely to break legitimate access. Never the first move.

Closing position