Posted in

MDE AI agent runtime protection : Audit before Block

Your developers installed a coding agent. Who checks the instructions it picks up from a repository, web page, or tool response? MDE AI agent runtime protection gives endpoint admins a control to pilot, and Intune 2609 adds the Windows policy template to manage it. The protection is still in preview. Start with Audit on a small developer group before assigning Block.

Start where the agents are already running

Defender’s agent-native inspection supports Claude Code, Codex CLI, GitHub Copilot CLI, and the GitHub Copilot app. It checks user prompts, tool requests before execution, and tool responses after execution at supported checkpoints. This is not continuous inspection of everything a process does.

A malicious instruction in project documentation can tell an agent to read secrets or send data elsewhere. Defender can detect prompt injection in the content and block at supported checkpoints. That is a useful safeguard, but not a guarantee that every unsafe command or data leak will be stopped.

Create the Audit policy

In the Intune admin center, go to Endpoint security > Antivirus > Create policy. Select Windows, then Microsoft Defender AI agent runtime protection. Set AI Agent Protection to Audit and assign it to a limited device group where developers actively use supported agents.

  • Default: agent-native runtime protection is off.
  • Audit: Defender detects and reports prompt injection, but allows the action to continue.
  • Block: Defender detects prompt injection and blocks supported agent activity at the available checkpoints.

Microsoft recommends testing on a small group, reviewing alerts for one to two weeks, expanding Audit, and then enabling Block where detections are accurate and actionable. Audit leaves the risky action running. It is an evaluation phase, not protection equivalent to Block.

Check the pilot before trusting the results

  • Confirm qualifying licensing. The setup guide lists MDE Plan 2, Microsoft 365 E5, Microsoft Agent 365, or Microsoft 365 E7.
  • Confirm MDE onboarding, supported Windows, Defender Antivirus in active mode, real-time protection enabled, and current platform, engine, and security intelligence updates.
  • After assignment, open the device in Defender: Configuration management > Effective settings. Check AI Agent Protection and its configuration source.
  • Close existing agent terminals, reopen them, and run Microsoft’s benign runtime-protection demonstration. Confirm evidence in Defender; an agent refusing the prompt by itself does not prove Defender detected it.

One prerequisite needs care: Microsoft’s setup and demonstration pages still instruct preview testers to use Beta platform and engine channels. Its Defender release notes say agent-native inspection works with standard channels and no Beta configuration is required. Those pages disagree. Check the current guidance and validate detection on the pilot device rather than changing update channels across the fleet to satisfy a conflicting note.

Know what Block does not cover

Block can stop a prompt from being processed, prevent a tool request from running, or stop a tool response from continuing in the agent loop, depending on the supported event. A post-tool check cannot undo a tool execution that already completed. This policy is not an application ban or a replacement for permissions and code review.

The Intune template configures agent-native inspection only. Network inspection is a separate setting, deployed through a PowerShell platform script in Microsoft’s guide. The overview lists OpenClaw for that path and excludes agents using certificate pinning or HTTP/3. Installing the template does not automatically cover every local agent.

Prohibited-agent compliance is a separate roadmap item

Intune’s in-development page describes a Windows compliance policy with a list of prohibited local agents. Discovery would mark a device noncompliant; removing the agent would restore compliance. Separately configured Conditional Access policies could restrict access based on that state. This control is not yet released, and the runtime-protection template does not enable it.

For now, assign Audit to the pilot, verify detection, and review alerts with the developers before deciding where Block belongs.

Poll: where would you start?

  • Audit only
  • Block on dev machines
  • Not in scope yet

Sources


As an Amazon Associate I earn from qualifying purchases. Links on this site may be affiliate links.