Threat Protection with Microsoft Defender for Agents

Every earlier article in this level reduces risk in advance: a proper identity, tight permissions, labelled data. This article is about the moment prevention is not quite enough and something is going wrong right now. Microsoft Defender is the layer that watches for that moment and acts on it, and the shift it represents for agents is stated plainly by Microsoft: moving from reactive to proactive protection.

1 · Runtime protection: blocking, not just logging

Defender provides runtime protection for agents, meaning it actively monitors an agent’s actions as they happen and can block unsafe ones, including attempts to access unauthorised resources or expose sensitive data. This is a meaningfully different posture from a system that only records what happened for someone to review later. A log entry after the fact tells you what already occurred; runtime protection can stop the unsafe action before it completes.

For an actor that moves as fast as an agent can, this distinction is not a nuance, it is the whole point. An agent can act across many systems in seconds; a security team reviewing yesterday’s logs is already too late to prevent yesterday’s damage. Runtime blocking closes that gap by acting in the same moment the risk appears.

2 · Cross-signal analysis: catching patterns early

Defender analyses signals across agents and other enterprise assets together, not one agent in isolation. A single action might look unremarkable on its own, but connected to a handful of other signals — an unusual sign-in elsewhere, a related device behaving oddly — the combined pattern can reveal a threat emerging before it fully escalates.

This is the practical meaning of “identify suspicious behaviour early and surface emerging threats before they escalate.” It is detective work across the whole enterprise picture, not a narrow check on one agent’s single action, which is exactly what lets Defender catch things a purely agent-local view would miss.

3 · Relationship mapping: an agent’s whole neighbourhood

Defender builds relationship mapping for local agents: which devices an agent runs on, which tools and connectors, including Model Context Protocol connections, it talks to. This gives a security team a picture of an agent’s whole neighbourhood, not just the agent as an isolated dot on a list.

Why does the neighbourhood matter? Because a compromise rarely stays contained to a single point. If an agent is connected to five tools and three devices, understanding that web is what lets a team reason about the true blast radius of a problem, and identify misconfigurations or exposure risks that only become visible once you see the connections, not just the agent alone.

4 · Syncing shadow agents from endpoints

Defender syncs in shadow AI endpoint agents — agents discovered running on endpoint devices that were never properly registered. This connects directly back to the registry: an unregistered agent found on a laptop or workstation is exactly the kind of shadow agent a complete catalogue is meant to expose, and Defender is one of the sensors that surfaces it.

The practical effect is that shadow agents are not only caught when someone happens to notice them; endpoint-level detection actively looks for them and feeds discoveries back into the broader governance picture, closing yet another door a shadow agent might otherwise hide behind.

5 · Blocking one tool, not the whole agent

Defender can detect suspicious agent activity, generate alerts, and block specific tool invocations for an agent. This is a more precise response than switching an agent off entirely: if an agent is misusing one particular tool, that single tool call can be blocked while the rest of the agent’s legitimate work continues.

This precision matters for the same reason least privilege matters elsewhere in this series: a narrow, targeted response does less collateral damage than a blunt one. Stopping one misused tool is often exactly the right amount of intervention, no more and no less.

6 · Investigating with the tools you already use

When an incident does occur, security teams investigate agent activity with the same tools and workflows they already use for every other enterprise asset. Microsoft frames this as treating agents as first-class security principals — full participants in existing security operations, not a special, bolted-on category requiring a separate process.

This closes the loop on the whole article. Detection happens across the same signal fabric as everything else; investigation happens in the same portal as everything else; response uses the same containment and remediation playbook as everything else. Agents are not managed alongside the rest of enterprise security — they are simply part of it.

7 · Glossary — every short-form term, spelled out

Runtime protection

Security that actively monitors and can block an action as it happens, rather than only recording it for later review.

Relationship mapping

A map of what an agent connects to, devices, tools, connectors, and other agents, showing its whole security neighbourhood.

Shadow AI endpoint agent

An agent discovered running on an endpoint device that was never properly registered.

Tool invocation

An agent’s act of calling or using a specific tool; can be blocked individually without disabling the whole agent.

First-class security principal

A subject treated as a full participant in existing security operations, investigated with the same tools as any other enterprise asset.

Reactive vs proactive

Reactive security responds after an incident is discovered; proactive security detects and blocks the unsafe action as it happens.

MCP (Model Context Protocol)

A standard way for an agent to connect to tools and data sources, mapped as part of an agent’s relationships.