A folder of draft contracts has been shared with everyone in the company for two years. Almost nobody knew it was there. Then Copilot goes live, someone asks for the terms in the Northwind renewal, and the forgotten draft becomes the top cited source. Copilot did not bypass a permission. It followed one that had been left too broad.
Copilot can answer from content each user already accesses, which makes loosely shared material much easier to discover. The access isn't new, and accidental access still has no approved business purpose. Start with the data itself. Labels and DLP belong on top of a reviewed data foundation. As you work, maintain separate records for the finding, the owner's decision, temporary containment, the permanent repair, and the test that shows whether a saved policy is enforced.
Find, decide, contain, fix, verify
Every access signal moves through the same five steps, and skipping one is where audits go wrong:
- Find: a Data Access Governance (DAG) report or a posture assessment shows an observable access condition, with its date and scope.
- Decide: the accountable owner says whether that access is intentional. A DAG row is evidence of a condition, never evidence of intent.
- Contain: a temporary control limits exposure while you work.
- Permanently fix: you correct the permission, remove the stale link, move or archive the content, or record another approved outcome.
- Verify: you re-test with known documents and keep the evidence.
The two containment tools are easy to mix up. Restricted SharePoint Search (RSS) defines a curated allowed list: the small, reviewed set of sites Copilot may search during a pilot. Restricted Content Discovery (RCD) restricts discovery of a specific site or content you've identified as needing to stay out of reach. Neither one repairs a permission. RSS is "only search these." RCD is "keep this one hidden." Both leave the underlying access decision open until an owner makes it.
SharePoint Advanced Management frames the readiness work in five stages: Content Management Assessment, site lifecycle and archiving, preventing accidental oversharing, the SharePoint Admin Agent, and backup and restore. A site that's been backed up is not a site whose access has been reviewed.
How do you prove the boundary holds?
A boundary test needs more than an instruction to Copilot. "Only use approved sites" checks whether Copilot follows that sentence. It does not show whether the configured boundary excludes a source. Use two independent probes with unique facts in synthetic documents, then inspect every cited source as well as the answer:
- A positive probe asks for a fact that lives only in an approved document. It should return that fact and cite that source: proof the boundary isn't so tight it breaks legitimate use.
- A negative probe asks for a fact that lives only in an excluded document. That excluded source must not appear in the citations.
If the excluded source shows up, the run fails and pilot expansion stops: preserve the evidence, apply the planned containment, and re-run. A fluent answer that happens to omit the fact is not a pass. The excluded document appearing anywhere in the returned sources is a fail. This paired design is what separates "the boundary is configured" from "the boundary is enforced," and only the second one is safe to roll out on.
Labels and DLP: the Copilot-specific guardrail
Once the data foundation is honest, sensitivity labels and Data Loss Prevention (DLP) add a second layer, and they do different jobs. Blurring them is a common mistake. A sensitivity label states a handling requirement ("this is Confidential"). A DLP rule matches a condition, such as that label, and applies a control. A label on a file does not, by itself, stop Copilot from processing it. A DLP rule referencing that label is what does the blocking.
For Copilot, there's a specific, verified DLP location: Microsoft 365 Copilot and Copilot Chat. Three things about it matter. It's available through a custom template only. Selecting it disables every other location in that policy, so a Copilot DLP policy is not a general-purpose DLP policy: if you see SharePoint or Exchange still selected, stop and correct it before you test. It also supports four controls, two of which are preview: blocking sensitive info types in prompts (preview), blocking sensitive info types in web-search prompts, blocking files or emails with sensitivity labels from processing, and blocking external email from processing (preview).
Configuring it needs one of the verified roles, such as Microsoft Entra AI Admin or a Purview data-security or compliance admin. Use the least-privileged one, and keep the person who observes Copilot's behavior separate from the person who can change the policy.
One label behavior is worth knowing before rollout: as of a mid-2026 update, files the Microsoft 365 Copilot App generates inherit the highest sensitivity label from their source data. A summary built from Confidential inputs carries that label forward instead of downgrading it, which is a real reason to get your labels right on the source content before Copilot starts producing new files from it.
Keep finding, decision, control, and verification apart
Data Security Posture Management (DSPM) applies this same discipline at the tenant scale. The classic DSPM for AI experience (insights into AI activity, a weekly data-risk assessment of the top 100 SharePoint sites, custom assessments in preview, one-click policies, and compliance controls) is being replaced by the newer Data Security Posture Management experience. Two accuracy notes go with that: the weekly assessment covers the top 100 sites, not "everything in real time," and you can't classify a whole tenant as "classic" or "new" from a page title. When a task's generation is unclear, mark it unresolved and confirm it against current guidance rather than guessing.
DSPM uses four records here: Observe, Assess, Act, Verify. An oversharing risk assessment fills the first record. It starts an investigation but does not establish a breach or wrongdoing.
The owner decision comes next, for example, "former project members no longer need access." Only then can the approved control remove membership through the proper process. Verification remains pending until a follow-up assessment is compared with the baseline. A DSPM finding is not an owner decision. Selecting a policy does not show that exposure fell. Separate columns keep a discovery from being reported as completed remediation.
