Microsoft is moving AI agent security onto the endpoint. In its June security update, the company said Microsoft Defender can now discover more than 25 types of local AI agents and Model Context Protocol servers across managed Windows and macOS devices, giving security teams a way to see coding agents, desktop assistants, IDE extensions, and MCP connections that may already be running on employee machines.
The more important change is runtime protection. In preview, Defender can inspect supported coding agents as they work and block prompt-injection attempts before the agent carries out a risky action. Microsoft names GitHub Copilot CLI and Anthropic’s Claude Code as the first supported agents for this hook-based protection.
The update matters because local AI agents are no longer passive chat windows. They read repositories, summarize files, call command-line tools, interact with MCP servers, edit code, and often run with the same permissions as the developer using them. That makes the workstation, not just the cloud model or the CI pipeline, part of the agent security boundary.
What Defender can now see
Microsoft’s local agent discovery documentation describes the agent inventory as a combination of user, device, and agent type. If Claude Code is used in several project folders by the same user on the same device, Defender treats that as one agent entry rather than a separate asset for every folder.
The supported discovery list is broad. It includes command-line tools such as Claude Code, Codex CLI, Gemini CLI, GitHub Copilot CLI, OpenCode, Warp, Kiro CLI, Junie CLI, and Antigravity CLI; desktop apps such as ChatGPT Desktop, Claude Desktop, Codex Desktop, Goose Desktop, Ollama Desktop, Perplexity Desktop, Poe Desktop, and Hermes Agent; agentic IDEs including Cursor, Devin Desktop, Kiro IDE, and Antigravity IDE; and VS Code extensions such as Claude Code, Cline, Codex, Gemini Code Assist, GitHub Copilot, and Roo Code.
Defender also discovers MCP server configurations when they are associated with supported agents, including local and remote server configurations. That is a useful shift for security teams because MCP servers often define what an agent can reach: source repositories, cloud services, databases, ticketing tools, file systems, internal APIs, or development environments.
Once discovered, agents appear in the Microsoft Defender portal with device and user associations, exposure mapping, and Advanced Hunting support. The point is not only to count agents. It is to understand which identities are running them, which machines host them, and what those identities can access if an agent is hijacked.
How the blocking works
Microsoft’s runtime protection focuses on prompt injection, especially instructions hidden inside files, web pages, repository content, or tool output that the agent reads and may treat as commands. Defender inspects three stages of the agent loop: the user’s prompt, the tool call before it executes, and the tool response after it returns.
That design is important. A malicious instruction does not have to be typed by the user to be dangerous. A coding agent might fetch documentation, read a README, inspect an issue comment, or process output from a tool. If that content contains hidden instructions telling the agent to read a local .env file and send secrets to an external endpoint, the attack is happening through the agent’s context rather than through a traditional executable payload.
Defender uses application-level hooks exposed by supported agents. For now, Microsoft lists Claude Code and GitHub Copilot CLI as the supported runtime-protection targets. The hook approach means Defender is not merely watching process names or network connections after the fact; it is receiving structured payloads at key points in the agent workflow and can audit or block before a tool action continues.
There are three modes. Disabled turns the feature off. Audit allows the action but records the detection and raises an alert. Block stops the action, notifies the user in the agent interface and through Windows notification, records the event in protection history, and sends an alert into Defender for security operations review.
Why developers are the early test case
Developer machines are a natural first target because coding agents sit close to source code, credentials, build systems, package managers, cloud CLIs, and repository automation. They also routinely ingest untrusted text: issue bodies, pull request titles, commit messages, generated logs, package scripts, and documentation from unfamiliar projects.
Recent AI-agent security research has shown why that matters. The Cloud Security Alliance’s June research note on AI agent prompt injection in CI/CD described how agent workflows can treat GitHub metadata as trusted prompt content. In the cases it summarized, untrusted issue or pull request text could steer tools such as Claude Code, Gemini CLI Action, and GitHub Copilot Agent toward exposing credentials or manipulating repository workflows when permissions were too broad.
That research focused heavily on CI/CD, but the endpoint problem is closely related. A local coding agent can be asked to set up a project, run a test, inspect a failing script, connect to an MCP server, or debug a deployment. If the agent has access to local files and developer credentials, prompt injection becomes an endpoint risk as much as an AI-model risk.
Traditional endpoint detection still matters, but it sees many agent failures late. By the time a shell command runs, a file is changed, or traffic leaves the device, the agent has already crossed a decision point. Hook-based inspection gives defenders a chance to evaluate the instruction before the risky tool action happens.
What teams should do now
The feature is still a preview, so broad enforcement should be deliberate. Microsoft’s setup guidance says runtime protection currently requires Microsoft Defender for Endpoint Plan 2, Microsoft 365 E5, Microsoft Agent 365, or Microsoft 365 E7; onboarded devices; supported Windows versions; Defender Antivirus in active mode; current monthly platform and engine updates; and devices configured for the beta platform and engine update channel. Runtime protection also depends on the agent supporting hooks.
A sensible rollout starts with inventory rather than blocking. Security teams should first use Defender’s AI agent inventory and Advanced Hunting to identify where local agents and MCP servers are actually present. That list should be compared against developer groups, privileged users, production-support roles, and machines with access to cloud credentials or sensitive repositories.
From there, Microsoft recommends testing runtime protection in audit mode on a small set of active agent users, monitoring alerts for one to two weeks, then moving to block mode only after validating that detections are accurate and actionable. That is especially important on developer machines, where a poorly tuned control can interrupt legitimate work or push teams toward unmanaged tools.
Teams should also review MCP server configurations directly. Discovery can show that a server exists, but it does not replace a governance decision about whether that server should be allowed, which tools it exposes, whether it can reach production systems, and whether the agent using it has more permission than the workflow requires.
The larger lesson is that local AI agents are becoming normal endpoint software with unusual authority. They need inventory, least-privilege design, prompt-injection testing, human approval for high-risk actions, credential hygiene, and incident-response paths that security teams understand. Defender’s preview does not solve all of that, but it gives Microsoft-heavy organizations a concrete place to start.
For readers tracking the details, Microsoft outlined the June Defender update in its Microsoft Security Blog, with separate Learn documentation for local AI agent discovery, AI agent runtime protection, and runtime-protection setup.
