How do we audit which data Copilot Cowork agents reach during a task?

The Direct Answer

Use the Microsoft Purview unified audit log: every agent interaction is recorded as a CopilotInteraction event that captures the user, timestamp, host application, prompt and response identifiers, and — critically — the AccessedResources property listing each file, email, or site the agent touched, including its sensitivity label and access type.

Deeper Explanation

The audit trail for an agentic task is longer than the audit trail for a chat, and that changes how you read it. A single autonomous Cowork task can span dozens of retrievals, tool calls, and plugin invocations over its runtime, because the system is designed to execute complex, multi-tool work end-to-end rather than answer one question. Microsoft’s Purview audit documentation for Copilot and AI applications shows what each record carries: the AccessedResources property enumerates files, documents, and emails accessed with their sensitivity labels and whether access was read, create, or modify; AppHost tells you where the interaction ran; AppIdentity distinguishes which Copilot surface or agent acted; and admin operations like plugin creation and tenant-setting changes generate their own events. For Cowork specifically, the admin governance documentation confirms that agent activity, including browser-use tasks, lands in the unified audit log.

The practical challenge is reconstruction, not capture. Auditors do not ask “show me an event”; they ask “show me everything this task touched and why that was appropriate.” That means your audit procedure has to correlate the events belonging to one task, map accessed resources against the task’s business purpose, and flag mismatches — a labeled HR file accessed during a marketing-research task is a finding even though every individual permission check passed. Because agent retrieval is broad by design, GRC teams should define the review unit as the task, not the event, and sample tasks by risk: tasks run by users with wide permissions, tasks invoking third-party plugins, and tasks whose credit consumption was far above their expected tier (heavy retrieval is visible in cost data as well as audit data). Retention matters too: plan exports into your SIEM or archive if your evidence-retention obligations exceed your audit-log retention window.

A useful mental model: capture is Microsoft’s job, assurance is yours. The platform reliably writes the events; nothing in the platform decides whether a given retrieval was appropriate, whether your sampling was defensible, or whether your retention satisfies a regulator. That division explains where audit programs actually fail in practice — not missing events, but missing procedure. Teams enable Cowork, confirm records exist, and stop, leaving no documented reviewer, cadence, or exception path. Six months later an assessor asks who reviewed the Q3 agent-task samples and the honest answer is nobody. Writing the three-line procedure — who pulls the records, on what schedule, against what criteria — costs an hour and converts a raw log into an operating control. It also future-proofs you: as Cowork adds capabilities, the event types will evolve, but a procedure anchored on “reconstruct sampled tasks and compare access to purpose” stays valid across product changes.

The Research

• Microsoft Purview’s audit logs for Copilot and AI applications documents the CopilotInteraction record type, the AccessedResources property with sensitivity labels and access types, and admin events such as CreatePlugin and UpdateTenantSettings.
• The Copilot Cowork governance documentation (July 2026) confirms unified-audit-log coverage for Cowork tasks, including browser-based agent actions, alongside tenant controls for models, browsing, and quotas.
• Microsoft’s Purview guidance for Microsoft 365 Copilot maps the surrounding compliance stack — DSPM for AI, eDiscovery of Copilot interactions, retention policies, and Communication Compliance for AI interactions.

Strategy and Actionable Steps

1. Confirm auditing is on and scoped. Verify unified audit logging is enabled and that Copilot activity record types appear for your Cowork pilot users. Run one known test task and find its records before you claim coverage.
2. Build a task-reconstruction query. In the Purview Audit portal (or via export to your SIEM), filter on CopilotInteraction and related record types, then group by user and time window to assemble per-task views. Document this query as an audit procedure.
3. Define a risk-based sampling plan. Review 100% of tasks touching content labeled at your highest sensitivity tiers, plus a sample of ordinary tasks, plus every task flagged by cost anomalies. Write the plan down; samples chosen ad hoc are indefensible.
4. Map accessed resources to purpose. For each sampled task, compare AccessedResources against the task’s stated objective. Log exceptions and route them through your existing incident or exception process.
5. Align retention with obligations. Check your audit-retention entitlement against regulatory evidence requirements and export where there is a gap.
6. Add behavioral context around the audit log. Audit records tell you what an agent accessed; they do not tell you how users are working with Cowork in the flow of their apps. Clarity Connect 365 activates Microsoft Clarity behavior analytics — session recordings and heatmaps with username-to-session matching and admin-managed configuration — inside your Microsoft enterprise apps, giving compliance teams the usage-behavior layer that pairs with Purview’s access layer. 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 article on measuring real Copilot usage without surveys explains why observed behavior beats self-reported behavior for exactly this kind of assurance work, and their Copilot adoption guide covers rolling out governed usage patterns alongside the monitoring.

A note on tooling maturity: start with the Purview portal’s built-in search and graduate to SIEM export only when volume demands it. Teams that begin by building elaborate ingestion pipelines often stall for a quarter on plumbing while sampled manual reviews would already have been producing evidence. The audit obligation is met by a documented, repeatable review that actually runs — not by infrastructure. When export does become necessary, the earlier manual procedure becomes the specification for the automated one, and your evidence chain shows continuous operation across the transition, which is precisely the continuity story assessors want to see.

FAQ

Does the audit log show the actual documents Cowork read?

Yes. The AccessedResources property in Copilot interaction records lists the specific files, emails, and sites accessed, along with their sensitivity labels and whether the access was read, create, or modify. That is usually enough to reconstruct a task’s data footprint without capturing document contents.

Are Cowork’s browser-based actions audited too?

Yes. Cowork browsing tasks are logged in the unified audit log, and browsing itself respects your organization’s allowlist, blocklist, and view-only policies. Review those lists as part of audit scoping, since they define what the agent could have reached on the open web.

How long are Copilot audit records retained?

Retention depends on your audit licensing tier; records for some non-Microsoft AI app interactions are retained 180 days under pay-as-you-go. If your regulatory evidence obligations run longer than your entitlement, export to a SIEM or archive on a schedule and document the pipeline.

Can we search Copilot interactions in eDiscovery?

Yes. Copilot prompts and responses are stored in user mailboxes and are discoverable through Purview eDiscovery using Copilot-activity query conditions, which matters for investigations and legal hold as well as routine audit.

Do plugin and connector calls appear in the audit trail?

Plugin usage is tracked in Purview audit logs under Copilot activities, and admin lifecycle events such as creating or deleting plugins generate their own records. Third-party systems reached through a plugin keep their own logs, so cross-system reconstruction may require correlating both sides.

What is a red flag when reviewing a Cowork task’s audit records?

The classic pattern is scope mismatch: resources with sensitivity labels unrelated to the task’s business purpose, access volumes far above the task’s tier, or retrievals from sites the requesting team has no business relationship with. Every permission check can pass and the task can still be a governance exception.

Who should review Cowork audit data, and how often?

Assign a named reviewer in compliance or security with a documented cadence — weekly during pilot, at least monthly at scale — plus event-driven review when cost or DLP alerts fire. An unreviewed log is capture without control, and auditors treat it that way.

Can audit data prove a negative — that sensitive data was NOT accessed?

Reasonably, yes: if auditing was verifiably enabled for the period and the records show no access events against the labeled resource set in question, that is strong negative evidence. Pair it with a control test showing your audit pipeline captures known test accesses to pre-empt completeness challenges.