Agent 365 Just Made OpenClaw Your Problem: A 30-Min IT-Admin Audit

11 min read By AI Skills Directory

Microsoft Agent 365's Shadow AI page went GA May 1. It will tell you which Windows endpoints are running OpenClaw. The Intune policy to block it? Not published yet. Here's what to do today.

Table of Contents

Microsoft Agent 365 went generally available yesterday, May 1. Buried in the GA announcement is a feature most IT admins haven’t priced into their week: a new Shadow AI page inside the Microsoft 365 admin center that discovers OpenClaw running on Windows endpoints. GitHub Copilot CLI and Claude Code are “expanding soon.”

If you’re an IT admin and you’ve been politely ignoring OpenClaw because nobody asked you to govern it — that ended yesterday. Microsoft is now showing you which Windows devices on your fleet are running it, and giving you a button labeled “block.” The page will tell you which user, which device, which path. What it won’t tell you, because Microsoft hasn’t published it yet, is the exact Intune CSP / OMA-URI syntax to actually deploy the block.

That gap is what this audit fills. Thirty minutes, four sections, deployable today.

What Just Changed (90 Seconds)

Microsoft Agent 365 reached general availability May 1, 2026. Inside it, the Shadow AI page started discovering one specific thing: OpenClaw, the popular open-source local-agent runtime that lets users wire up Claude (or any LLM) to their filesystem, browser, and credentials. Per Microsoft’s GA announcement, the page identifies “local agent activity on Windows devices” and lets admins “apply policies to block common OpenClaw execution methods” with one click that links to the Intune admin center.

The discovery is gated to the Frontier program. Per Microsoft Learn, you need an Agent 365 license ($15/user/month standalone, or bundled in Microsoft 365 E7 at $99/user/month). E5 alone doesn’t unlock it.

Coming next, per the same announcement: detection coverage for GitHub Copilot CLI and Claude Code. No public timeline beyond “expanding soon” — though Microsoft Build runs June 2-3, which is the natural next venue.

The reason this matters more than your usual feature drop: OpenClaw is to AI agents what Dropbox was to file sharing in 2012. People install it on their work machine because it makes them faster, and they don’t ask. By the time security finds out, it’s already touched something sensitive. Cisco’s @nik_kale called it “Shadow AI 2.0 — full filesystem access, zero telemetry, bypassing DLP/CASB.” Not wrong.

Why OpenClaw Is the First Tool Microsoft Picked

Microsoft documented the threat model three months ago in their running-OpenClaw-safely post. The five-step compromise chain matters because every Intune policy below maps to one of these steps:

  1. Distribution — malicious skills published to ClawHub (the OpenClaw skill registry).
  2. Installation — skills executed without sufficient approval gates.
  3. State access — attackers retrieve tokens, credentials, and configuration data.
  4. Privilege reuse — valid identity material used through legitimate APIs.
  5. Persistence — configuration changes (OAuth consents, scheduled tasks, approved tools) that survive reboot.

Microsoft’s plain-English read on the runtime: “untrusted code execution with persistent credentials” — unsuitable for standard workstations. Their recommended posture: dedicated VM, dedicated credentials, regular rebuild as an “expected control, not an incident response measure.”

That’s the threat model. Now the audit.

The 30-Minute IT-Admin Audit

Open the Microsoft 365 admin center. You’ll need Frontier program access and Agent 365 licensing on the tenant. The Shadow AI page lives inside Agent 365 (Microsoft hasn’t published the exact navigation breadcrumb yet — it’s the “Shadow AI” tile inside the Agent 365 control plane).

Minute 0-5: Run the Discovery Sweep

Click into the Shadow AI page. Microsoft Defender + Intune feed the inventory. You’ll see a table: device name, signed-in user, OpenClaw version, install path, last-seen timestamp.

What to write down:

  • Total instance count across the fleet.
  • Top three departments by instance count. Engineering will dominate; the surprise is who else.
  • Any device flagged with OpenClaw running outside C:\Users\<user>\.openclaw\ — that’s the renamed-binary or persistence-relocation case.
  • Any user who shows up on more than one device — usually a power user or a credential-shared service account.

If you find zero instances on a fleet of 500+ Windows devices, double-check your discovery scope is set correctly (is the right device group attached?). Zero is possible, but unusual in any org with engineers.

Minute 5-15: Decide Allow / Deny / Monitor (Per Department)

This isn’t a tenant-wide flip. Three policy zones, picked by department, are the usable pattern most security architects on X have landed on this week.

Block (Deny) — Apply to: Finance, HR, Legal, Compliance, anything that touches PII or regulated data. Reason: OpenClaw’s threat model includes “valid identity material used through legitimate APIs,” which is a quiet way of saying “your AI agent will use your real Outlook session to send mail and you won’t see it in audit logs.” Regulated work doesn’t tolerate this.

Monitor (Allow + Telemetry) — Apply to: Engineering, IT, Data Science. Reason: blocking will trigger a shadow-IT response (devs run it on personal laptops connected to corp Wi-Fi instead, which is strictly worse). Allow it on managed endpoints, log everything via Defender for Endpoint EDR, and require Entra Agent ID assignment.

Allow (Sanctioned) — Apply to: developer sandbox VMs only. Reason: Microsoft’s own deployment guidance says OpenClaw belongs on a dedicated VM with dedicated credentials and a rebuild plan. Make that pattern available, deprecate any other path.

The mistake to avoid is “block everywhere, figure it out later.” The block-everywhere position will be reversed within two weeks because someone in Engineering will lose access to a productivity tool, escalate to their VP, who will escalate to the CIO, and you’ll be back at this audit on a tighter clock.

Minute 15-25: Stage the Four Intune Policies

Microsoft’s announcement says “use Intune policies” but does not yet publish the actual CSP / OMA-URI syntax. Per Perplexity-verified search of Microsoft Learn, the configuration profile syntax for OpenClaw-specific blocking isn’t documented as of this writing. So the policies below are the deployable patterns the IT-admin community is converging on, mapped to Microsoft’s own threat-model steps:

Policy 1 — Block default install path (Distribution + Installation steps). Use Intune Configuration Profile → Settings Catalog → Defender → Attack Surface Reduction → Controlled Folder Access. Add %USERPROFILE%\.openclaw\, C:\ProgramData\OpenClaw\, and any custom enterprise-software paths your endpoints use to the protected folders list. This breaks the default install but doesn’t catch renamed binaries — that’s policy 2.

Policy 2 — Block by file hash (Renamed binary case). Use Intune → Endpoint Security → Attack Surface Reduction → Custom rules. Pull the hash of claude-code.exe, openclaw.exe, and the most recent published binary from the OpenClaw GitHub releases. Hash-based policy survives a rename to productivity-helper.exe. Refresh the hashes monthly because OpenClaw ships fast.

Policy 3 — Block scheduled-task persistence (Persistence step). Use Intune → Compliance Policy → custom rule that flags any scheduled task with executable paths matching *\.openclaw\* or known OpenClaw daemon names. Mark non-compliant. Couple with Conditional Access to revoke session tokens until the task is removed.

Policy 4 — Block MCP-server outbound traffic (State access + Privilege reuse). Use Microsoft Defender for Endpoint → Network protection rules. Block outbound traffic to localhost ports commonly used by OpenClaw MCP servers (3000, 3333, 8080-8090 range) only on devices in the Block-policy department list. This is the noisiest of the four — expect false positives from legitimate dev tools using the same ports — so keep it scoped to Finance/HR/Legal device groups, not Engineering.

If your org runs Defender for Cloud Apps, also push the OpenClaw cloud-API endpoints (api.openclaw.ai, claude.ai/api) into the Sanctioned/Unsanctioned lists per your zone decision above.

Minute 25-30: Pre-Stage for Claude Code and Copilot CLI

The same Shadow AI page is going to surface Claude Code and GitHub Copilot CLI within weeks. Two things to do today so you’re not redoing the audit:

  1. Add Entra Agent ID conditional-access policies now. Per Microsoft Entra Agent ID docs, Entra supports both “agent on behalf of user” (GA) and “agent with own identity” (preview). Stand up the on-behalf-of policy now: every AI agent gets a unique identity with its own conditional-access scope. When Claude Code shows up in the Shadow AI inventory, you don’t decide whether to block it — you decide which Entra Agent ID scope to apply.

  2. Document the standard “AI agent intake” form. Three questions: which agent, which department, which Entra Agent ID scope. If a developer wants to run Claude Code, they fill the form. The form takes thirty seconds, and it gets you out of the “every IT admin is the AI committee” pattern that’s about to consume your week.

What This Means for You

If you’re an IT admin at a regulated org (banking, healthcare, defense subcontracting): the four Intune policies above are not optional. The “untrusted code execution with persistent credentials” framing is the language your auditors will use within six months. Get the Block zone deployed this week, even if you have to defer the Allow zone.

If you’re a CISO or security architect: the Shadow AI page is your evidence basis for the next AI Risk Council meeting. Pull the discovery sweep, screenshot the inventory, and bring it. Don’t argue policy abstractly — argue from the actual count of devices on your own fleet.

If you’re a SOC analyst: OpenClaw process names, install paths, and known MCP-server ports go in your detection rules this week. Defender for Endpoint will surface the discovery; your SIEM correlation should catch the behavioral anomalies (an “OpenClaw” process making API calls to Outlook on behalf of a user who isn’t actively using Outlook).

If you’re an engineering manager whose team uses OpenClaw: the answer is not “fight the block.” Build the sanctioned-VM pattern that Microsoft itself recommends, get an Entra Agent ID scoped for it, and present that to security. You’ll keep the productivity, lose the friction.

If you’re a Frontier program customer at a 50-person company: the Shadow AI page might surface zero or one instance, in which case the audit takes ten minutes, not thirty. Still worth running so you have the baseline before Claude Code lands.

What This Audit Can’t Fix

Five honest limits:

  1. Personal laptops on corp Wi-Fi. The Shadow AI page only sees Intune-managed endpoints. The unmanaged laptop a dev brought from home runs OpenClaw all day and you’ll never know.
  2. Mac and Linux. The discovery is Windows-only at GA. Mac and Linux endpoints running OpenClaw don’t appear. If your engineering org is Mac-heavy, the inventory is a partial view at best.
  3. OpenClaw running inside a VM on a managed host. Defender sees the host, not the guest VM. If a developer runs OpenClaw inside Hyper-V or WSL2, you may see “WSL2 process activity” but not the OpenClaw runtime itself.
  4. MCP servers hosted externally. The Network Protection rule blocks localhost MCP ports. An MCP server running on a colleague’s machine across the office, or on a personal cloud VM, doesn’t get caught by this policy.
  5. The “expanding soon” agents. Claude Code and GitHub Copilot CLI aren’t in the Shadow AI inventory yet. Until they are, you have a blind spot for the two most popular alternatives.

The Bottom Line

Yesterday’s GA didn’t add a vendor risk. It added visibility into a vendor risk you already had. The five-minute discovery sweep is free intelligence; the four Intune policies are deployable today using the patterns above; and the Entra Agent ID groundwork pays compound interest as Claude Code and Copilot CLI land in the inventory next.

If you want to deepen the policy framework — including the Conditional Access patterns for sanctioned-VM AI agents — see our companion analysis on Microsoft Agent 365’s 4-model picture for the procurement side, and our Anthropic vs Pentagon vendor audit for the upstream supply-chain-risk question that affects whether Claude Code itself stays sanctionable in DoD-flowed contracts.

For team upskilling on AI-agent security specifically, our AI Agent Security course covers the threat model end-to-end with the Intune + Defender + Entra patterns above as Module 4.

Sources

Build Real AI Skills

Step-by-step courses with quizzes and certificates for your resume