With AI agents now running in many Microsoft 365 tenants, monitoring their activity has become part of the security team’s job. Microsoft Defender XDR monitors AI agents through its integration with Microsoft Agent 365, the control plane for agents in your tenant. This post covers what to enable, where the data lands, and how to respond when an agent goes wrong. We will also show you some interesting log sources, where useful information about the behavior of agents can be found..
The features listed in this article may not be visible or available without the proper license. You may need the “Agent 365” add-on for you actual license, or the new E7 license plan which includes everything (Agent 365, Microsoft 365 Copilot).
Which agents Defender XDR can see
Defender’s threat detection uses observability data from different cloud agent sources, plus agents running locally on endpoints.
| Agent type | Examples |
| Copilot Studio agents | Low-code custom agents built by users |
| Microsoft Foundry agents | Pro-code agents in Azure |
| Copilot Agent Builder agents | Declarative agents built in Microsoft 365 Copilot |
| Non-Microsoft agents | Agents built with the Agent 365 SDK |
| Local agents | Coding and desktop agents on devices |
Each managed agent also gets a Microsoft Entra Agent ID: a directory identity with owners, sign-in logs and risk scoring. That identity is what ties Defender, Entra and the Microsoft 365 admin center together.
Check our great blog bost here for more info about agent identities:
Entra Agent ID from a Security Perspective – Compass Security Blog
Not in this list: Microsoft 365 Copilot and Security Copilot themselves. They’re Microsoft-operated assistants, not tenant-built agents.. Their activity is audited in Purview and can be brought into Sentinel through the Microsoft Copilot connector (CopilotActivity table). Agents build on top of Copilot are covered under Copilot Agent Builder agents.
What do I have to configure?
To efficiently monitor AI activity in the Defender XDR platform, there are some key settings that must be enabled and configured to have the visibility needed:
- Security for AI: settings for the built-in detection capabilities of Microsoft Agent 365 in Defender XDR
- Local Runtime Agent Protection: Defender for Endpoint / Defender AV settings to monitor local agents
- Sentinel logs: ingest new log categories that you may be interested into
Security for AI
“Security for AI” are settings configured in the XDR portal that affects detection of built-in behaviors for Microsoft Agent 365.
First go to the security portal, go to settings and select “Security for AI“:
In the “Get started” page you want something like this:
Click “Enabled” and then we suggest “Agent 365” and “Microsoft 365 connector” to always be enabled and connected. For the “Microsoft 365 connector” you may want to click on it and in the panel that will show up, select all checkboxes relative to the M365 components to connect. This will ingest in you Defender XDR information and logs relative to important parts of the M365 environment, needed for later investigations or also for other purposes than AI.
Enable the third setting, Copilot Studio, if anyone in your organization builds or uses agents in Microsoft Copilot Studio. When enabled, Defender inspects each tool invocation before the agent runs it, blocks suspicious actions (such as cross-prompt injection attempts), and raises an alert in the Defender XDR alerts and incidents queues. Click the setting to see the configuration steps.
On the left hand-side, select now “Real-time protection“, you should see a default rule set in audit mode. We suggest to create a new rule in “Block” mode, scoped for all agents with all protections active:
And finally, always on the left hand side menu, enable the “Prompt evidence collection”, to let the platform have access to code snippet of the prompt the user exchanged with the agent (Microsoft says sensitive information are redacted…):
Local agent runtime protection
These Defender AV settings allows the Microsoft Defender for Endpoint sensor to monitor the behavior of local agents running for example on your host or VM, in particular:
- “AiAgentProtection“: the sensor will use the interfaces exposed by the agent vendor to gather data and perform analysis
- “AiAgentNetworkInspection“: in case an agent has no exposed interfaces where the sensor can pull its data from, the network request made by that agents will be inspected
You can set them in “Audit” or “Block” mode via Set-MpPreference:
Set-MpPreference -AiAgentProtection Block
Set-MpPreference -AiAgentNetworkInspection Block
Following agents are supported (AI agent runtime protection with Microsoft Defender for Endpoint (Preview) – Microsoft Defender for Endpoint | Microsoft Learn):
- Claude Code
- Codex CLI
- GitHub Copilot CLI
- Github Copilot app
Every agent listed above exposes hooks that the EDR can use to access content and other info.
Use for example Intune to deploy a policy on your devices (Endpoint Security => Antivirus => Create Policy => Windows, “Microsoft Defender AI agent runtime protection”):
Note that this only sets “AiAgentProtection“, to also set “AiAgentNetworkInspection” you should deploy a PowerShell script via Intune as explained here:
WARNING: test these settings on a restricted number of devices before deploying them across your fleet. This feature is for the moment only available in the Beta channel of Defender, if you want to test it out you have to switch the channel via powershell:
Set-MpPreference -PlatformUpdatesChannel Beta -EngineUpdatesChannel Beta
Sentinel Logs
There is vast choice of logs you can access in Sentinel regarding the behavior of agents. Some of these logs are already available as standard table inside your environment and other must be configured and enabled separately. Some of these are particularly useful if you want you create your own detections.
| Table | Connector | Purpose |
|---|---|---|
| AgentsInfo | Activated by default if you use Microsoft Agent 365 | Inventory of AI agents and their properties across platforms, saved as snapshots over time. |
| CloudAppEvents | Enable the “Microsoft 365 Connector” as explained in the “Security for AI” chapter | Agent activity logs: what agents (and users) actually did in Microsoft 365 apps, like who started an agent and who updated it. |
| BehaviorInfo | Enable UEBA in sentinel | Behaviors and anomalies, built by correlating raw events. Use it to spot unusual agent or user activity. |
| UnifiedAgentObservability | Install the “Agent 365” connector from Sentinel Content Hub. It streams Agent 365 telemetry into the Sentinel data lake. | Runtime behavior of agents: user prompts, session and conversation IDs, agent identities, MCP and connector tool calls with their arguments and responses, payloads, and errors. Useful for forensics. |
| EntraAgentIdentities EntraAgentIdentityBlueprintPrincipals EntraAgentIdentityBlueprints EntraAgentUsers | Install the “Agent 365” connector from Sentinel Content Hub, and enable “Microsoft Agent Identities” | Agent and blueprint inventory, ownership, relationships, governance metadata, and risk context. Answers questions like “who owns this agent?” |
| CopilotActivity | Microsoft Copilot | Copilot usage auditing, operational visibility, and tracking of user interactions. Useful for governance, compliance, and adoption reporting. |
| AppEvents | Copilot Studio agent connected to application insight | Detailed custom telemetry for “Standard” agents built in Copilot Studio. App Insights also fills AppDependencies (connector and tool calls), which is handy for baselining. |
| RiskyAgent | Entra ID => Diagnostic settings => Send the RiskyAgents logs to the Sentinel workspace. | Agents flagged as risky by Entra ID Protection, including type (AgentIdentity, AgentUser, BlueprintPrincipal) and enabled/deleted state. |
| AgentRiskEvents | Entra ID => Diagnostic settings => Send the AgentRiskEvents logs to the Sentinel workspace. category | The individual agent risk detections, with when each happened, when it was detected, and the detection timing type |
For the log in the “AppEvents” table, you need extra configuration. First, only “Standard” Copilot agent can be configured to log in the AppEvents table, “GitHub Copilot” agents do not have this capabilitiy:
Then, you must create in Azure an “Application Insight” workspace, and from the overview page you can copy the “Connection string”:
In the settings of your agent (https://copilotstudio.microsoft.com), under “Advanced => Application Insights”, copy the connection string and enable “Enable logging”, “Log conversation details”, and if you want also “Log sensitive properties”:
Once this is done, you will see the “AppEvents” table with the relative logs. See the paragraph below for examples of logs.
Incident Handling
Once your environment is configured and ready, Defender XDR will start generating alerts in case your agents misbehave or in case you setup custom detection rules. More in particular, out-of-the-box alert may come from these sources:
| Source | Examples | Where it shows up |
| Near-real-time agent detections (Agent 365 observability) | Jailbreak attempts, indirect prompt injection (XPIA), malicious content propagation, secret and credential leakage, evasion techniques, LLM reconnaissance, suspicious user or IP access | As alerts and incidents, in the Defender XDR portal |
| Real-time protection (cloud agents) | Blocked or audited tool invocations | As behavior, in the BehaviorInfo table |
| Endpoint runtime protection (local agents) | Suspicious AI prompt injection on a local claude agent | For the moment this signal is not visible in Defender XDR as alert/incident. |
| Entra ID Protection | Risky agent: sign-in spike, unfamiliar resource access, failed access attempts, suspicious credential usage | Entra Risky agents report, as alerts and incidents, in the Defender XDR portal |
Not that this list is not exhaustive. In the different Sentinel tables you may find lots of information and behaviors you may want to monitor using custom detection rules.
Example of out-of-the-box alert for indirect prompt injection
This alert was generated after sending an email with an hidden prompt, and having the agent with the outlook tool/connector, reading it
In red the “<span>” element with the indirect prompt
Example of out-of-the-box alert for tool invocation
Here we tried to access sensitive information in SharePoint, using an agent configured with the SharePoint tool, so we were able to browse all files and folders:
Unfortunately this out-of-the-box alert does not give much details about which prompt was exactly used.
Example of behavior
In some cases, Defender XDR will just log blocking events and categorize them as “behavior” in the “BehaviorInfo” table:
You can then write your own KQL query to identify when such behaviors occur. For the moment we only identified “BehaviorPromptShieldJailbreakBlock” and “BehaviorAIAgentsRealTimeBlock” (ActionType field).
Example of detailed log entry in AppEvents
The AppEvents table, holds detailed conversation logs between your user and “Standard” Copilot agents. If you configured the log ingestion correctly you will see such entries, in this case a “BotMessageRecevied”:
Example of local runtime prompt injection
Here we are on a local Windows machine, using Claude Code. We started a new sessions and passed an “Hello World” test prompt you see in the red box, this generated an Antivirus alert on the machine:
We did not find any relevant telemetry or incident related to the Defender AV alert above. This could be due to the “preview” status of this feature.
Basic Investigation Steps
In the XDR portal, when an AI agent is involved in an alert, you can usually click on the entity and open its dedicated page:
Among all the generic information you can find, the “Capabilities” panel gives insights about which tools does the agent use so you can have an idea of what to eventually check or investigate, or where the payloads could be (files, email, …):
You can even get some recommendations in case of misconfigurations or others:
Also do not forget that other information are available in the admin.microsoft.com portal, under the “Agents” => “All agents” section.
In “AgentsInfo” table you can find the same information of the “Agent page” plus more details (AgentsInfo | where Name == 'defender-test-agent'):
As next query, we could check in “CloudAppEvents” if there is anything that could interest us, for example who and when the agent was started, and metadata about conversations (but unfortunately not the conversation itself).
Who invoked the agent:
CloudAppEvents | where ActionType contains "InvokeAgent" | extend RD = parse_json(RawEventData) | extend TargetAgentName = tostring(RD.TargetAgentName), ExecutionType=tostring(RD.ExecutionType), PlatformTargetAgentType= tostring(RD.PlatformTargetAgentType), ConversationId = tostring(RD.ConversationId) | project Timestamp, ActionType, AccountDisplayName, TargetAgentName, ExecutionType,PlatformTargetAgentType, ConversationId,ChannelName=tostring(RD.ChannelName), IPAddress | order by Timestamp desc
Still in “CloudAppEvents”, we can check if someone added a tool to an agent or if someone updated the agent properties, like adding a tool (you find this information in the field called “Raw” => “PropertyCollection”):
From the above log we can say that at 16:25:04 the user added the tool “Send an email (V2)” to the agent, because it the very first event we see. Unfortunately, these logs do not exactly say what has been updated.
Detailed conversation logs
In case you have agents built using the “Standard” Copilot platform you can have access to more detailed logs via Application Insights. In the “AppEvents” more detailed telemetry is stored and we can for example reconstruct a conversation. Here a few examples
Disclose the agent system prompt:
List files in a SharePoint and try to export the content:
Here the query:
AppEvents
| where TimeGenerated > ago(30d)
| where Name in ("BotMessageReceived", "BotMessageSend")
| extend ConversationId = tostring(Properties.conversationId),
MessageId = tostring(Properties.activityId),
ReplyTo = tostring(Properties.replyActivityId),
From = iff(Name == "BotMessageReceived", "User", "Agent"),
Agent = tostring(Properties.recipientName),
UserId = iff(Name == "BotMessageReceived", tostring(Properties.fromId), tostring(Properties.recipientId)),
Text = tostring(Properties.text)
| project TimeGenerated, ConversationId, Text, UserId, MessageId, ReplyTo
| order by TimeGenerated asc
How to Respond
As for other entities in the XDR platform, you can also react on agents to contain them in case of a security incident.
Block the agent itself
You can for example block the agent, so that your users will not be able to use it anymore (will also be removed from the store where your users can install new agents).
This is available in admin.microsoft.com, “Agents” => “All agents”, then you have to select the affected agent from the list
Block the agent identity
Also an important step to perform when dealing with rogue agents, is to block its identity to prevent it from logging in in Entra and therefore accessing resources:
Other containment/mitigation actions
There are other containment actions that could be applied across your environment like:
- Isolate the device via Defender XDR, in case of rogue local agents
- React on risky agent, via Entra ID Protection (confirm as compromised, confirm safe, revoke sessions, diable account): https://learn.microsoft.com/en-us/entra/id-protection/concept-risky-agents
- Create conditional access policies for agents: Conditional Access for Agents in Microsoft Entra – Microsoft Entra ID | Microsoft Learn
Conclusion
AI agents are quickly becoming a normal part of Microsoft 365 tenants, and they need the same security oversight as users and apps. With the integration between Microsoft Defender XDR and Microsoft Agent 365, security teams can see which agents exist, monitor what they do, and respond when something goes wrong. Enabling the right settings and knowing where the agent data lands are the first steps. Start with the setup described in this post, explore the log sources we covered, and build detections that fit your environment.
Leave a Reply