How can GRC teams prove Copilot Cowork isn’t over-reaching into sensitive data?

The Direct Answer

Prove it with layered evidence: audit records showing exactly which resources each agent task accessed and their sensitivity labels, DLP and sensitivity-label policies that demonstrably block restricted content, posture reports from AI security tooling showing over-sharing was found and remediated, and documented control tests where deliberately planted sensitive content was not retrieved.

Deeper Explanation

“Prove a negative” becomes tractable when you decompose it into positive control assertions. You cannot directly demonstrate that an agent never saw anything it shouldn’t; you can demonstrate that (1) preventive controls existed, (2) detective controls were complete, and (3) observed behavior stayed inside policy. On the preventive side, Microsoft’s Purview capabilities for Microsoft 365 Copilot give you testable mechanisms: sensitivity labels with encryption prevent content from being returned to users without extract rights, DLP for AI restricts processing of prompts carrying defined sensitive information types, and DSPM for AI surfaces over-shared content with recommended policies. Each produces configuration evidence an auditor can inspect and — more persuasively — behavior you can test: plant a labeled canary document, run a task that should not reach it, and file the null result.

On the detective side, completeness is the argument that wins. Purview’s audit logs for Copilot interactions record every agent interaction with an AccessedResources property listing the files, emails, and sites touched, including their sensitivity labels and access types. If auditing is verifiably enabled for the whole period, and periodic reviews of those records show no access to restricted label tiers outside approved purposes, you have a genuine evidence chain: capture was complete, review was performed, exceptions were zero or were handled. The remaining gap is behavioral: logs show what the agent accessed, not whether users are delegating tasks in risky ways in the first place — vague, over-broad task instructions are the upstream cause of over-broad retrieval. That is why mature programs pair access evidence with usage-behavior evidence, an approach VisualSP describes in its piece on measuring real Copilot usage without surveys: observed behavior, not attestation, is what closes the loop.

Anticipate the completeness challenge, because a competent auditor will raise it: “your evidence shows what was logged — how do you know everything was logged?” The answer has three prongs. First, capture verification: run known test accesses periodically and show each appears in the audit log, demonstrating the pipeline works end-to-end. Second, configuration attestation: show auditing was enabled tenant-wide for the entire period, with change records proving nobody turned it off. Third, perimeter honesty: state plainly which activity falls outside the tenant log — chiefly the interior of third-party systems reached through connectors — and show the compensating controls, a default-deny plugin catalog and vendor-side log review for high-sensitivity connectors. Evidence packages that acknowledge their boundaries survive scrutiny; packages that imply omniscience invite the one counter-example that discredits the whole submission.

The Research

• Microsoft Purview’s data security guidance for Microsoft 365 Copilot documents the preventive stack — DSPM for AI, DLP for AI prompts, sensitivity-label enforcement, Insider Risk Management’s risky-AI-usage template, and Compliance Manager’s regulatory templates.
• The Purview audit documentation details CopilotInteraction records whose AccessedResources property captures each accessed file with its sensitivity label and access type — the raw material for over-reach testing.
• Microsoft’s Cowork governance documentation (July 2026) confirms agent tasks, including browser actions, are captured in the unified audit log and are bounded by tenant browsing policies, model controls, and quotas.

Strategy and Actionable Steps

1. Define “over-reach” operationally. Write the policy sentence first: which label tiers, data categories, and repositories are out of scope for agent tasks, for whom, under what exceptions. Without this, no evidence can prove compliance with anything.
2. Baseline with DSPM for AI. Run posture assessment, remediate the over-sharing it finds, and archive the before/after reports — auditors weight remediation evidence heavily because it shows the control loop actually operates.
3. Deploy canary tests. Seed labeled test documents in plausible locations, run representative Cowork tasks quarterly, and record that the canaries were not retrieved (or that label enforcement blocked their return). This is your strongest direct evidence of non-over-reach.
4. Operate a task-level audit review. Sample tasks risk-weighted by user permission breadth, plugin involvement, and credit-consumption anomalies; compare AccessedResources against task purpose; log and disposition exceptions.
5. Assemble the evidence pack. Policy, configuration exports, DSPM reports, canary results, review minutes, exception dispositions — one folder, refreshed quarterly, mapped to your control framework.
6. Add behavior-layer visibility. To see how people actually work with Cowork inside your Microsoft apps — where risky delegation habits form — Clarity Connect 365 activates Microsoft Clarity behavior analytics (session recordings, heatmaps) inside Microsoft enterprise apps with username-to-session matching and admin-managed configuration, giving GRC a defensible behavioral evidence stream alongside Purview’s access records. Microsoft Clarity is Microsoft’s free, self-serve behavior-analytics tool, and Clarity Connect 365 is VisualSP’s enterprise integration that adds what free Clarity lacks — deployment into Microsoft enterprise apps, username-to-session matching, and admin-managed configuration. VisualSP’s Copilot adoption guide covers pairing that visibility with governed rollout practices.

Calibrate the evidence effort to your regulatory exposure. A firm under model-risk or privacy supervision should run the full stack — canaries, quarterly samples, DSPM reports, behavioral analytics — because the cost of an unsupported assertion is a formal finding. A lower-exposure organization can defensibly run the same architecture at lower frequency: annual canary tests, semi-annual samples, exception-driven review in between. What does not scale down is the structure itself: some preventive control, some completeness-verified detective control, some behavioral signal, all documented. Regulators and auditors forgive modest cadence; they do not forgive missing layers discovered after an incident.

FAQ

What single piece of evidence do auditors find most convincing?

Control testing with negative results: a documented canary exercise showing planted sensitive content was not retrieved, or was blocked by label enforcement, during representative agent tasks. It demonstrates operating effectiveness directly, where configuration screenshots only demonstrate design.

Can Purview audit logs prove completeness of capture?

Support it, yes: show auditing was enabled throughout the period, then run a known test access and show it appears in the log. That capture-verification test plus unbroken retention is the standard completeness argument; export to a SIEM if your evidence obligations outlast the retention window.

What if a Cowork task accessed sensitive data but the user had permission?

Treat it as a purpose-limitation exception, not an access violation: permissions passed, but scope did not. Disposition it through your exception process — was the retrieval relevant to the task? Should the user’s permissions or the site’s sharing be narrowed? This distinction is exactly what task-level review exists to catch.

Does restricting plugins help prove non-over-reach?

Materially. Every disabled or group-scoped plugin removes an external data path the evidence otherwise has to cover. A default-deny plugin catalog with documented purposes shrinks the assertion surface an auditor has to test.

How often should over-reach testing run?

Quarterly canary tests and audit-sample reviews are a defensible cadence for most organizations, tightened to monthly during pilot phases or after material changes — new plugins, new user populations, or new model families with different retention behavior.

Can Insider Risk Management detect risky agent usage?

Purview’s Insider Risk Management includes a risky-AI-usage policy template that flags patterns such as prompt-injection attempts and risky interactions. It adds a behavioral detection layer on top of DLP’s content rules, useful for the cases where each individual action looks permissible.

How do we prove browsing tasks didn’t reach prohibited sites?

Cowork browsing honors your Edge allowlist, blocklist, and view-only policies, and browser tasks are logged in the unified audit log. Evidence is the policy export plus sampled browser-task records showing destinations within policy.

What do we do about models that retain prompts with the provider?

Document it. Some available models retain user prompts and responses with the model provider; admins can disable model families where that conflicts with policy. Either the restriction or the accepted, documented risk belongs in your AI data-flow register — silence is the audit finding.