You’ve secured your endpoints against unauthorized apps. You’ve locked down USB drives, blocked untrusted publishers, and reviewed every Win32 package before it touches production. But there’s a new category of software quietly running on your managed devices that most Intune configurations don’t touch: local AI agents.
As of May 2026, Microsoft has an answer. The Shadow AI page in Agent 365, launched alongside Agent 365’s general availability on May 1, gives IT and security teams a dedicated place to discover unmanaged local AI agents running on Intune-enrolled Windows devices and push blocking policies with a few clicks. This guide walks through exactly how it works, what you need to set it up, and where the gaps still are.
What Counts as Shadow AI, and Why Should Desktop Engineers Care?
Shadow AI is any AI tool or agent operating on a device without IT awareness or formal approval. Where shadow IT used to mean unmanaged SaaS subscriptions, shadow AI includes local agents: processes running directly on the endpoint that can read files, execute code, call external APIs via MCP servers, and act on a user’s behalf without ever touching a managed cloud service.
The most visible example right now is OpenClaw, an open-source autonomous AI agent that users install locally and configure with their own credentials and MCP tool chains. Unlike a browser extension or SaaS subscription that leaves a network footprint, OpenClaw runs as a local process. Without specific telemetry from Defender, it’s invisible to standard Intune compliance checks and app inventory.
The risk profile is real. A misconfigured local agent can:
- Read and exfiltrate files without triggering DLP policies that only watch cloud traffic.
- Call MCP servers with elevated permissions tied to the user’s identity.
- Make changes across the filesystem or code repositories without leaving an audit trail in your SIEM.
- Serve as a vector for prompt injection attacks if connected to external data sources.
Microsoft’s own announcement noted that local agents “can read files, execute code, and act on a user’s behalf, enabling access to sensitive data or risky operations without touching managed cloud services.” That’s the core problem. Standard Intune app protection policies were built for managed apps with known publishers. They were not built for autonomous agents that a developer built and a user compiled locally.
What the Shadow AI Page Actually Does
The Shadow AI page is a dedicated section in the Microsoft 365 admin center, separate from the main Agents registry. It’s built specifically for unmanaged, locally running agents, specifically agents that aren’t registered in your Agent 365 control plane because they were never approved in the first place.
The page currently supports one agent: OpenClaw, with detection and blocking both available. Support for GitHub Copilot CLI and Claude Code is on the roadmap and expected to expand over the coming months.
From the Shadow AI page you can:
- Enable continuous detection. Intune pushes a discovery policy that scans managed Windows devices for OpenClaw execution paths.
- View detected devices. See a list of every enrolled device where OpenClaw has been found, including device name, type, OS, and last Intune sync time.
- Push a block policy. One action creates and deploys an Intune policy named A365 - Block OpenClaw that closes the common execution paths on all managed Windows devices.
The integration runs through Microsoft Defender for endpoint telemetry and Intune for policy enforcement. You don’t need to write a custom Intune script or build a detection rule from scratch. The policy is pre-built and pushed automatically when you enable blocking.
Prerequisites
Before you can use the Shadow AI page, you need the following in place:
- Microsoft 365 E3. the minimum license tier to access Shadow AI detection. E5 adds Defender-powered asset context mapping, which gives you a relationship graph showing which MCP servers and cloud resources a local agent can reach. That context mapping arrives in June 2026.
- Frontier preview enrollment. Shadow AI is currently part of the Frontier preview program. You opt in through the Microsoft 365 admin center. Without this, the Shadow AI section doesn’t appear in the navigation.
- Microsoft Intune enrollment for Windows devices. detection and blocking only apply to Intune-managed Windows endpoints. BYOD devices, non-enrolled machines, and macOS are not currently in scope.
- An appropriate admin role. Security Administrator, AI Administrator, Intune Administrator, Security Operator, Security Reader, Reports Reader, or Global Reader. Read-only roles can view detected devices but can’t push policies.
If your organization is already running Intune for endpoint management and has M365 E3 or higher, the main gate is the Frontier enrollment step.
Step-by-Step: Detecting Shadow AI Agents
Step 1: Enroll in the Frontier preview
In the Microsoft 365 admin center, navigate to Settings > Org settings and look for the Frontier preview toggle. Enabling this unlocks the Shadow AI (Frontier) section under the Agents node in the left nav.
Step 2: Navigate to Shadow AI (Frontier)
From the left nav in the M365 admin center, expand Agents and select Shadow AI (Frontier). You’ll see a list of known shadow AI agents currently supported for detection. At launch, that list contains one entry: OpenClaw.
Step 3: Enable detection
Select OpenClaw from the list to open the details pane. Switch to the Security policies tab. Under security policies, select Continuously detect managed devices, then confirm by selecting Apply policies.
This pushes an Intune detection policy to all enrolled Windows devices. The policy uses Defender telemetry to look for the execution paths OpenClaw commonly uses, including installer artifacts, process signatures, and scheduled task registrations.
Step 4: Wait for device sync
Intune policy propagation isn’t instant. Depending on device check-in frequency and network conditions, allow between 15 minutes and 8 hours for devices to sync and report back. After the initial sync window, the Detected devices tab in the details pane will populate with a count and list of devices where OpenClaw was found.
Step 5: Review the device list
The detected devices view shows device name, device type (desktop, laptop, virtual machine, server), operating system, and last Intune scan timestamp. Use this list to assess the scope before deciding whether to block. In some environments, particularly engineering organizations, OpenClaw may be an approved development tool for specific teams, and blanket blocking may not be appropriate. Cross-reference the device list against your team directory before proceeding.
Step-by-Step: Blocking OpenClaw via Intune
Once you’ve reviewed detected devices and confirmed that blocking is appropriate, the deployment is one action:
Step 6: Enable the block policy
Back in the Security policies tab of the OpenClaw details pane, select Block AI agents from OpenClaw, then apply. This creates the A365 - Block OpenClaw Intune policy and deploys it automatically to all managed Windows devices enrolled in Intune.
The policy targets the execution paths OpenClaw commonly uses: startup registry entries, scheduled tasks, and known binary locations. Blocking via this method means you don’t need to enumerate every possible installation path yourself; Microsoft maintains the policy definition as OpenClaw evolves.
Step 7: Verify in Intune
To inspect what exactly was deployed, search for A365 - Block OpenClaw in the Intune admin center under Devices > Configuration profiles. The policy is fully editable in Intune if you need to scope it to specific device groups. For example, you can allow OpenClaw on devices assigned to your AI development team while blocking it everywhere else. Editing the scope in Intune doesn’t break the Agent 365 management relationship; the policy remains visible and manageable from both consoles.
Step 8: Monitor deployment status
Standard Intune policy reporting applies. Use the Device and user check-in status view in Intune to confirm that the blocking policy has applied successfully across your estate. Devices that check in but report an error status on the policy warrant individual investigation. A Windows Update dependency or a conflicting policy with a higher-priority scope.
What the June 2026 Update Adds
The Shadow AI page today gives you detection and blocking. The June 2026 update from Microsoft will add asset context mapping via Defender, which layers relationship data onto each detected local agent:
- Which devices the agent runs on.
- Which MCP servers the agent has been configured to call.
- Which identities are associated with the agent.
- Which cloud resources those identities can reach.
This context changes the analysis from “OpenClaw is present on 47 devices” to “OpenClaw on these 12 devices is configured with credentials that have write access to your Azure DevOps repositories.” That’s a materially different risk signal and should allow security teams to prioritize response by actual blast radius rather than raw device count.
The June update will also bring runtime blocking. Defender will be able to interrupt a coding agent mid-execution if it exhibits behavior patterns consistent with data exfiltration or unauthorized access, and generate an incident alert in the Defender portal with full context for investigation.
Limitations Worth Knowing
A few honest constraints to factor into your rollout planning:
Coverage is narrow right now. OpenClaw is the only agent with detection and blocking support at launch. GitHub Copilot CLI and Claude Code are explicitly called out as “coming soon,” but there’s no specific date. If your environment has users running autonomous Claude Code agents with their own MCP configurations, you can’t block those through the Shadow AI page yet.
Intune enrollment is a hard requirement. Detection and blocking only apply to Intune-managed Windows devices. If you have a segment of unmanaged or BYOD Windows endpoints, those aren’t visible in this workflow. macOS support is not mentioned in any current documentation.
The Frontier program is a gate. Enrolling in Frontier exposes you to preview features that can change or be removed. If your organization has strict change control requirements around preview capabilities, that’s a conversation to have before enabling the Shadow AI page in production.
Detection latency is real. The 15-minute to 8-hour sync window for Intune policy propagation means there’s a window after enabling detection or blocking where devices aren’t yet covered. In a fast-moving incident where you’ve discovered an active agent exfiltrating data, this pipeline isn’t a replacement for Defender’s real-time response capabilities.
Policy editing carries risk. Because the A365 - Block OpenClaw policy is editable in Intune, an admin with sufficient Intune permissions could inadvertently change the scope or conditions and leave gaps in coverage. If you have multiple Intune administrators, document the Agent 365 policies clearly and consider a naming convention or scope tag that signals they’re managed by the Shadow AI workflow.
What’s Coming Beyond OpenClaw
Microsoft’s roadmap for Shadow AI detection follows adoption curves in the enterprise. OpenClaw gets first support because it’s the most widely deployed autonomous local agent with a user base that has spread beyond developers into business teams. GitHub Copilot CLI and Claude Code are next in line because those are the other two local agents showing up most frequently in enterprise device telemetry.
Beyond specific agents, the Agent 365 May 2026 release notes describe a broader strategy: the local agent inventory discovered through Defender and Intune will be surfaced in the Agent 365 registry, giving IT and security teams a unified view of both approved cloud agents and discovered local agents in a single place. Right now, Shadow AI is a separate page. Over time, local agents that pass through an approval workflow should flow into the main registry.
The enforcement model will also extend. Global Secure Access (Entra network controls) is already in GA for Copilot Studio agents and local endpoint agents with the GSA client installed. That means network-layer filtering (prompt injection protection, web filtering, risky file movement controls) can apply to approved local agents, not just cloud-hosted ones.
Closing Thoughts
The Shadow AI page is a practical addition to the Intune and Defender toolkit for desktop engineers who are watching AI agent proliferation accelerate on their managed estate. The workflow is straightforward: enable Frontier, enable detection, review the device list, push the block policy. The Intune integration means you’re not writing new scripts or maintaining custom detection logic. The policy management lifecycle runs through the same consoles you already use.
The gaps are honest ones. A single supported agent at launch is narrow, macOS support is absent, and the Frontier enrollment requirement means this isn’t generally available for everyone yet. But the plumbing is sound: Defender telemetry feeding into Intune policy, surfaced through a purpose-built admin page, is the right architectural pattern. As coverage expands to Claude Code and GitHub Copilot CLI, the operational lift for desktop engineers stays low because the detection and blocking model scales without requiring new per-agent configuration.
For environments where local AI agents are already appearing in Defender logs without any governance structure around them, this gives you a starting point today.
Resources
- Understand Shadow AI in Microsoft 365 admin center — official docs with step-by-step screenshots
- Microsoft Agent 365 GA announcement — full capability overview including Shadow AI and Windows 365 for Agents
- What’s New in Agent 365: May 2026 — detailed technical breakdown of all GA and preview capabilities
- Assign policies in Microsoft Intune: for inspecting and scoping the A365 - Block OpenClaw policy