Defender for Endpoint: detecting and blocking prompt injection in local AI agents
Key takeaways
- Prompt injection means an instruction is hidden in a file, web page or email, and an AI agent carries it out as if it came from the user. On company devices, that happens with real permissions.
- Microsoft Defender for Endpoint offers runtime protection for local AI agents (AI agent runtime protection). The feature is in preview (as of October 2026) and currently limited to Windows.
- Prerequisites include Defender for Endpoint Plan 2 or Microsoft 365 E5 and Microsoft Defender Antivirus in active mode.
- Roll out in audit mode on a test group, review for one to two weeks and only then switch to block mode.
In development and administration, AI agents are in use that do more than answer questions: they read files, change code and run commands. That saves time. It also moves a risk onto the endpoint that traditional protection has not covered so far. Microsoft has introduced a dedicated protection feature for this in Defender for Endpoint.
What is prompt injection, in plain terms?
An AI agent cannot reliably tell your instruction apart from text it reads along the way. Prompt injection exploits this: someone hides an instruction in a file, a web page, an email or a software project’s documentation. When a coding agent such as Claude Code or GitHub Copilot CLI reads that content, it may follow the hidden instruction as if it came from you.
A typical pattern: an agent fetches a documentation page containing invisible text that tells it to send local configuration files with credentials to an external address. The agent treats this as part of the task.
Why does this matter to management?
Local agents run with the permissions of the signed-in person. On an administrator’s or developer’s laptop those permissions are often extensive: access to source code, credentials for cloud environments, connections to production systems. A single injected instruction can then lead to data exfiltration, modified code or harmful commands being run.
For you, this means: if you allow AI agents, you need a rule on which agents may work where, and a technical control that detects misuse. Without both, it is hard to demonstrate after an incident that appropriate measures were in place.
What does runtime protection in Defender for Endpoint do?
Defender inspects the points in the agent’s workflow where content enters or leaves its reasoning. There are two methods:
- Agent-native event inspection: agents such as Claude Code and GitHub Copilot CLI expose vendor-supported event interfaces. Defender uses them to check inputs and planned actions just before execution and to stop them if needed.
- Network inspection: for agents without such interfaces, Defender inspects the traffic between the agent and the language model. Agents that use certificate pinning or HTTP/3 are not supported.
Which agents are covered by which method is listed in the support matrix. The list changes during the preview, so check it before any planning.
On a detection, Defender raises the alert Suspicious AI prompt injection and correlates it into incidents. In block mode the action is prevented and the user sees a message in the agent and a Windows notification. In audit mode the action continues and the alert is classed as informational. The setting is protected by Defender’s tamper protection.
What are the prerequisites?
The protection requires the following:
- Licence: Microsoft Defender for Endpoint Plan 2, Microsoft 365 E5, Microsoft Agent 365 or Microsoft 365 E7.
- Device: onboarded to Defender for Endpoint, a supported Windows version, Microsoft Defender Antivirus in active mode with real-time protection and current platform, engine and security intelligence updates. The signature version must be 1.451.224.0 or later.
- Preview: during the public preview, test devices should receive platform and engine updates from the Beta Channel.
- Administration: an Intune role with rights for device configurations to deploy via Intune, and a role such as Security Reader to review alerts.
If another antivirus product is active and Defender only runs in passive mode, the feature does not apply.
How do I roll out the protection without disruption?
Four steps have proven useful:
- Test: enable runtime protection in audit mode on a few devices where supported agents are actually used.
- Review: monitor alerts in the Microsoft Defender portal for one to two weeks and classify false positives.
- Deploy: roll out audit mode to further device groups.
- Enforce: once accuracy is confirmed, switch to block mode.
In Intune, deployment runs through Endpoint security > Antivirus > Create policy, platform Windows, profile Microsoft Defender AI agent runtime protection. There you set Ai Agent Protection to Audit or Block. The profile controls agent-native event inspection; network inspection is deployed with a PowerShell platform script. Afterwards, check on the device page in the Defender portal under Configuration management > Effective settings that the value has arrived. Open terminal sessions must be restarted.
For a safe functional test, there is a demonstration with a harmless test prompt. Use it only on devices you are authorised to test.
What does the feature not cover?
- Cloud-hosted agents: runtime protection applies to local agents on endpoints. Agents running in cloud services are not within the scope of this feature.
- Browser-based AI tools: they are not listed in the runtime protection support matrix.
- Other operating systems: runtime protection currently supports Windows only. For macOS there is so far only discovery of local agents (also in preview), not runtime protection.
- Unlisted agents: anything not in the support matrix should be treated as unsupported.
What else belongs in a policy for AI agents?
Runtime protection is a technical control. A policy for AI agents should also define:
- Approved agents: which agents are allowed and in which version. Local AI agent discovery in Defender for Endpoint shows what is actually in use.
- Workspaces: which repositories and environments agents may work in, and where not, for example with access to production systems.
- Secrets handling: no credentials in local files an agent can read; use a secrets manager such as Azure Key Vault instead.
- Approvals: risky actions such as commands with system privileges only after confirmation by the person at the device.
- Ownership: who assesses runtime protection alerts and within what time.
The next step
You are accountable for how AI is used in your organisation. We make AI adoption audit-ready and provide the evidence. As part of Endpoint Security we set up runtime protection via Intune and support the review during audit mode. With AI Foundation we create the organisational framework: approved agents, policies and documentation.
Frequently Asked Questions
Is runtime protection for AI agents ready for production use?
No. The feature is in preview, as of October 2026. Features and support may change before general availability. Running it in audit mode on test devices is a sensible way to gain experience before a broad rollout.
Does the protection slow down work with the agent?
These are short inline checks at defined points rather than continuous monitoring of the agent process, so the added latency is minimal. In audit mode nothing is blocked, which lets you assess the effect in daily use before switching to block mode.
Is Microsoft Defender for Business sufficient for this feature?
The licensing prerequisites are Defender for Endpoint Plan 2, Microsoft 365 E5, Microsoft Agent 365 or Microsoft 365 E7. Defender for Business is not among them. Check the current requirements before making a licensing decision.
Does runtime protection replace a policy for AI agents?
No. It detects and blocks injected instructions on supported devices. Which agents are allowed, which data they may access and how credentials are protected is something the organisation has to define and document itself.