The area I looked at is:

Microsoft Defender portal > Assets > AI Agents

The interesting part for endpoint teams is Local agents.

A local AI agent is not just another SaaS app. It can run on a Windows endpoint with the user’s permissions. Depending on the tool, it may read local files, inspect repositories, call tools, run commands, or connect to MCP servers.

That changes the risk model.

A browser-based AI chat is mostly a data governance problem. A local agent is also an endpoint governance problem.

What I corrected before publishing

I had an earlier draft that was too confident around the KQL.

The important correction is this:

AgentsInfo is a real Microsoft Defender XDR Advanced Hunting table, but it is preview and may not be available in every tenant yet. It also depends on the relevant Microsoft Agent 365 / AI security capabilities and preview availability.

So I would not start by building a workbook around it. I would first validate that the table exists:

AgentsInfo
| take 10

If that fails, the tenant does not have the table available yet.

Also, KQL string comparisons need quoted strings. This is valid:

| where LifecycleStatus != "Deleted"

This is not:

| where LifecycleStatus != Deleted

Small detail, but important if people copy/paste queries from a blog post.

What Microsoft documents

Microsoft documents the AI agent inventory as a preview capability. It can include cloud agents and local agents discovered on endpoints.

For local agents, Microsoft Defender for Endpoint can discover supported local AI agents and MCP server configurations on onboarded devices. Runtime protection is a separate preview control that can audit or block supported prompt-injection-driven agent actions.

Microsoft also documents AgentsInfo as the current Advanced Hunting table for AI agent inventory and posture. The older AIAgentsInfo table is being transitioned to AgentsInfo.

The query I would start with

After confirming that AgentsInfo exists, this is the safer starting point:

let Lookback = 30d;
AgentsInfo
| where Timestamp > ago(Lookback)
| summarize arg_max(Timestamp, *) by AgentId
| where isempty(LifecycleStatus) or LifecycleStatus !in~ ("Deleted", "Uninstalled")
| project
    LastSeen = Timestamp,
    AgentId,
    AgentName,
    Platform,
    PublishedStatus,
    LifecycleStatus,
    Availability,
    Owners,
    SharedWith,
    DeclaredTools,
    McpServers,
    Model,
    Endpoints
| order by LastSeen desc

I keep the query close to the documented schema. No guessed columns. No assumed device fields. No workbook logic until the table is proven in the tenant.

Why local agents matter

The risk is not simply “AI is installed”.

The risk is the agent loop:

Prompt, file, webpage or tool output
-> agent reasoning
-> tool call, file access, command or service call
-> action performed as the user

That is where prompt injection becomes relevant. A local agent can read content that contains hidden instructions. If the agent follows those instructions and has tool access, the endpoint becomes part of the attack path.

MCP servers make this even more important to review. They can expand what the agent can reach.

My preferred rollout

I would not block everything on day one.

A safer approach:

1. Confirm whether the Defender AI agent inventory is available.
2. Confirm whether AgentsInfo works in Advanced Hunting.
3. Review discovered agents and MCP server configuration.
4. Separate expected IT, security and developer usage from unexpected endpoint usage.
5. Pilot Defender AI agent runtime protection in Audit mode.
6. Review alerts and workflow impact.
7. Move selected groups to Block only after validation.
8. Use App Control, AppLocker or WDAC separately if the software itself should not run.

Runtime protection and application control are not the same thing.

Runtime protection can help audit or block supported unsafe agent actions. App Control, AppLocker or WDAC controls whether the agent executable is allowed to run.

Watch-outs

A few things I would be careful with:

• This is preview functionality. Expect changes.
• AgentsInfo may not exist in every tenant yet.
• Inventory does not prove data loss. It proves discovery or representation.
• Broad Block mode can break legitimate admin or developer workflows.
• MCP server access should be reviewed like tool access, not harmless metadata.

My practical takeaway:

Find -> classify -> audit -> validate -> block where justified

Defender is not magically solving local AI agent governance by itself. But it is starting to give endpoint and security teams a useful place to begin.

Microsoft references

• Discover AI agents and assess security posture using Microsoft Defender
• Local AI agent discovery with Microsoft Defender for Endpoint
• AI agent runtime protection with Microsoft Defender for Endpoint
• Set up AI agent runtime protection with Microsoft Defender for Endpoint
• AgentsInfo table in the Microsoft Defender XDR Advanced Hunting schema