Microsoft added several public preview capabilities that make local AI agents on Windows endpoints more visible and manageable.

In Microsoft Defender XDR, the June 2026 what’s new page lists local AI agent discovery for onboarded Windows devices. Microsoft says supported coding agents, IDE extensions, desktop AI assistants, local AI runtimes, and agent platforms can appear in the AI agent inventory, exposure map, and advanced hunting.

The same Defender XDR update also lists preview runtime protection for supported local AI agents on Windows endpoints. Microsoft describes this as inspection of the agent loop, including user prompts, tool calls, and tool responses, with the ability to audit or block risky activity before it executes.

In Microsoft Intune, the June 2026 service release adds a public preview path for detecting and blocking Shadow AI on Windows. Microsoft describes three pieces: a properties catalog policy to collect the Local AI Agent entity, Device Query to view devices with a local AI agent, and the Local AI Agent Baseline - OpenClaw (Preview) to block OpenClaw.

Microsoft also notes that the Defender XDR advanced hunting table AgentsInfo is now in preview, and that AIAgentsInfo remains accessible until July 1, 2026 while customers update queries.

Why admins should care

This is not just another inventory feature. Local AI agents are starting to behave like operational tooling on endpoints. They can read files, call tools, generate code, interact with browsers, and run inside developer or productivity workflows.

For Microsoft 365 admins, this changes the rollout conversation from "do we allow AI tools?" to a more practical question: "which AI agents are present, where are they running, and what controls do we have if one becomes risky?"

The useful part is the combination:

• Defender XDR gives security visibility, hunting, exposure, and runtime protection signals.
• Microsoft Intune gives endpoint management controls, Device Query, and a preview baseline for blocking a supported local agent.
• Advanced hunting gives teams a way to build repeatable evidence instead of relying on screenshots or one-off checks.

For me, this is the kind of change I would treat as an early governance signal, not as a reason to block everything immediately.

What I would check first

I would start with visibility before enforcement.

1. In Microsoft Defender portal, check whether AI agent inventory and exposure views are available in the tenant.
2. In Microsoft Defender XDR > Advanced hunting, review any existing queries that use AIAgentsInfo and plan to move them to AgentsInfo before July 1, 2026.
3. In Intune admin center > Devices > Device query, check whether Local AI Agent data is available for Windows devices.
4. In Intune admin center > Devices > Configuration, review the properties catalog option for collecting the Local AI Agent entity.
5. If OpenClaw is relevant, review the preview Local AI Agent Baseline - OpenClaw before assigning it.

I would not start by broadly blocking preview controls across all users. A better first step is a small pilot group, documented exceptions, and clear validation in Defender XDR and Intune.

Practical rollout / validation steps

A safe rollout could look like this:

1. Inventory first
   Confirm which supported local AI agents are detected and where the signal appears: inventory, exposure map, advanced hunting, or Intune Device Query.

2. Update hunting content
   Move any early AI-agent hunting logic from AIAgentsInfo to AgentsInfo. Keep the old query only as a temporary compatibility check until the Microsoft retirement date.

3. Pilot Intune collection
   Use a small Windows pilot group for the properties catalog policy. Validate that the collected Local AI Agent entity appears where expected.

4. Decide the policy posture
   Separate discovery, audit, and blocking decisions. Some environments may only need visibility at first. Others may need blocking for specific unsupported agents.

5. Validate user impact
   If testing the OpenClaw baseline, validate that the block is visible to support staff and that exceptions can be handled without creating unmanaged workarounds.

Watch-outs

These features are in public preview, so I would avoid treating them as a complete AI governance platform.

A few practical cautions:

• Supported agent coverage may not include every local AI tool users install.
• Runtime protection is described for supported local AI agents, not all possible AI workflows.
• Blocking one agent does not solve browser-based AI usage, SaaS connectors, unmanaged extensions, or data handling policy by itself.
• If you already created hunting queries against AIAgentsInfo, the July 1, 2026 transition to AgentsInfo needs cleanup.
• Intune blocking should have a pilot, an exception path, and a helpdesk-ready explanation.

What changed after reading these updates is that I would now put local AI agents into the same governance backlog as browser extensions, developer tools, and SaaS app discovery. Not panic, but visible ownership.

Official Microsoft sources

• What’s new in Microsoft Intune - Week of June 8, 2026
• What’s new in Microsoft Defender XDR - June 2026

Microsoft added new preview capabilities in the June 2026 Microsoft Defender XDR updates for local AI agents on endpoints.

The first change is local AI agent discovery. Microsoft Defender can automatically discover supported local AI agents and MCP servers on onboarded devices and show them in the AI agent inventory, exposure map, and advanced hunting.

The second change is local AI agent runtime protection for supported Windows endpoints. Microsoft says Defender can inspect the agent loop, including user prompts, tool calls, and tool responses, and either audit or block risky activity before it executes.

This is still preview functionality. I would treat it as visibility and pilot material first, not as a finished replacement for normal endpoint, data, and identity controls.

Why admins should care

Local AI tools are easy to introduce quietly. Coding agents, IDE extensions, desktop assistants, local runtimes, and MCP-based tooling can appear on endpoints before the security team has a clean inventory.

That creates a practical governance gap:

• Which endpoints have local AI agent tooling installed?
• Which tools are running in developer or admin-heavy groups?
• Are there MCP servers or extensions that can touch files, browsers, terminals, or internal data?
• Can security operations see risky agent activity as part of normal Defender investigation workflows?

For Microsoft 365 admins, the useful part is not the AI branding. It is the shift from asking users what they installed to checking endpoint evidence in Microsoft Defender portal.

What I would check first

I would start with discovery before blocking anything.

1. Confirm the devices are onboarded to Microsoft Defender for Endpoint.
2. Confirm Microsoft Defender Antivirus is active and current on the pilot devices.
3. Open Microsoft Defender portal and review the AI agent inventory for discovered local agents.
4. Compare findings against expected developer, automation, and test-device use cases.
5. Document which agent types are acceptable, which need exception review, and which should be removed.

Microsoft’s discovery documentation also notes some important boundaries: discovery is for investigation and visibility. It does not by itself provide posture assessment or alerts for endpoint agents.

Practical rollout / validation steps

For a first pilot, I would keep the scope narrow:

1. Pick a small set of Windows endpoints where local AI tooling is expected.
2. Validate that discovery works without extra scripts beyond normal Defender for Endpoint onboarding requirements.
3. Review discovered agents in the Defender portal and map them to known business use cases.
4. If runtime protection is tested, use a separate pilot ring. Microsoft currently states that runtime protection is available only on devices configured to receive Beta platform and engine updates.
5. Run runtime protection in audit mode first where possible, then review Defender alerts before considering block behavior.
6. Feed the result back into endpoint standards: approved tools, unsupported tools, owner, pilot group, and review cadence.

What changed after rollout in a setup like this is simple: the discussion moves from “we think these tools exist” to “we have endpoint evidence and can decide what to allow.”

Watch-outs

A few points are worth being careful with:

• This is preview. Do not over-promise coverage.
• Runtime protection is narrower than discovery and has stricter prerequisites.
• Discovery can include supported Windows and macOS devices, but runtime protection is currently described for supported Windows devices.
• Sovereign and national clouds are not supported for discovery according to the Microsoft documentation.
• Visibility is not the same as governance. You still need policy, ownership, exception handling, and user communication.

My practical take: this is worth testing now if AI agents are already showing up in your endpoint estate. Start with inventory, then move to audit, and only then consider blocking for specific supported scenarios.

Official Microsoft sources

• Microsoft Defender XDR what’s new - June 2026
• Local AI agent discovery with Microsoft Defender for Endpoint
• Set up AI agent runtime protection with Microsoft Defender for Endpoint
• Microsoft Defender for AI security overview

Microsoft has updated the Microsoft Defender XDR advanced hunting schema for AI agent inventory.

The old preview table, AIAgentsInfo, is transitioning to AgentsInfo. Microsoft says AIAgentsInfo remains accessible until July 1, 2026, and Microsoft Agent 365 customers should use AgentsInfo today.

This is still marked as preview, so I would treat it as an operational signal, not as the only source of truth for AI governance.

Why admins should care

This is a small schema change with a real operational impact.

If you already built Defender XDR advanced hunting queries, saved hunting queries, workbooks, Sentinel content, or export jobs around AIAgentsInfo, those queries need to be reviewed before the July deadline.

The more interesting part is the data model. AgentsInfo is not just a name change. The table gives admins a place to inspect AI agent metadata such as:

• agent name and platform
• Microsoft Entra agent identity references
• permissions and consent state
• deployment scope
• owners and sharing
• declared data sources and tools
• MCP servers and external endpoint information
• guardrails, triggers, skills, and connected agents

For Microsoft 365 admins, that makes this a useful starting point for AI agent inventory and risk review. It does not replace policy design, ownership review, or data access governance, but it gives a practical hunting surface.

What I would check first

I would start by finding anything that still references the old table name.

In Microsoft Defender portal > Hunting > Advanced hunting, check saved queries and custom detection logic for AIAgentsInfo.

A minimal validation query for the new table is:

AgentsInfo
| take 10

Then I would run a small inventory view:

AgentsInfo
| project Timestamp, AgentName, Platform, LifecycleStatus, PublishedStatus, DeploymentScope, Owners
| order by Timestamp desc

For governance review, I would also look at permissions and external connectivity signals:

AgentsInfo
| project AgentName, Platform, Permissions, DeclaredDataSources, DeclaredTools, McpServers, Endpoints
| order by AgentName asc

The exact value is tenant-dependent. In some environments the first useful outcome may simply be confirming that the table is present and whether any agent inventory is visible yet.

Practical rollout / validation steps

My preferred rollout would be simple:

1. Search saved hunting queries, Sentinel content, and documentation for AIAgentsInfo.
2. Copy one query and replace the table with AgentsInfo.
3. Validate that the referenced columns still exist in the Microsoft Learn table schema.
4. Keep the old query only as a temporary fallback during the transition.
5. Update any dashboard or export labels so the owner knows the data comes from the preview AgentsInfo table.
6. Add a reminder before July 1, 2026 to remove the old table reference.

This is also a good moment to decide who owns agent review. AI agent inventory crosses normal boundaries between security, identity, productivity, and data governance.

Watch-outs

A few things I would not overclaim:

• AgentsInfo is marked as preview.
• Inventory visibility is not the same as runtime control.
• A clean query result does not prove that every AI-related risk is governed.
• Permissions and data source fields should be reviewed together with Entra ID, Microsoft 365 admin center, and Purview controls where relevant.

The practical win is reducing blind spots. If AI agents are becoming part of the Microsoft 365 estate, hunting queries and reporting should not break because of an old preview table name.

Official Microsoft sources

• What’s new in Microsoft Defender XDR
• AgentsInfo table in advanced hunting