Monitoring AI Agents in Microsoft 365: What You Can and Cannot See

Why this question matters now

An AI agent in Microsoft 365 is not only a chat box. It can read files and email that the signed-in user can read, call connected services, and act on a person's behalf. Copilot Studio lets staff build their own agents with low-code tools. That is useful, and it also means the number of agents in a company can grow without anyone in IT approving each one.

Security teams, insurers and auditors then ask the same questions in different words. Which agents exist? Who owns them? What did they access? Can we reconstruct what happened after an incident? This article answers for the Microsoft 365 platform, using Microsoft's own documentation. We do not describe what other vendors' products show.

Layer one: Purview audit logs

Microsoft Purview Audit records user activity across Microsoft 365. Microsoft's page on audit logs for Copilot and AI applications says the system automatically logs these activities as part of Audit (Standard). If auditing is enabled, no extra steps are needed to turn on support for Copilot and AI applications. The page states that Microsoft applications, including custom applications built using Microsoft Copilot Studio and Microsoft Foundry, are included in Audit Standard.

Audit records contain details about which user interacted with Copilot, when and where. They also include references to the files, sites and other resources that Copilot accessed to generate responses. The documented properties that matter most for security work are these.

• AccessedResources: the resources Copilot accessed, with an ID, site URL, type, name, the action (such as read, create or modify), whether it succeeded, and the sensitivity label ID of the resource. It can also carry policy details when access was blocked or restricted, and a boolean, XPIADetected, that flags a detected cross-prompt injection attack from a resource.
• AgentId, AgentName and AgentVersion: identify the agent involved. For agents created through Copilot Studio, the ID string includes the agent category, for example a declarative or custom-engine agent.
• AISystemPlugin: the plugins or extensions enabled for the interaction, including a value showing that the public web was used through Bing.
• AppHost and AppIdentity: where the interaction took place (Teams, Word, Outlook, the Microsoft 365 Copilot Chat client and many more) and which Copilot or AI application it was.
• Messages: the prompt and response messages in the interaction, identified by message ID, with a flag for whether each is a prompt, and JailbreakDetected for prompts.
• Operation, RecordType and Workload: the type of record. User interactions with Microsoft Copilot use CopilotInteraction. Custom-built or registered third-party AI applications and unregistered ones use other record types.
• DLP evaluation fields: show when data loss prevention evaluation of a prompt, response or grounding content was deferred, and why.

You search these records in the Purview portal under Audit, filtering by operation, record type and workload. If you need to search for a particular AppIdentity value, Microsoft's page says to first export the relevant Copilot audit logs filtered by operation name, then filter by that property offline.

One licensing detail: audit logs for non-Microsoft AI applications use pay-as-you-go billing and are retained for 180 days, according to the same page. Microsoft applications are not billed that way. We do not discuss prices here; ask your Microsoft representative or licensing partner.

What the audit log does not show

Audit records are evidence of access and activity, not a transcript. Three limits matter.

• No prompt or response text in the record. The Messages property in the documentation holds IDs and flags, such as whether a message is a prompt or whether a jailbreak was detected. The text itself is not a listed field. Whether and how prompt content can be retrieved through other Microsoft tools, such as eDiscovery or data security posture management for AI, depends on your configuration and licenses; we did not verify that route, so confirm it before you rely on it.
• No reliable model name or version for Microsoft 365 Copilot. The property ModelTransparencyDetails includes ModelProviderName, which is present in all Microsoft 365 Copilot scenarios, but Microsoft states that ModelName and ModelVersion are not available in Microsoft 365 Copilot scenarios. Elsewhere the same page says records may include the model provider and name when a user selects a specific model, and that when a user selects Auto, provider and model name might not be available for every request, for example when an internal model is used. It also says Cowork currently does not show provider details. Treat model identity as not dependable evidence.
• Access is not intent. A record that Copilot read a file shows that it read it, not why, and not what it did with the contents.

Layer two: Microsoft Entra and agent identities

Microsoft Entra Agent ID is the part of Entra that provides identities for AI agents. Microsoft's documentation describes agent identities as identity accounts in Entra ID that provide unique identification and authentication for AI agents, separate from human user identities and from ordinary application identities (service principals). The reason for the separation, as Microsoft explains, is to tell apart operations done by agents from those done by people or workloads, to give agents right-sized access, and to keep them away from the most critical roles.

For Copilot Studio, the documentation says each time an agent is created, it gets an agent identity in the Entra tenant, and the user who created the agent is recorded as its sponsor. Authentication performed by these agents is logged in Entra ID as AI agents and is viewable in the Microsoft Entra admin center. For a security team, that gives you two useful things: an inventory entry for each agent identity, and a named human attached to it. The sponsor field is a ready-made answer to "who owns this agent?", provided someone keeps it current when people leave.

Microsoft's page says Agent ID is available for all Entra customers, and that extending Microsoft Entra security features to agents requires Microsoft Agent 365. Licensing terms change, so confirm the current terms in Microsoft's product terms.

Layer three: Microsoft Agent 365 and Defender

Microsoft Agent 365 is described on Microsoft Learn as providing the ability to observe, govern and secure agents within an organization. It includes a central registry of agents, lifecycle and access controls through the Microsoft 365 admin center, Entra and Purview, and threat detection and real-time protection through Defender. Microsoft states that Agent 365 has been generally available since May 1, 2026 for the Commercial segment on a per-user basis, that it works best with Microsoft E5 as a prerequisite, and that at least one user must hold a qualifying Agent 365 license to enable it.

The change that affects monitoring plans is dated. Microsoft's Defender documentation states that effective July 1, 2026, AI agent security capabilities for Microsoft Copilot Studio and Microsoft Foundry agents require a Microsoft Agent 365 license and are no longer covered by existing Defender for Cloud Apps or Defender for Cloud licenses. Tenants without an eligible license lose access to these capabilities. The list of what moved:

• Copilot Studio agents: agent discovery and posture; agent threat detection and real-time protection; and investigation of agent activity in Advanced Hunting, now powered by Agent 365 observability logs.
• Foundry agents: discovery and security posture for cloud-hosted agents, and threat protection for agents. Defender for Cloud still discovers Foundry accounts and projects, but agent-level discovery, posture and threat detection need Agent 365.
• Advanced Hunting: the agent inventory moves from the AIAgentsInfo table to a new AgentsInfo table. Saved queries and custom detections that use the old table need updating.
• Blocking: tenants that had Agent 365 real-time protection rules set to Block stopped blocking on July 1, 2026 and must define rules again under the new policy experience. Alerts from the older rules are replaced by behaviors in the BehaviorInfo table.

Microsoft's page also says that admin-led Agent 365 trials are available for 25 seats for 30 days. A trial is a way to see what the tenant would show before deciding. We mention it as a fact from the page, not as advice on licensing.

What cannot be seen

Putting the layers together, there are gaps that no amount of configuration within these logs closes. A monitoring plan should name them.

• Agents outside the Microsoft platform. Microsoft's transition page says third-party cloud agents are no longer discoverable through Defender for Cloud connectors and points to registry sync in the Microsoft 365 agent registry, which it labels preview. Agents running in other vendors' clouds are therefore visible only to the extent registry sync, or other tooling you add, covers them.
• Local tool servers and local agents. The documentation we reviewed describes cloud-side logs. It does not describe visibility into Model Context Protocol (MCP) servers running on a user's own computer. The MCP specification adds a reason that such servers leave little authorization trail: it says implementations using the STDIO transport should not follow its authorization specification and should instead retrieve credentials from the environment. A local tool server started by an agent on a laptop therefore may use credentials sitting in the environment, with no OAuth flow to log. Calls are visible only if they pass through a gateway or logging layer that someone has put in the path.
• Prompt and response text, as described above.
• Model identity for Microsoft 365 Copilot, as described above.
• Unlicensed capabilities. Without Agent 365, the Defender agent inventory, posture, threat detection and real-time protection for Copilot Studio and Foundry agents are not available. Audit and sign-in logs remain.
• Blocking in real time. Treat detection and blocking as separate claims. Blocking rules stopped on July 1 until redefined, and no rule set stops every unsafe action.

A practical monitoring baseline

Given those layers and limits, this is the baseline our team sets up and documents for Microsoft 365 tenants.

• Confirm that auditing is on and that the people who investigate can search it. Practice one search before you need it.
• Export Copilot audit records to a place your security team can query, and set a retention period that matches your policy and your broker's questions.
• Review Copilot Studio settings: who may create agents, who may share them, which connectors and data sources are allowed, and which environments they run in.
• Inventory agent identities in Entra. Check each has a sponsor who still works at the company and a purpose written down. Apply least privilege to the access granted.
• Decide whether Agent 365 is right for the tenant, with your licensing adviser. If it is not licensed, write that down as a known limit.
• Build a few detections on what you do have: an agent accessing resources with sensitive labels, XPIADetected or JailbreakDetected flags, new agent identities, unusual sign-in patterns for agent identities.
• Route any agent that uses MCP tool servers through a gateway where practical, and inventory local servers by endpoint management.
• Write a one-page statement of the visibility ceiling for the tenant: what is logged, for how long, who reviews it, and what is not visible.

That last item is the one most often skipped. A written ceiling stops people assuming the logs show more than they do.

What Clayton Cybernetics does here

Our team reviews Microsoft 365 tenants for agent exposure, sets up the audit, identity and Defender configuration described above, monitors the agent activity that your Microsoft licenses and any gateway we place in the path make visible, and tells you in writing where that visibility ends. We also test agents for over-permissioning and prompt injection. A free security assessment is the place to start.

Sources

• Microsoft Learn: Audit logs for Copilot and AI applications (Microsoft Purview)
• Microsoft Learn: Transition Microsoft Copilot Studio and Microsoft Foundry agent security capabilities to Microsoft Agent 365 (Microsoft Defender XDR)
• Microsoft Learn: Microsoft Agent 365 overview
• Microsoft Learn: What are agent identities? (Microsoft Entra Agent ID)
• Model Context Protocol: Authorization, specification revision 2026-07-28

This article is general information, not legal advice. It describes Microsoft documentation as read on November 8, 2026. Product names, features and licensing change often; confirm current terms with Microsoft and your licensing adviser. Nothing here states that any configuration provides complete visibility. Last reviewed November 8, 2026.

Keep reading

Next · InfrastructureServer Burn-In and Acceptance Testing Before ProductionA new server that boots is not a server that is ready. Parts fail early more often than they fail in the middle of their life, and a fault found in the rack costs far less than one found during a customer outage. Burn-in is the planned stress of every subsystem before the machine takes real work, and acceptance testing is the written decision that it passed. This article walks through memory testing with MemTest86, CPU and system stress with stress-ng, storage tests with fio, GPU diagnostics with NVIDIA DCGM, firmware baselines and inventory through the DMTF Redfish standard, and the acceptance criteria and records worth keeping. It is based on tool documentation we read on November 8, 2026.9 min read

• Penetration Testing Explained for Executives: Scope, Reports and How Often to Test8 min
• Ransomware Readiness and Incident Response: A Checklist Based on the CISA #StopRansomware Guide9 min