Copilot has no permissions of its own. It sees exactly what the signed-in user can already see — so security-group membership is the control. This traces six people against the same document, and shows exactly which gate stops each one.

The containment model

A document sits inside a library, inside a site. The site and library decide who can reach the file. What Copilot may read back is decided on the file itself — which is why two documents in the same folder, with identical permissions, can have opposite exposure.

SITE — sites/QC who can reach it: QC_Reader
LIBRARY — Loan Files who can reach it: LoanFiles_Reader · identical for both files
PROTECTED
Smith-Loan-File.docx
label: Confidential-CreditFiles (encrypted)
Copilot may extract for: CreditFiles_Extract members
✓ everyone else: blocked
NOT PROTECTED
Jones-Loan-File.docx
label: none — no gate exists
Copilot may extract for: ANY LoanFiles_Reader
✗ CreditFiles_Extract ignored
same site · same library · same permissions · opposite Copilot exposure

Both files sit in the same folder and are governed by the same two groups. The only difference is the encrypted label on the left-hand file — and that single difference decides whether Copilot will read the contents back. Protection is a property of the file, never of the library that holds it.

This is the failure mode to watch for. A library can be correctly permissioned, sit behind the right groups, and still leak through Copilot — because one file in it was never labelled. Nothing in the SharePoint interface makes that difference visible while you are looking at the folder.

Six users, one document

All six work at the bank. The gate each one fails determines both what they can do and what Copilot can do for them — and the last two show that identical permissions can still produce opposite outcomes.

User Gate 1 · Licence
Copilot_User
Gate 2 · Site
QC_Reader
Gate 3 · Library
LoanFiles_Reader
Gate 4 · Extract
CreditFiles_Extract
Result
User A
Branch teller
✗ not a member
STOPPED HERE
never evaluated never evaluated never evaluated cannot open the file
User B
Marketing
✓ member ✗ not a member
STOPPED HERE
never evaluated never evaluated cannot open the file
User C
QC analyst
✓ member ✓ member ✗ not a member
STOPPED HERE
never evaluated cannot open the file
User D
Loan officer
✓ member ✓ member ✓ member ✗ not a member
STOPPED HERE
opens file,
Copilot blocked
User E
Credit officer
✓ member ✓ member ✓ member ✓ member Copilot extracts
User F
same rights as D
✓ member ✓ member ✓ member NO GATE EXISTS
file has no label
Copilot EXTRACTS

Gates 1–3 decide whether the file is reachable. Fail any one and the user cannot open it — later gates never evaluated. Gate 4 is different: User D opens the document normally; only Copilot is refused. Users D and F have identical group membership. D is protected, F is not — because F's file was never labelled.

Each gate is a security-group membership. Users A, B and C never reach the file at all — once a gate stops them the remaining gates are never evaluated. User D reaches it and opens it, and only Copilot is refused. User E clears everything. User F has exactly the same group memberships as User D, yet Copilot extracts freely — because the file User F opened was never labelled, so the fourth gate does not exist for it.

Read D and F together. Same person profile, same groups, same library — opposite exposure. The difference is not a permission. It is whether someone applied the encrypted label to that particular file.

The group does nothing on its own

Gate 4 only exists because the document carries an encrypted label. Remove the label and the gate disappears — along with any protection the group appeared to provide.

NO ENCRYPTED LABEL
Any user past gates 1–3— no gate 4 →Copilot extracts
CreditFiles_Extract membership is irrelevant — nothing to gate
ENCRYPTED LABEL APPLIED
Any user past gates 1–3— gate 4 exists →EXTRACT right? checked per user
CreditFiles_Extract membership now decides the outcome

The label is the lock; the group is the key list. A key list without a lock protects nothing — and this is the single most common mistake when configuring Copilot restrictions.

Order of operations matters. Apply the encrypted label first, then grant VIEW + EXTRACT to the group in the label's encryption settings, then manage membership. Doing it in any other order produces a group that looks like a control and enforces nothing.

Membership decides the outcome

Security groupControlsUser A · TellerUser B · Credit officer
Copilot_UserHas Copilot at allmembermember
QC_ReaderCan reach the sitemembermember
LoanFiles_ReaderCan reach the librarymembermember
CreditFiles_ExtractEXTRACT right on encrypted contentnot a membermember
Can open the documentYesYes
Copilot can extract from itNoYes

What to actually do

TO STOP COPILOT EXTRACTING FOR A USER
  1. Apply the encrypted label Confidential-CreditFiles to the document or set it as the library default.
  2. In the label's encryption settings, grant VIEW + EXTRACT to CreditFiles_Extract only.
  3. Ensure the user is not in that group.
  4. Result: they keep normal access; Copilot returns nothing from the file.
TO LET COPILOT EXTRACT FOR A USER
  1. Add the user to Copilot_User so they have Copilot.
  2. Add them to QC_Reader for the site.
  3. Add them to LoanFiles_Reader if that library has its own permissions.
  4. Add them to CreditFiles_Extract for the EXTRACT right.
Put groups in SharePoint, never people. Add the security group to the site's Members or Visitors group once, then manage everything by editing group membership in Entra. Access changes become logged, reviewable, and reversible in one place — and an access review can actually see them.

The blind spot: files that cannot be labelled

Sensitivity labels only attach to Office formats and PDF. A .csv, .txt, .xml or .zip cannot carry one — so gate 4 can never exist for it, and no DLP policy can withhold it either.

.docx .xlsx .pptx .pdf licencesitelibraryEXTRACT right 4 gates available
.csv .txt .xml .zip .tif licencesitelibraryno such gate — cannot be labelled 3 gates only — permissions are all you have

For unlabelable formats the fourth gate does not exist and cannot be created. Whether Copilot reads the file is decided entirely by whether the user can open it.

Why this matters in a bank. Core-banking exports, ACH files, reconciliation dumps and report extracts are overwhelmingly CSV and TXT — and they are among the most NPI-dense content in the tenant. That is exactly the category labels cannot protect.
PERMISSIONS, INCLUDING PER-FILE
  1. Break inheritance on the individual file or its folder.
  2. Grant only the group that should hold it.
  3. Copilot cannot read what the user cannot open — this is the one free, file-level control.
CHANGE THE FORMAT
  1. Save the .csv as .xlsx.
  2. It becomes labelable, so the encrypted label and gate 4 apply normally.
  3. Free, and usually the right answer for recurring exports — fix it at the source system.

For the CISO: where least privilege has to be strictest

ContentControls availableIf permissions are wrong
Office & PDF
.docx .xlsx .pptx .pdf
Permissions and encryption label — two independent controls Contained. The label still withholds content from Copilot.
Everything else
.csv .txt .xml .zip .tif
Permissions only — single point of failure Unmitigated. Nothing else stands between the file and Copilot.
Copilot changes the consequence of a permissions mistake. An over-permissioned .csv used to sit in a folder nobody browsed — technically exposed, practically invisible. A natural-language query now surfaces it on demand to anyone holding a licence. The permission did not change; its discoverability did. Copilot does not create misconfigurations, it converts latent ones into active ones.

This inverts the usual instinct. Teams protect the important-looking Office documents and leave the machine-generated extracts loose — yet the extracts are where a permissions error has no backstop, and in a bank they are frequently the most NPI-dense content in the tenant.

Control standard for content that cannot be labelled

  1. Inventory it. Identify unlabelable files in every Copilot-reachable site. You cannot restrict what you have not enumerated.
  2. Segregate it. Put extracts in dedicated libraries with broken inheritance, not mixed into general document libraries where they inherit broad site access.
  3. Grant narrowly. One purpose-built group per extract library, smallest possible membership. Never the site's default Members group.
  4. Fix it at the source. Have the originating system emit .xlsx instead of .csv. The file becomes labelable and defense in depth is restored — usually a report-configuration change, not a project.
  5. Review it quarterly. Entra ID P2 access reviews are already licensed here. Point them at these groups first.
  6. Or keep it out. If an extract has no reason to live in SharePoint, move it somewhere Copilot does not index.

What does not control Copilot

Four things that are commonly assumed to restrict Copilot and do not.

  • A label without encryption. Marking a file Internal or Confidential classifies it for reporting. It does not stop Copilot reading it. Only encryption with a withheld EXTRACT right does that.
  • Labelling more files. Raising classification coverage improves posture reporting. It changes nothing about who can reach what.
  • DLP policies in simulation mode. They alert; they do not block.
  • Hiding a site from navigation. Copilot follows permissions, not menus. Unlinked does not mean unreachable.

Applies to Microsoft 365 Copilot in SharePoint and OneDrive. Group names shown are a recommended convention; substitute your own. Encryption behaviour verified in a production tenant, 2026-07-29.