Microsoft updated its documentation in September on how Microsoft Defender can monitor AI agents during runtime and block risky actions before they execute. For organizations testing agents in Copilot Studio, Agent 365, or on Windows endpoints, this is more than another portal setting. Agents can access data, call tools, and run commands. Teams should decide early which agents are visible, which actions are only audited, and where blocking is safe enough for daily operations.
What Microsoft now documents
The Microsoft Learn article “Protect AI agents in real time using Microsoft Defender” explains that Defender inspects agent activity throughout the agentic loop and can block risky actions before execution. A built-in default rule audits all agents as behaviors without stopping the action. Custom rules can block selected detection types and can be scoped to all agents or only to specific agents.
For smaller IT teams, that separation matters. Audit data shows which agents actually invoke tools and which users are involved. Only after that visibility exists should block mode be enabled, so that productive workflows are not interrupted by rules that are too broad.
The capability also complements Microsoft Security Copilot and Defender investigations: the team is not limited to analyzing a finished incident after the fact. A risky agent step can be stopped before execution or at least recorded with enough context for later review.
Which agents are covered
Microsoft distinguishes several integrations. Coverage depends not only on Defender, but also on how the individual agent is connected.
- Agent 365 tool invocations are evaluated through Work IQ MCP when the tools are integrated accordingly.
- Copilot Studio agents are listed as part of the described preview capability and require the Copilot Studio connection.
- Foundry agents are also listed as preview; Microsoft says user requests, agent responses, tool invocations, and tool responses are evaluated there.
- Local AI agents are covered through AI agent runtime protection in Microsoft Defender for Endpoint and must be configured separately on endpoints.
Why audit should come before blocking
Defender records audit and block events in the BehaviorInfo table. According to Microsoft, these records include the affected agent, user, tool invocation, and the reason the action was considered risky. Security teams can use the events for hunting queries, detections, and downstream automation. In audit mode, near-real-time alerts continue to surface; when a blocking rule covers an agent, those alerts are not generated for that agent.
That supports a phased approach: establish visibility, then block a small number of high-confidence risks. Examples include actions where an agent would exfiltrate secrets, propagate suspicious content, or use an unsafe email domain. Microsoft lists these detection types in the rule configuration.
That caution is practical in organizations with only a small admin team. A blocking rule needs an owner, an exception process, and a fast path for deciding what happens when an agent can no longer complete legitimate work.
What local agents on Windows need
For local agents, Microsoft points to Defender for Endpoint. The separate Learn article is marked as preview and describes prompt-injection protection at device level. Requirements include Defender for Endpoint Plan 2, Microsoft 365 E5, Microsoft Agent 365, or Microsoft 365 E7; onboarded devices; Defender Antivirus in active mode; current platform, engine, and security intelligence updates; and supported local agents. Microsoft recommends a rollout that starts with audit mode on a small device group, then review, broader deployment, and finally block mode. For small and midsize businesses, the practical evidence matters: which devices have the setting enabled, and whether supported local agents actually run there.
Next steps for small and midsize businesses
- Inventory which production or pilot AI agents exist in Agent 365, Copilot Studio, Foundry, and on Windows endpoints.
- Enable the Microsoft 365 connector in Defender Security for AI so Entra ID management events and Microsoft 365 activities are included.
- Start with audit rules and review
BehaviorInfo, alerts, and incidents for the most important agents. - Use blocking rules only for well-scoped, high-confidence scenarios, and deliberately include or exclude critical agents.
- For local agents, document which Windows devices run audit or block mode and when enforcement should be enabled.
Official Microsoft sources
- Microsoft Learn: Protect AI agents in real time using Microsoft Defender
- Microsoft Learn: Enable security for AI agents using Microsoft Defender
- Microsoft Learn: Set up AI agent runtime protection with Defender for Endpoint
If you already use agents in production or are preparing the first rollout, we can review the Defender rules, roles, and operating processes for your environment as part of a Microsoft Security Assessment.
What does this mean for your environment?
Assess the topic in the context of your Microsoft 365 environment and define a practical next step.
You speak directly with Sebastian Kerssen – working in the Microsoft ecosystem since 2014, with personal consulting and a dedicated point of contact.
