Audit, Compliance, and Data Residency — Agent 365: Governance and Security

Good agent governance is not only about stopping the wrong thing before it happens. It is also about being able to explain, later and with evidence, what an agent did, which data it touched, which tools it used, and when the record began. That proof comes from audit logs, electronic discovery, observability data, and the service commitments that govern where collected data is handled and stored.

From control to proof

Preventive controls matter because they reduce risk in the moment. Access rules, data labels, threat detection, and policy templates can stop or limit harmful behavior. But auditors, regulators, courts, security teams, and executives often ask a different question after the fact: what actually happened?

That question cannot be answered by intent, architecture diagrams, or a developer's memory. It needs a trustworthy record. For agents, that record must show activity at runtime: the agent being used, the tools it called, the model interactions it triggered, and the surrounding context needed to investigate the event.

This is the quiet part of governance. It does not look as dramatic as blocking an attack, but without it an organization cannot prove compliance, reconstruct incidents, or respond confidently to legal requests.

📌

Proof is a control. An audit trail is not just paperwork; it is the evidence layer that makes agent governance defensible.

Preventive controls reduce risk in the moment; a trustworthy record proves what actually happened later.

Audit logs and electronic discovery

Audit logs are the running record of agent activity. They capture details about what an agent did and when it did it, giving administrators and investigators a factual trail to follow. Without complete logging, later search and export are limited because the evidence was never collected.

Electronic discovery, often shortened to eDiscovery, is the legal and compliance capability used to search, review, and export relevant content. In Microsoft Agent 365, agent interactions can be searched and exported for legal, regulatory, or investigative needs, extending a pattern organizations already know from employee email, documents, and collaboration records.

The practical value is simple. If a regulator asks whether an agent used a sensitive document, or a legal team needs to preserve interactions related to a matter, the organization should be able to produce evidence rather than guess.

Observability is the data underneath

Audit and electronic discovery depend on observability. Observability means the runtime activity data collected from systems so that operators can understand behavior, diagnose problems, measure usage, and investigate events. In the agent world, it is the raw material that feeds oversight and analytics.

The same observability foundation can support several views. An administrator may use it to understand agent usage, performance, and health in the Microsoft 365 admin center. A compliance team may use it through Microsoft Purview. A security team may use related signals through Microsoft Defender. An investigator may rely on it through audit and discovery workflows.

This shared foundation is important. If each tool built its own separate version of reality, teams could spend more time reconciling records than investigating facts. A common activity stream gives the organization a more consistent account of agent behavior.

A shared observability stream feeds four different oversight tools instead of four rival versions of reality.

Built-in agents and third-party agents do not report the same way

How observability data reaches Microsoft's systems depends on how the agent was built. Agents built with Microsoft's own development platforms, such as Foundry, Copilot Studio, and Agent Builder, include built-in observability support by default. If the organization has an active trial or license, these agents send activity data automatically without extra developer work.

Custom and third-party agents are different. Their developers must explicitly integrate with the observability system and choose to send activity data. A license alone does not cause an externally built agent to report activity automatically.

This distinction is easy to miss and important in practice. An organization may believe it has audit coverage because the tenant is licensed, while some custom or third-party agents remain outside the activity stream because their developers never wired them into observability.

⚠️

Check coverage. For custom and third-party agents, audit coverage depends on explicit observability integration, not merely on having a service license.

Microsoft-built agents report automatically; custom and third-party agents must be wired in deliberately.

When collection begins, and what it records

The timing is precise. Agent activity data is not stored before an organization starts a trial or buys a valid license and accepts the terms of use. Collection begins at that point. There is no pre-license store of agent activity waiting in the background.

Once collection is active, supported agents send data in a defined format. The format covers the main runtime events needed to understand agent behavior: the agent being invoked, a tool being executed, and a call being made to the underlying model.

That start line matters for compliance. The moment of customer acceptance is also the moment the evidence record begins. Anything that happened before collection was active is not available later as stored agent activity data in this system.

Agent invocation: the agent is called to act.
Tool execution: the agent uses a tool to perform a task or retrieve information.
Inference call: the agent makes a call to the underlying model.

Data residency is part of the evidence design

Data residency is the question of where data is stored and, depending on the service commitment, where it is processed. For agent observability, residency belongs in the same conversation as audit and compliance because the evidence itself is data that may be subject to legal, contractual, or regulatory location requirements.

The safe rule is to treat observability data as governed service data, not as an informal diagnostic by-product. Once collected, it may be used by audit, discovery, compliance, security, and administrative analytics. That makes its handling important to privacy, retention, access control, and regional governance decisions.

The exact residency and data-handling commitments for Microsoft Agent 365 observability should be checked in the current Microsoft service description and data handling documentation. This article should not be read as a substitute for those terms, because residency requirements are both jurisdiction-specific and contract-specific.

📌

Residency is evidence governance. If observability data is used as evidence, where it lives and who can access it are compliance questions, not operational afterthoughts.

Decisions leaders and practitioners should make

The practical work is not only turning on a product. Leaders and practitioners need to decide what level of evidence is required, which agents must be covered, who may search or export records, and how audit data fits existing legal, security, and privacy processes.

For Microsoft-built agents, the main task is confirming licensing, terms acceptance, and administrative readiness. For custom and third-party agents, the work is more explicit: require observability integration, test that events arrive, and document the boundary if an agent cannot or will not report activity.

A useful governance test is to pick a real scenario and walk backward from the question an auditor might ask. Can the team show that a specific agent was invoked? Can it show which tool was used? Can it search and export relevant interactions? Can it explain when collection began and where the resulting data is governed?

Require an inventory of agents and mark which ones report observability data.
Verify that third-party and custom agents have explicit observability integration.
Define who can access audit logs and who can run electronic discovery searches.
Align retention, privacy, and data residency reviews with the treatment of observability data.
Test investigations before an incident or legal request forces the issue.

Key takeaways

Governance needs proof after the fact, not only prevention in the moment.
Audit logs record agent activity, and electronic discovery lets authorized teams search and export agent interactions.
Observability is the shared runtime data foundation behind audit, discovery, administration, compliance, and security analytics.
Microsoft-built agents send observability data automatically when licensing and terms are in place; custom and third-party agents require explicit integration.
Agent activity data is not collected before a trial or license begins and the terms of use are accepted.
Data residency must be considered because observability data becomes part of the compliance and evidence record.

Coverage depends on whether an agent was actually wired into the observability stream.

Glossary

Audit log: A record of system activity that shows what happened, when it happened, and which actor or component was involved.
Electronic discovery: The process of searching, preserving, reviewing, and exporting electronic information for legal, regulatory, or investigative purposes.
Observability: Runtime data collection that helps teams understand how a system behaves, diagnose issues, and investigate events.
Agent invocation: An event in which an agent is called to perform work.
Tool execution: An event in which an agent uses a connected tool, service, or function to complete part of a task.
Inference call: A request made to the underlying model so it can generate, classify, reason over, or transform information.
Data residency: The set of requirements or commitments that determine where data is stored and, in some cases, where it is processed.
Microsoft Purview: Microsoft's compliance and data governance family of services used for tasks such as information protection, compliance monitoring, and discovery.
Microsoft Defender: Microsoft's security family of services used for threat detection, investigation, and protection across users, devices, workloads, and cloud services.