What happened
Microsoft announced that discovery of local AI agents and their configured MCP servers is generally available in Microsoft Defender. The capability was introduced at Microsoft Build 2026 as coverage for more than 20 types of local AI agents. The generally available release expands discovery coverage to more than 50 supported agents and MCP servers.
The target is the growing population of agents that operate directly on employee endpoints: coding assistants, command-line agents, desktop applications, and agentic development environments. Microsoft frames the issue as a visibility gap. These tools can have access to a user’s data, credentials, tools, and services, while their MCP connections can extend that access to more tools and data. Defender’s discovery feature is intended to answer a practical security question: which local agents are running, where they run, which user and device are associated with them, and which MCP servers they are configured to use.
On eligible devices that have been onboarded to Defender, the service observes activity to discover supported agents. Security teams see the results under Assets in the Defender portal. Each inventory entry associates an agent with its device and user account and can include the agent name, version, vendor, related process, and discovery history. Microsoft’s examples span CLI tools including Claude Code, Codex CLI, Gemini CLI, and GitHub Copilot CLI; desktop applications including ChatGPT Desktop, Claude Desktop, Codex Desktop, Ollama Desktop, and Perplexity Desktop; agentic IDEs including Cursor, Devin Desktop, Kiro IDE, and Antigravity IDE; and VS Code extensions such as Cline, Codex, Gemini Code Assist, GitHub Copilot, and Roo Code.
The inventory also includes supported local and remote MCP server configurations associated with discovered agents. Depending on the setup, Defender can show the server name, type, endpoint, or command used to start a local server. That changes an agent inventory from a list of installed applications into a partial map of the tools and services those applications can reach. Defender’s exposure graph can show an agent’s associated devices, identities, and MCP context; teams can also use the data in advanced hunting alongside endpoint, identity, email, and cloud data. Microsoft says risk indicators and security recommendations help prioritize findings.
Runtime protection is not part of this general-availability announcement. It remains in preview for discovered agents on Windows, with support varying by agent and inspection method. Microsoft describes agent-native event inspection through vendor-supported hooks, covering user prompts, pre-execution tool requests, and post-execution tool responses. It also describes network inspection for supported agents without a native event interface. Administrators can validate detections in audit mode and move selected device groups to block mode. Microsoft says both discovery and runtime protection are available to Microsoft Defender for Endpoint P2 and higher customers; Intune-based runtime deployment is also preview.
What the archive adds
This is a new event rather than a further fact in an earlier Defender story. It sits beside Glean’s general-availability release for agent-specific governed accounts: Glean addresses which identity an agent acts under, while Defender’s new discovery surface identifies which local agents and MCP configurations exist on managed endpoints.
Trend signal
The release supports the pattern that agent security moves to runtime boundaries. Defender is not presenting prompt policy as sufficient control. Its discovery layer links an agent to endpoint, account, process, and MCP configuration; its still-preview enforcement layer inspects parts of the operating loop and can block an action. The announcement does not establish that this approach is comprehensive, but it makes runtime and endpoint context a product surface for agent governance.
Why now
Microsoft says local agents have moved from experimentation into everyday work. Its own timeline also shows a rapid widening of the problem definition: the company introduced discovery for more than 20 local agent types at Build 2026, then made it generally available with more than 50 supported agents and MCP servers. The timing reflects an operational need to inventory deployed tools before organizations can decide where enforcement is appropriate.
Connections to other events
The Glean release above makes delegated, governed agent identities available as a general product capability. Defender addresses a different layer: local execution environments and the MCP servers configured into them. Together, the two releases illustrate that an agent governance program needs both an accountable principal and an observable runtime context; neither an account record nor an application inventory alone describes the whole path to a tool call.
Why it matters
Teams often adopt local coding agents one developer, extension, or desktop application at a time. That makes the technical estate difficult to describe even before a security team assesses permissions. An endpoint inventory that includes configured MCP servers creates a starting point for a more specific conversation: not “do we allow AI agents?” but “which agent is on which managed machine, under which account, and configured to reach what?”
For engineering leaders, the immediate value is discovery and review, not an assumption that Defender has made every agent interaction safe. The inventory can support a rollout baseline, investigations, and prioritization of configurations that connect agents to higher-value systems. It can also expose inconsistency between approved developer tooling and what is actually installed or configured locally.
What happens next
- Microsoft expands the supported-agent and MCP-server matrix beyond the announced 50-plus coverage. (6 months, 75%). Watch for: new entries in its support matrix.
- More Defender customers test prompt-injection controls in audit mode before enabling blocks for selected device groups. (3 months, 65%). Watch for: clearer agent-specific enforcement guidance or coverage updates.
Limits and uncertainty
Microsoft’s announcement is a vendor description of supported coverage, not an independent evaluation of detection quality, performance impact, or false-positive rates. It does not say that every local agent, MCP server, operating system configuration, or network path is discovered. Runtime protection remains preview-only for Windows, and coverage varies by agent and by whether Defender can use hooks or network inspection. The announcement also does not provide pricing beyond eligibility for Defender for Endpoint P2 and higher, nor does it establish how organizations should classify acceptable versus unacceptable MCP configurations.
Skill to build now
Create a small inventory worksheet for the local agents your team already permits. For each one, record the endpoint owner, agent and extension version, account used, and every configured MCP server, including its endpoint or local launch command where applicable. Then label the data or systems each server can reach. This is a useful exercise whether or not the organization uses Defender: the announced product makes those fields operationally visible, but a team still needs to decide which combinations deserve review.
Reader takeaway
Microsoft Defender’s generally available discovery feature turns local AI agents and their MCP connections into endpoint inventory data for eligible P2 customers. Treat it as a way to establish facts about an existing agent footprint: the tooling present, the identities and devices involved, and the configured paths to additional tools. Runtime blocking is a separate, preview-stage decision.
Open question
Will Microsoft’s supported coverage and preview enforcement mature quickly enough to govern the heterogeneous mix of local agents and MCP setups that enterprises already have?