Prompt injection on the endpoint: how Microsoft Defender discovers and protects local AI agents

The rise of coding agents has fundamentally changed how software is written. Tools like Claude Code, GitHub Copilot CLI, Cursor, and Windsurf are no longer passive suggestion engines; they read code and files, call external tools and APIs, write and execute scripts, and orchestrate tasks across multiple steps. That makes them productive. It also makes them a new attack surface on the endpoint.

At Microsoft Build on 2 June 2026, Microsoft unveiled a range of new security capabilities specifically for local AI agents. Defender for Endpoint can now automatically discover more than twenty types of local agents and provides runtime protection that actively monitors the agentic loop and blocks malicious instructions before the agent can act on them. For IT administrators, this introduces a new domain within endpoint security: no longer just protecting the user, but also the agent acting on behalf of the user.

Why AI agents have a different security profile than ordinary software

Traditional endpoint security is designed for a relatively clear-cut attack model: an attacker tries to execute code via a vulnerability, an attachment, or a malicious file. Attack indicators are reasonably well defined: suspicious processes, known malware signatures, anomalous network traffic.

An AI agent works differently. The agent reads content from the environment — files, repositories, API responses, web pages — and acts based on that content. Prompt injection is the attack type where malicious instructions are hidden inside that content. A developer asks a coding agent to analyse a repository; inside that repository is a file containing a hidden instruction telling the agent to download an external script or forward credentials. The agent executes this because the instruction looks to it like an ordinary task.

This attack type is not theoretical. Coordinated audits of popular coding agents in 2026 showed that agents from multiple vendors were susceptible to prompt injection via repository files and MCP server responses. Defender's runtime protection is a direct response to that finding.

Which local AI agents does Microsoft Defender discover automatically?

Defender for Endpoint automatically discovers more than twenty agent types on Windows and macOS endpoints, grouped into four categories.

Coding CLIs and agentic tools: Claude Code CLI, GitHub Copilot CLI, OpenAI Codex CLI, and OpenClaw. These are command-line agents that work autonomously through a codebase, run tests, and create pull requests.

Agentic IDE extensions: Cursor, Windsurf, and Claude Code as an IDE integration. These tools work within the context of a code editor and can read, modify, and execute files with a high degree of autonomy.

Desktop AI assistants: ChatGPT Desktop and Claude Desktop. Although less code-focused, these agents have access to the file system and system functions via tool integrations.

Local AI runtimes: Ollama Desktop and related platforms that run local language models. These are increasingly deployed as backends for internally built agent solutions.

Beyond the agents themselves, Defender also discovers configured Model Context Protocol servers, both local and remote. MCP is the protocol that connects agents to external tools and data sources. An MCP server with access to an internal database or a cloud API is a potential pivot point for an attacker seeking to enter via the agent.

How runtime protection works: three checkpoints in the agentic loop

The core of Defender's protection for AI agents is runtime inspection of the agentic loop — the cycle of processing input, deciding on an action, calling a tool, and interpreting the result. Defender monitors three specific points in that cycle.

The first checkpoint is the user prompt: the input that the user or an automated system provides to the agent. Defender inspects the prompt for signs of abuse or malicious instructions before the agent begins processing.

The second checkpoint is the pre-tool call: the moment at which the agent has decided to invoke a tool — reading a file, executing a script, querying an API — but has not yet done so. This is the critical point for blocking, because here Defender can intervene before the harmful action has taken place.

The third checkpoint is the post-tool response: the data that a tool returns to the agent as input for the next step. This is the most common injection route: a malicious server or a manipulated file returns a response that instructs the agent to do something the user never intended.

When Defender detects a prompt injection, three actions are taken simultaneously. First: in Block mode, Defender halts execution before the agent can act on the instruction. Second: the user receives a Windows notification that the action has been blocked, so there is no silent suppression. Third: an alert is created in the Defender portal with the classification 'Suspicious AI prompt injection', which is automatically correlated with related activities into an incident for the security team.

What IT administrators see in the portals

The findings from agent discovery and runtime protection are centrally available in the Defender XDR portal. The AI agent inventory provides an overview of all discovered local agents per device, including agent version, configured MCP servers, associated Entra identity, and the cloud resources reachable via that identity. This gives security teams a complete picture of the agent footprint within the organisation for the first time.

The exposure map has been extended with agent entities. An IT administrator can see how a specific coding agent on a specific device is connected to an MCP server, which cloud services that server reaches, and which user identity is linked to it. This makes attack path inspection possible on a dimension that until recently was invisible.

Advanced hunting in Defender XDR now supports queries specifically on agent activity. Security teams can search for which tools an agent has called, which files have been read, which external connections have been established, and whether any blocking events have occurred. This data is available as part of the existing telemetry in Defender for Endpoint, without additional installation.

Purview integration adds an extra layer: runtime DLP for agent prompts inspects whether sensitive data — such as passwords, social security numbers, or confidential business information — appears in prompts or tool responses. This data can be audited, blocked, or flagged based on the DLP policies already configured for human users.

Licensing requirements and timeline

The capabilities for local agent discovery and runtime protection are currently available as a preview in Defender for Endpoint. Activation requires that preview features are enabled in the Defender portal under Settings.

From 1 July 2026, using agent protection and visibility capabilities requires an active Agent 365 subscription. Organisations with Microsoft 365 E5 or GitHub Enterprise licences will have all new agent capabilities included at no additional cost through June 2027. For organisations not yet on E5, this is a concrete argument to consider the upgrade, given the breadth of security functions included.

Discovery coverage is being actively expanded. Microsoft has indicated that the list of supported agents grows as new platforms gain market share. Organisations that join the preview now are building experience with the tooling before general availability rolls out.

What IT teams can do now

Four concrete steps to activate and evaluate the agent security layer today.

First: enable preview features in Defender for Endpoint via Settings > Endpoints > Advanced features. Specifically enable 'Local AI agent discovery'. Defender will then automatically begin inventorying agents on onboarded endpoints.

Second: open the AI agent inventory in the Defender portal and assess which agents and MCP servers are present in your environment. Focus on agents with broad file access or configured external MCP connections: these have the largest attack surface.

Third: enable runtime protection for the agents where this is available (Claude Code and GitHub Copilot CLI are the first). Set the mode to Audit for an initial observation period of two weeks so you can see what activity is detected without disrupting existing workflows. Then evaluate whether Block mode is appropriate.

Fourth: verify that your Purview DLP policies are aligned with agent activity. Policies written for email and SharePoint do not automatically cover agent prompts. A brief review of which sensitive information types are relevant for your organisation helps complete the DLP coverage.

AI agents on the endpoint are not a future vision; they run today on the workstations of your developers and knowledge workers. The question is not whether you want to secure them, but whether you start in time with the tools that already exist. Want help activating Defender AI agent discovery, auditing your agent footprint, or setting up runtime protection? Contact Zarioh.