For Windows administrators, the immediate question is not simply which vendor shipped first. It is whether a control discovers an agent, inspects its instructions, blocks a particular action, or interrupts its access to a service. Those distinctions should determine the pilot plan—and prevent a purchase order from becoming an expensive substitute for testing.
What changed—and what the labels actually mean
The availability picture as of November 15, 2026, is more nuanced than a simple ranking:
| Platform or capability | Verified status | Important boundary |
|---|---|---|
| Microsoft Defender local AI-agent discovery | Generally available on supported Windows and macOS devices, with specified preview exceptions | Discovery does not establish runtime protection |
| Microsoft Defender AI-agent runtime protection | Public preview | Support depends on the agent and inspection method |
| CrowdStrike Falcon Guardian | Generally available since September 2026, according to CrowdStrike | Individual additions can have different rollout stages |
| SentinelOne Singularity ADR | Early access from October 21, 2026 | Launch claims do not establish universal deployment eligibility |
Microsoft’s support matrix separates discovery from enforcement and expressly retains preview scenarios. CrowdStrike’s November announcement confirms Guardian’s September availability, while SentinelOne’s launch establishes ADR’s early-access status. None of those labels is an independent effectiveness score.
The buying implication is straightforward: ask for availability and support commitments for the specific capability, not merely the platform carrying it. “Generally available” on the cover does not guarantee that every control described inside has shipped.
Microsoft: inventory is not enforcement
Microsoft’s October feature notes list local AI-agent discovery as generally available, specifying Windows Defender Antivirus platform 4.18.26090.9 or later and macOS Defender for Endpoint 101.26072.0017 or later. WSL discovery remains a preview scenario. These are discovery requirements, not a universal minimum-version statement for every runtime protection method.
The detailed support matrix adds an essential qualification: Windows and macOS discovery are generally available except where individual scenarios remain marked preview. Administrators should therefore avoid treating either “all discovery is preview” or “everything on macOS is GA” as an accurate summary. WSL coverage also should not be interpreted as native Linux endpoint coverage.
Discovery itself has different collection paths. Microsoft can identify a running agent process, while supported VS Code extensions can be inventoried through periodically collected extension data. A process appearing in inventory does not prove that its user submitted a prompt or successfully accessed an AI service; conversely, installing an agent does not guarantee an immediate inventory entry.
That distinction matters during an audit. Treat inventory as evidence of discovered software and configuration—not as a complete usage ledger.
Licensing and antivirus mode matter
Microsoft’s discovery documentation requires a commercial-cloud environment, Defender for Endpoint Plan 2, onboarded devices and supported versions. Its general prerequisites include active antivirus mode and real-time protection, but supported Windows and macOS VS Code extension inventory has an exception: that collection requires a functioning, reporting endpoint client rather than active antivirus or a running extension. MCP-server configuration discovery still requires active mode and real-time protection.
Licensing also separates visibility from posture assessment. Plan 2 provides local-agent inventory and hunting access. Microsoft lists Microsoft 365 E7, or Microsoft Agent 365 alongside Plan 2, for the associated risk levels, risk indicators and recommendations. An organization should not assume its existing endpoint subscription unlocks every agent-security screen.
For procurement, request a capability-by-capability entitlement statement. For operations, record which collection mechanism produced each finding before drawing conclusions about missing agents.
Defender runtime protection: useful checkpoints, explicit limits
Microsoft describes two inspection approaches. Agent-native inspection uses supported event interfaces to examine activity at points such as prompts, tool requests and tool responses. Network inspection instead examines covered agent-to-model traffic. Neither description means continuous inspection of every possible action by every local agent. Microsoft specifically excludes certificate-pinned connections and HTTP/3 from network inspection support.
Two documented preview issues deserve prominent placement in any pilot runbook:
- An alert can claim an action was blocked even when the device is configured for Audit, which allows the action.
- Claude Code can continue processing a tool response despite a reported post-tool-response block. Microsoft identifies this as an enforcement limitation, not merely misleading wording.
Post-tool inspection also cannot undo actions a tool has already completed. The practical lesson: verify the actual result, not just the alert title. A dashboard saying “blocked” is evidence to investigate, not a victory lap.
A bounded Windows pilot
Microsoft’s setup documentation supports this initial sequence:
- Use an onboarded, supported Windows test device with an eligible license, current Defender updates, active antivirus and real-time protection.
- In elevated PowerShell, verify security intelligence version 1.451.224.0 or later:
Get-MpComputerStatus | Select-Object AntivirusSignatureVersion - Enable the required inspection method in audit mode:
Code:Set-MpPreference -AiAgentProtection Audit Set-MpPreference -AiAgentNetworkInspection Audit - Verify effective preferences:
Get-MpPreference | Select-Object AiAgentProtection, AiAgentNetworkInspection - Close agent terminals and start a new terminal before relaunching the agent.
Microsoft documents values of 0 for Disabled, 1 for Block and 2 for Audit, and recommends reviewing detections for one to two weeks before expanding enforcement. Either method can be turned off by setting it to Disabled.
Define pilot success before starting: the intended setting is effective, representative workflows remain usable, detections reach the responsible team, and investigators can distinguish an alert from a prevented action. Do not promote a pilot simply because it generated an impressive number of notifications.
CrowdStrike: GA protection, but inspect the control point
CrowdStrike introduced Falcon Guardian on September 1, 2026, positioning it as AI Detection and Response anchored at the endpoint. Its architectural argument is that agent security requires context about both instructions and execution, rather than governance alone. That is the vendor’s product positioning—not proof of superiority over the other two platforms.
Its November 3 announcement provides more specific deployment boundaries. CrowdStrike says Guardian combines agent-level controls, endpoint network inspection and endpoint activity through a Falcon sensor. The announcement describes its AI Kill Switch as operating first at the gateway, with endpoint enforcement forthcoming. It also says Falcon AI Gateway was already generally available on November 3 and included with Guardian; November 13 should therefore not be presented as its first confirmed GA date.
The distinction is operationally significant. Interrupting an agent’s gateway access is not equivalent to terminating its local process. A buyer evaluating an agent that performs substantial local work should require a demonstration of precisely what stops, what continues and what recovery looks like.
CrowdStrike’s published licensing FAQ introduces another consideration: Guardian entitlement is calculated from licensed endpoints multiplied by four million tokens per endpoint per month, measured at account level. Thus, “licensed by endpoint” does not tell the complete capacity story.
Ask the vendor to model that allowance against representative workloads and document additional-capacity terms. Count devices, but measure agent activity too. A developer workstation running frequent automated tasks should not automatically be budgeted like a laptop that occasionally opens an assistant.
SentinelOne: distinguish ADR from the autonomous SOC
SentinelOne’s October 21 launch describes Singularity ADR as combining agent discovery, governance of permitted actions, behavioral monitoring, and detection and response. The company positions it across endpoints, cloud workloads and the broader enterprise, built on the Singularity Platform. It opened early access with the announcement.
That establishes a concrete product event, but not a complete operating-system support matrix, a universal production entitlement or independently measured detection performance. Early-access buyers should obtain written confirmation of supported agents, deployment requirements, response actions and support arrangements.
SentinelOne separately announced Singularity ASOC on October 21. Its autonomous security-operations offering combines Purple Agentic Investigation, AI SIEM, Hyperautomation, AI Data Pipelines and case management, with practitioners defining the limits of automated activity. ADR protects against agent-related threats; ASOC concerns how the security operation investigates and responds. They should not be treated as alternative names for the same product.
This creates two separate evaluation tracks. First, can ADR constrain the agents employees use? Second, what authority would the organization delegate to agents operating inside its own SOC? Require separate acceptance criteria rather than letting one demonstration stand in for both.
How to compare the three without buying the brochure
A defensible evaluation starts with workflows, not a vendor leaderboard. The following is an operational assessment framework, not a claim that the products have passed these tests.
1. Build an agent-by-environment inventory
List the exact agent, version, operating system, execution location and connected tools. Separate desktop applications, command-line agents, IDE extensions and WSL workloads. Record which accounts they run under and what sensitive resources those accounts can access.
For Defender specifically, Microsoft’s support matrix warns that unlisted combinations are not documented as supported. A familiar product name is insufficient; the agent and inspection-method combination matters.
2. Separate four acceptance questions
For each workflow, ask:
- Discovery: Does the platform identify the agent and relevant configuration?
- Detection: Does it recognize the test condition?
- Enforcement: Does the intended action actually stop?
- Investigation: Can an analyst explain the event and its outcome?
Keep these results separate. A discovered agent can remain unprotected, and a generated alert can coexist with a completed action.
3. Test ordinary work alongside safe security demonstrations
Include routine development, approved tool use and expected network access. Record false positives, interruptions and the steps required to recover. Use isolated test devices and non-sensitive data; a security pilot should not need production credentials to prove its point.
Require evidence of both successful prevention and successful legitimate work. Otherwise, the easiest product to “win” is the one that stops everyone from doing anything.
4. Price the actual capability
Request separate line items for endpoint protection, agent-security functionality, investigation services and consumption allowances. For Microsoft, verify posture entitlements separately from inventory. For CrowdStrike, include Guardian’s token allowance. For SentinelOne, establish exactly what early access includes and what commercial terms apply afterward.
5. Make any migration a separate decision
Do not replace an endpoint platform merely to try an agent-security feature. First determine whether the pilot can satisfy its prerequisites within the current architecture.
This is particularly important for Defender: its runtime setup requires active antivirus and real-time protection. A generic plan to leave Defender passive alongside another product does not satisfy those stated requirements.
The practical verdict
CrowdStrike has the clearest vendor-confirmed GA position for its named agent-security offering. Microsoft combines generally available discovery scenarios with preview runtime enforcement and unusually consequential documented caveats. SentinelOne offers an early-access agent-defense product alongside a separate autonomous-SOC initiative. Those distinctions establish availability and design boundaries—not a detection championship.
For Windows teams, the strongest next move is a narrowly scoped, measurable pilot. Verify entitlements, map exact agent support, confirm effective settings and observe what actually happens when enforcement triggers. Choose the platform that demonstrates the required outcome in your environment—not the one whose launch announcement contains the most confident verbs.
References
- Endpoint Protection Platform: 3 AI Agent Defenses (2026) - shattered.io shattered.io · 2026-11-15T21:38:22+00:00
- CrowdStrike Unveils Falcon Guardian to Secure AI Agents Where They Execute: On the Endpoint at Runtime crowdstrike.com
- SentinelOne Brings Security Superintelligence to the SOC With Singularity ASOC | SentinelOne sentinelone.com