Microsoft announced discovery for 60 local AI agent types on October 19, 2026, adding 35 types to its coverage. For a security team tracking Claude Code, Codex, and GitHub Copilot, the immediate job is to reconcile the larger inventory with the agents employees actually use. Keep a separate record of which deployments have runtime protection.
An agent can appear in Defender while its actions remain outside an enabled inspection path. The announcement also introduces broader agent risk and permission controls, but the local discovery count does not establish that those controls apply to every listed agent. Use the implementation requirements for each control before approving a deployment.
This guide combines Microsoft's documented behavior with a proposed acceptance procedure. General Analysis has not run these queries or tested protection in a Microsoft tenant. For a wider inventory strategy, start with detecting shadow AI.
Define what you expect Defender to find#
Build a small pilot list from your endpoint and software records. Record the device, operating system, account, agent type and version, and the time of a known ordinary agent session. Use non-sensitive pilot work; discovery validation does not require an attack simulation.
Microsoft's discovery overview says the sensor needs to observe activity. An installation alone may not appear. It also defines an agent by the combination of user, device, and agent type: the same user running Claude Code in several folders on one device can still produce one inventory entry.
Comparing project folders with agent profiles creates apparent gaps. Counting only the profiles Defender returned hides missing devices. Keep the expected pilot list independent of the discovery output, and match each entry by device, account, and agent type.
Check the discovery prerequisites: commercial cloud, Defender for Endpoint Plan 2, supported onboarded devices, current antivirus updates, active mode, and real-time protection. The documentation says discovery starts automatically once these conditions are met. Local inventory and hunting are available with Plan 2; risk indicators and recommendations require Microsoft 365 E7 or Agent 365 in addition to the endpoint coverage.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Read the two support lists separately#
Microsoft maintains distinct discovery and runtime support tables. The following is a narrow reading of that matrix on October 19, not a list of every supported product.
| Deployment | Discovery entry | Runtime evidence to require |
|---|---|---|
| Claude Code on Windows | Agent and MCP configuration discovery listed | Windows preview lists native event inspection; verify its effective mode. |
| Codex CLI on Windows | Agent and MCP configuration discovery listed | Codex is absent from the runtime rows; resolve the documentation discrepancy below. |
| Claude Code on macOS | Agent and MCP discovery listed in preview | The runtime section lists Windows combinations; obtain separate support evidence for this deployment. |
| Claude Code, Codex CLI, or Copilot CLI in WSL | Agent discovery listed in preview; MCP discovery not listed | WSL discovery does not establish native Linux or runtime protection support. |
The runtime overview names Codex CLI among agents exposing event interfaces, while the current runtime matrix omits it. This discrepancy leaves the supported deployment unclear. Ask Microsoft to confirm the version and inspection path before approving a Codex deployment as protected, and retain that answer with the pilot record. A missing table row does not prove protection is technically impossible.
MCP configuration discovery also has a narrower meaning than a tool audit. A configured server tells the reviewer where to investigate. It does not establish which calls occurred, what credentials authorized them, or whether a remote service enforced the intended policy. Use the MCP security guide to review that authority.
Retrieve current profiles without hiding missing coverage#
In the Defender portal, open Assets > AI agents > Local agents and export the pilot's records. For a repeatable investigation, use advanced hunting. Start by inspecting the tenant's AgentsInfo schema:
Code source: illustrative read-only KQL.
AgentsInfo
| getschema
Microsoft's local-agent query guide explains that profiles accumulate updates. Select the newest record before excluding removed installations. Filtering out deletion records first can leave an older active record looking current.
The example below keeps identifiers and nested metadata for reconciliation. It deliberately avoids the display-name column: the local-agent guide uses Name, while the general table reference lists AgentName. Confirm the schema before adding either to your saved query.
Code source: illustrative KQL using Microsoft's documented local-agent fields; not executed against a tenant.
AgentsInfo
| where Platform == "LocalAgents"
| summarize arg_max(Timestamp, *) by AgentId
| where LifecycleStatus !in~ ("Deleted", "Uninstalled")
| extend Local = RawAgentInfo.localAgentMetadata
| project AgentId, Version, LifecycleStatus,
ProfileRecordedAt = Timestamp,
Device = tostring(Local.deviceName),
Account = tostring(Local.accountName),
AccountDomain = tostring(Local.accountDomain),
Vendor = tostring(Local.vendor),
McpServers, LocalMcps = Local.localMcps
ProfileRecordedAt is the time the information was recorded. Do not relabel it as the last tool execution. Save the hunting time range with the export; this query can only select records available in that range. If the schema check or query fails, record the failure separately from a successful query returning no rows.
Reconcile each expected pilot entry:
- For a matching profile, confirm the account and device, then attach its
AgentIdto the pilot record. Open the profile to verify the agent type. - For a missing profile, check support, onboarding, antivirus state, observed activity, and the hunting window. Keep the row unresolved until evidence explains it.
- For an unexpected profile, identify the owner and permitted use before adding it to the approved inventory.
Report unresolved entries alongside the eligible, active cohort. Keep unsupported hosts visible as a separate group so the security owner can decide where another sensor or deployment restriction is needed.
Verify the inspection mode on the device#
For a supported Windows pilot, Microsoft's runtime setup instructions distinguish AiAgentProtection from AiAgentNetworkInspection. One enables native event inspection; the other handles covered network flows. They have independent settings.
The same instructions require current Windows and Defender components, specify signature version 1.451.224.0 or later, and direct public-preview test devices to the platform and engine Beta Channel. Confirm those prerequisites with the endpoint owner before changing a production update policy.
Code source: Microsoft's runtime setup checks, combined into a read-only inspection.
Get-MpComputerStatus | Select-Object AntivirusSignatureVersion
Get-MpPreference | Select-Object AiAgentProtection, AiAgentNetworkInspection
Record the values and their configuration source. After applying runtime settings, Microsoft instructs administrators to close agent terminals and open a new terminal before starting the agent. Verify the resulting session, rather than attaching an old session's outcome to the new policy.
Audit mode permits the action and records a detection; Block mode applies enforcement. An alert in audit mode is useful investigation evidence, but it cannot support a claim that the action was stopped. Network inspection also excludes certificate-pinned traffic and HTTP/3, so verify the actual transport before assigning coverage to that path.
Use your approved validation procedure to collect the device, session, effective mode, alert, and action outcome together. No alerts during ordinary work may simply mean there was nothing to detect. The inventory query cannot establish blocking efficacy.
Keep the rollout decision attached to evidence#
The pilot owner should be able to produce one record for each deployment containing its expected identity, discovered profile or unresolved gap, support reference, effective mode, and validation outcome. Give unresolved rows an owner and a next diagnostic step. If runtime coverage is required for the workload, hold that deployment's approval until the missing evidence is resolved.
Continue to restrict the agent's filesystem, network, and service credentials. For Copilot deployments, the local sandbox rollout guide covers those restrictions and session transitions. Prompt-injection inspection adds a detection and response path; the agent still needs a bounded set of permissions for legitimate work.
Frequently asked questions
- Does a discovered AI agent have runtime protection?
An inventory entry alone does not establish protection. Check the exact agent and OS against the runtime support matrix, then verify the effective inspection mode and evidence from that device. Audit mode records detections while allowing actions to continue.
- Why is an installed agent missing from Defender's inventory?
Discovery depends on observed agent activity on an eligible onboarded device. Check the agent and OS combination, device prerequisites, account, and query scope. An absent row does not prove that the agent is absent or prohibited.
- Does Windows Subsystem for Linux discovery cover native Linux?
No. Microsoft's support matrix lists WSL discovery separately in preview and explicitly says that it does not establish support for native Linux endpoints.
