Audit, Compliance, and Data Residency for Agents

Everything else in this level of the series is about preventing, detecting, or ranking risk before or as it happens. This final article is about the record left behind afterward — the evidence that lets an organisation prove, with confidence, exactly what an agent did and when.

1 · Beyond prevention: the need to prove

A control that blocks a bad action is valuable in the moment. But regulators, auditors, courts, and an organisation’s own leadership frequently need something different: a trustworthy record of what actually happened, produced after the fact, that can be searched, exported, and relied upon. That record is what this article covers, and it is just as essential to governance as any preventive control.

2 · Audit logs and eDiscovery

Audit logs record agent activities in detail — a running history of what each agent did, when, and to what. This is the foundation: without a complete log, there is nothing to search or export later.

On top of the log sits eDiscovery, sometimes described as content search: the ability to search and export an agent’s interactions to hold for legal, regulatory, and investigative needs. This is precisely the same capability organisations have long used to search employee email and documents during a legal matter, now extended to cover agent activity as well. If a regulator or a court needs to know what an agent did with a particular piece of data, eDiscovery is the tool that answers that question with evidence rather than a guess.

3 · Observability: the data underneath it all

Both audit logs and eDiscovery depend on data actually being collected in the first place, and that collection is called observability. Observability is the underlying runtime activity data that powers agent oversight and analytics across the organisation — the raw material everything else in this article is built from.

In the Microsoft 365 admin centre, this same observability data also feeds analytics for administrators: usage trends, performance signals, and overall agent health, helping teams understand how agents are actually being used, not just whether something went wrong. It is a shared foundation, powering both day-to-day operational insight and the audit trail needed for compliance.

4 · Built-in agents vs custom and third-party agents

Where an agent was built changes how its observability data reaches Microsoft’s systems, and this is a distinction worth knowing precisely. Agents built using Microsoft’s own development platforms include built-in observability support by default. If an organisation has an active licence or trial, agents built on these platforms automatically send their activity data in, and developers do not need to take any extra steps to enable it.

Custom or third-party agents are different: their developers must explicitly integrate with the observability system and choose to send activity data in. Having a licence alone does not make this happen automatically for agents built outside Microsoft’s own platforms. This matters practically: an organisation relying heavily on third-party or custom-built agents should not assume audit coverage is automatic — it depends on those agents having been deliberately wired up to report their activity.

5 · When data collection actually begins

A precise and important fact: agent activity data is not stored before an organisation begins a trial or purchases a valid licence and accepts the terms of use. Data collection starts at that specific point, not before. There is no background collection happening ahead of a customer’s actual decision to use the service.

Once collection is active, supported agents send data in a defined format covering specific kinds of events: an agent invocation (the agent being called to act), a tool execution (a tool the agent used), and an inference call (a call made to the underlying model). Knowing this timing matters for anyone reasoning about data governance: the moment of consent is also the moment the record begins.

6 · One data source, multiple consumers

The same observability data does not serve just one purpose. Microsoft Purview and Microsoft Defender both draw on this same agent activity data to power their own compliance monitoring, security analytics, and investigation scenarios. A single stream of well-formed activity data underpins the audit trail, the data-protection controls from earlier in this level, and the threat-detection capabilities covered before that.

This is the same design principle seen throughout this level: rather than each capability collecting its own separate data, one shared, well-governed source feeds many consumers. It is more efficient, and it means the record an auditor searches is the same record Defender used to detect a threat and Purview used to check compliance — one consistent truth, not three different accounts that might disagree.