Microsoft Defender Local AI Agents: Your Endpoints Have Houseguests
Microsoft Defender finds the AI agents quietly occupying your endpoints.
I opened Microsoft Defender for Endpoint expecting to find Claude Code and maybe Cursor. The Local agents inventory found eight AI agents across two lab devices. Apparently, my endpoints were running a small bed-and-breakfast and forgot to mention it.
Local AI agents are useful, which is exactly why they spread so quickly. A developer can use Claude Code to work through a project. An analyst can clean up a report in ChatGPT Desktop. Nobody had to wait six months for IT to build an AI adoption committee first.
The security problem is not that people use these tools. It is that the agents run as the user, read content from several places, and can call other tools through MCP. The same helpful assistant can read a README, open a local file, and send data to a remote service. That is a lot of trust for something installed five minutes before lunch.
Until now I could explain the risk, but I could not answer the first question an admin should ask. How many local AI agents are actually running?
Microsoft Defender can now handle local AI agent discovery on onboarded endpoints, including supported agents and their MCP server configurations. It adds the results to an AI agent inventory, provides posture information when the right licensing is in place, and can inspect activity at runtime. Everything covered here is still in preview, so test it in your own tenant before writing any of it into a standard.
Why Local AI Agents Are Different From Traditional Shadow IT
We have dealt with unsanctioned tools before. Dropbox, Slack, browser extensions, and whatever free utility somebody found five minutes before a deadline. I wrote about using Defender for Cloud Apps and Defender for Endpoint to block risky cloud apps. Local AI agents start in the same place, except this round the browser extension may also have a command shell.
Microsoft is pretty direct about it. A local agent runs with user-level permissions and can reach the files, tools, and services available from that endpoint. If security cannot see which agents are present or what they are connected to, there is no practical way to judge the exposure.
The user context matters more than the product name. Claude Code on a developer lab machine is one thing. The same agent launched by a platform engineer with standing production access is a very different conversation.
The input side matters too. Agents work with prompts, local files, web pages, and tool output. They do not reliably separate helpful content from a hidden instruction. I covered the network side of that problem in Prompt Injection Is the New Phishing. On the endpoint, one bad instruction in a README or fetched page can steer an agent toward a local .env file or another resource the user can access.
Unsanctioned file sync was a data governance problem. A local AI agent can be a data governance problem holding a command shell.
How Microsoft Defender Discovers Local AI Agents
The first surprise is that there is no discovery package to deploy. If the device meets Microsoft’s prerequisites, Defender starts finding supported local agents automatically.
Those prerequisites are manageable. You need a commercial cloud tenant, Defender for Endpoint Plan 2, and devices onboarded to Defender for Endpoint. The endpoint must run a supported Windows or macOS version. Defender Antivirus also needs current platform and engine updates, active mode, and real-time protection enabled.
If your Defender deployment is healthy, you may already qualify. No extra discovery package, no new client, and no platform script held together with optimism. For a preview feature, that is unusually considerate.
The supported agent list is broader than I expected. A full list can be found here.
Ollama Desktop is worth noticing. Local model runtimes are part of the inventory, so security teams finally get a better answer to the question, ‘Are people running models on company hardware?’ Yes. It is probably the person whose laptop fan sounds like it is preparing for takeoff.
Defender counts an agent as the combination of user, device, and agent type. One user running Claude Code against several project folders on one computer still shows as one entry. Run it on a second laptop and you get a second entry. Keep that definition handy before somebody compares the inventory count with a folder count and decides the data is wrong.
Using the Microsoft Defender AI Agent Inventory
Go to Assets > AI agents > Local agents. My lab showed eight monitored agents across two devices. That included Claude Code, Claude Desktop, Cursor, Codex CLI, Antigravity Desktop, and Perplexity Desktop.
The default view gives you the agent name and version, device, operating system, account, and discovery dates. It looks a little bare at first. Open Customize columns and turn on MCP servers, Local MCPs, and First seen before declaring that Microsoft hid all the useful data. It did. The useful data is just two clicks away.
I would sort by First seen during the initial review. It quickly shows whether you are looking at a stable set of tools or adoption that is still accelerating. If half the entries first appeared in the last month, a one-time cleanup will not solve the problem.
Open an agent and the details pane adds the fields I actually care about. You get the vendor, related process, trusted-process status, auto-approve setting, source agent ID, device information, and user context. My Claude Code entry showed Anthropic as the vendor, claude.exe as the process, Trusted process set to Yes, and Auto approve set to No.
Pay attention to Auto approve. When it is enabled, the agent can move from one action to the next without waiting for the user. Add an untrusted host process and a privileged account, and that entry belongs near the top of the review list.
Party planning tip: Do not walk into the developer standup waving this inventory like a subpoena. Nothing moves a tool onto a personal laptop faster than an admin with a spreadsheet and a grievance. Ask which tools people depend on, which MCP connections are intentional, and what would break if the tool disappeared tomorrow. You need a sanctioned path people will actually use.
Why MCP Server Discovery Matters
The agent name tells you what is installed. The MCP server list tells you what gave that agent hands.
Defender discovers local and remote MCP server configurations tied to supported agents. One Claude Code installation in my lab showed twelve remote servers. The list included Slack, Linear, Figma, Notion, Asana, and Atlassian, with the endpoints visible. It also found two local servers for Calendar and Gmail.
The endpoint value is the field I would export first. A remote endpoint shows where the agent is configured to connect. A local MCP entry shows the command used to start the server on the device. If you followed my Global Secure Access and Sentinel work, the split should look familiar. The network sees the traffic. The endpoint sees the configuration that created it.
You can hunt local AI agents at scale with the AgentsInfo table in Microsoft Defender advanced hunting. It stores profile records for discovered agents, including the publisher, process, trust setting, auto-approve value, MCP configuration, device, and account. This is a useful starting query:
AgentsInfo
| where Platform == "LocalAgents"
| summarize arg_max(Timestamp, Name, Version, LifecycleStatus, RawAgentInfo) by AgentId
| where LifecycleStatus !in~ ("Deleted", "Uninstalled")
| extend M = RawAgentInfo.localAgentMetadata
| extend Vendor = tostring(M.vendor), Process = tostring(M.relatedProcess),
TrustedProcess = tostring(M.trustedProcess), AutoApprove = tostring(M.autoApprove)
| project Name, Vendor, Version, Process, TrustedProcess, AutoApprove
Local AI Agent Risk Scoring and Licensing
An inventory answers what exists. Risk helps decide which entry gets your limited time first.
Defender calculates local-agent posture from configuration, runtime activity, endpoint and user context, and active alerts. The result can be High, Medium, Low, No known risk, or Not evaluated. Documented indicators include use by a critical user, operation on a critical or vulnerable device, and privileged software-development access. The same agent can land at a different risk level depending on who runs it and where.
Licensing changes what you see. Defender for Endpoint Plan 2 includes discovery, inventory details, MCP visibility, and the AgentsInfo hunting table. Risk levels, risk indicators, and security recommendations require Microsoft 365 E7, or Microsoft Agent 365 together with Defender for Endpoint Plan 2. Microsoft 365 E5 includes Plan 2, so E5 gets the guest list. It does not get the background check. For an E5 tenant, build the first report from inventory data and hunting queries instead of waiting for a risk column that never populates.
Configure AI Agent Runtime Protection
Local AI agent discovery gives you visibility. AI agent runtime protection is the feature that can interrupt a risky action before the agent carries it out.
Microsoft Defender AI agent runtime protection can inspect three parts of the agent loop: the user’s prompt, the tool call before it runs, and the tool response after it completes. That last one matters because the bad instruction may arrive in content the agent fetched. Microsoft’s example uses project documentation containing hidden instructions to read a local .env file and send it to an external URL. Defender blocks the action before the data leaves the device.
Configuration currently happens through PowerShell. Agent-native inspection and network inspection each support Disabled, Audit, and Block.
Set-MpPreference -AiAgentProtection Audit
Set-MpPreference -AiAgentNetworkInspection Audit
Get-MpPreference | Select-Object AiAgentProtection, AiAgentNetworkInspectionAfter changing either setting, close every terminal window used to run an agent and open a new one. I missed that step and spent twenty entertaining minutes troubleshooting a feature that was patiently waiting on a fresh process.
Heads up: There is no native Intune policy for these settings yet. Microsoft’s documented deployment method is a PowerShell platform script. Back to platform scripts like it is 2019. Set it to run in the system context so it can change Defender Antivirus preferences. Tamper protection guards the setting after it is applied.
Start with Audit on a small group that actually uses supported agents. Review the informational alerts, submit false positives, and expand the audit group before moving to Block. In Block mode, a detected hijack creates a Suspicious AI prompt injection alert, and the user sees a terminal message plus a Windows notification. Tell the service desk before the toaster does.
A Practical Rollout Plan for Local AI Agents
During the first week, open the AI agent inventory and learn what normal looks like. Sort by First seen, identify the common tools, and resist the urge to block something before lunch just because the export button worked.
Next, use hunting to find agents with auto-approve enabled, untrusted processes, or privileged user context. The overlap is your first review queue. It will probably be much smaller than the full inventory.
Then review MCP endpoints with the teams using those agents. Some connections will be expected. The ones nobody recognizes deserve more attention than another count of installed AI tools.
Finally, choose a developer pilot and enable runtime protection in Audit. Developers are the right group because they carry the most agents and will tell you within the hour if something breaks, loudly, in a channel you already watch. After the pilot, document the expected alerts, expand in stages, and keep a rollback path. My post on Conditional Access for Agent ID covers the identity side of the problem.
Wrapping Up: Count the Houseguests
I do not think the answer is to evict every local AI agent. People like the houseguests because the dishes are getting done, the code is shipping faster, and nobody is volunteering to return to the slow way because security sent an email.
The better starting point is visibility. Find the agents, check the user and device behind each one, review the MCP connections, and decide where runtime protection makes sense.
If your endpoints already meet the Defender for Endpoint Plan 2 prerequisites, the Microsoft Defender local AI agent inventory may be waiting for you now. Open Assets > AI agents > Local agents before the next AI governance meeting. A real list from your own environment beats another slide about hypothetical risk.
