Microsoft OpenClaw Security Warning: Isolate AI Agents and Protect Credentials

The warning itself is not new. On February 19, 2026, the Microsoft Defender Security Research Team published a post titled "Running OpenClaw safely: identity, isolation, and runtime risk." Its main line is that OpenClaw "should be treated as untrusted code execution with persistent credentials" and "is not appropriate to run on a standard personal or enterprise workstation." This post first appeared on February 19. The AI-tools gateway vendor OrcaRouter has now republished the story. That gives an eight-month-old recommendation a fresh headline, but Microsoft has not issued a new November alert.

Who makes OpenClaw?​

Some early coverage got this wrong. Cybernews wrote that "Microsoft's AI assistant OpenClaw should not be operated on a standard personal or enterprise workstation". AIbase also described it as Microsoft's own artificial intelligence assistant.

Microsoft's post does not describe OpenClaw as a Microsoft product. It calls OpenClaw a self-hosted agent runtime that can run on a workstation, VM or container. Skills (add-on code) are often found and installed through ClawHub, which Microsoft describes as OpenClaw's public skills registry. OrcaRouter's relay flags the same mistake. It says the error shows how quickly a vendor warning about a third-party tool becomes a vendor warning about its own.

This matters in practice:

• Microsoft has no OpenClaw patch to ship. This is guidance about third-party software running in your environment.
• The responsibility is yours. If OpenClaw runs on your hosts, your organization owns the host, the installed skills and the agent's saved state.

Why Microsoft says it's risky​

Microsoft does not point to a specific CVE or vulnerability. Its concern is how OpenClaw is designed. According to the post, the runtime can:

• read untrusted text,
• download and run skills (code) from outside sources, and
• take actions using whatever credentials it has been given.

Microsoft says this moves the execution boundary away from fixed application code and toward content and third-party capabilities supplied at runtime. There are no matching controls for identity, input handling or privilege scope. In an unguarded deployment, Microsoft lists three risks:

1. Credential and data exposure. Credentials and accessible data may be exposed or exfiltrated.
2. Memory poisoning. The agent's persistent state or "memory" can be modified, causing it to follow attacker-supplied instructions over time.
3. Host compromise. The host environment can be compromised if the agent is induced to retrieve and execute malicious code.

Microsoft calls these two "supply chains" that feed the same execution loop:

• Indirect prompt injection: malicious instructions are hidden in content the agent reads.
• Skill malware: malicious code arrives as an installable skill.

Microsoft also mentions Moltbook, a platform where agents post and read content. Because many agents read it on a schedule, a single malicious post could reach many agents at once.

Endpoint protection doesn't solve this by default. TechRadar's analysis notes that standard endpoint protection and a properly configured firewall reduce certain threats, yet they do not automatically block logic that uses approved credentials. If a compromised agent uses a valid OAuth token through a legitimate API, the activity can look like normal automation.

Microsoft also describes how an attacker could keep access over time. It walks through a possible five-step attack chain:

1. A poisoned skill is published to ClawHub.
2. A user or the agent installs it.
3. The skill gets at tokens and saved instructions.
4. The attacker reuses those privileges through legitimate APIs.
5. Access persists through configuration changes.

Persistence often doesn't involve a classic malware drop. It shows up as new OAuth consents, scheduled runs, modified agent tasks or tools that stay permanently approved. As TechRadar puts it, an OAuth consent approval or a scheduled task may extend access without immediate warning signs.

Microsoft's minimum safe setup for testing OpenClaw​

Microsoft's first preference is not to install OpenClaw with your main work or personal accounts, and not on a device that holds sensitive data. For most environments, it says the right call may be not to deploy it at all. If you do have a legitimate reason to evaluate it, Microsoft lists five baseline guardrails:

1. Run it only in isolation. Use a dedicated VM or a separate physical device that isn't used for daily work, and treat it as disposable.
2. Give it dedicated credentials and non-sensitive data. Create accounts, tokens and datasets just for the agent, and plan to rotate them regularly.
3. Watch for changes to its state or memory. Check saved instructions for unexpected persistent rules, newly trusted sources or behavior that changes between runs.
4. Back up state so you can rebuild quickly. Backing up .openclaw/workspace/ saves working state without credentials. Backing up the whole .openclaw/ directory also saves tokens and credentials. That makes the backup more sensitive, and it may be the wrong choice if you think those credentials are compromised.
5. Plan on rebuilding. Reinstall on a regular schedule, and rebuild right away if you see odd behavior.

A developer writing on DEV Community agreed the advice is sound but called it wildly impractical for most people running OpenClaw. That's a fair point for hobbyists. Enterprises have less room to complain: a spare VM costs far less than cleaning up after a stolen token.

Mapping the guidance to Microsoft security tools​

The second half of Microsoft's post matches each control to a Microsoft product:

Microsoft sells all of these tools, so treat the table with that in mind. The underlying ideas (least privilege, egress filtering, consent governance, DLP) apply whatever security stack you use. None of these products makes OpenClaw safe on its own.

Hunting for OpenClaw in your environment​

The most useful part for administrators is the set of Defender XDR Advanced Hunting queries. The basic inventory query searches DeviceProcessEvents for the past 30 days:

DeviceProcessEvents
| where Timestamp > ago(30d)
| where ProcessCommandLine has_any ("openclaw","moltbot","clawdbot")
or FileName has_any ("openclaw","moltbot","clawdbot")
| project Timestamp, DeviceName, AccountName=InitiatingProcessAccountName, FileName, FolderPath, ProcessCommandLine
| order by Timestamp desc

The other queries look for:

• Container and Kubernetes workloads, using CloudProcessEvents for workloads that send telemetry through Defender for Cloud.
• ClawHub skill installs, by pulling the skill name out of clawhub install command lines and flagging rarely seen skills.
• VS Code extension churn on developer machines.
• High-privilege OAuth apps in OAuthAppInfo. This needs App Governance turned on.
• Listening ports opened by agent processes.
• Agent processes launching cmd.exe, PowerShell, bash, curl or wget.

Microsoft's triage advice is consistent. First, check whether the device belongs to an approved pilot. Then compare skills against an approved list to catch lookalike names, and look for follow-on activity. If an agent listener can be reached from outside its intended boundary, isolate the host and rotate every identity the agent used. A hit from these queries is a starting point for investigation, not proof of compromise.

Intune's preview OpenClaw baseline​

Microsoft has also built OpenClaw controls into Intune. Microsoft Learn documents a "Local AI Agent Baseline - OpenClaw" security baseline, currently Preview, Version 1. The reference page was last updated June 2, 2026. The baseline is meant to limit unauthorized local AI agents by disrupting the paths they commonly use to run. It includes two firewall rules that block outbound TCP from Node.js at:

• %LOCALAPPDATA%\Programs\node\node.exe
• %ProgramFiles%\nodejs\node.exe

It also includes settings for Windows Subsystem for Linux.

Microsoft's documentation is careful about the limits. The settings may not block every way an agent can run, and they may also block processes other than OpenClaw. Teams that rely on Node.js or WSL should expect breakage. Microsoft says to review and test each setting before deployment and to disable any setting whose impact on legitimate work is unacceptable. It also suggests using the Intune properties catalog to collect a Local AI Agent inventory before you deploy the baseline. In practice:

1. Run the inventory.
2. Pilot the baseline on a test ring.
3. Tell your developers before their Node.js toolchain stops reaching npm.

The bigger picture​

Microsoft's own summary is the best guide here. It says running OpenClaw is not just a configuration choice. It is a decision about which machine, identities and data you are prepared to expose to an agent that will eventually read malicious input.

Microsoft recommends three steps right away:

1. Inventory where the runtime is deployed.
2. Check which identities it uses and what permissions they have.
3. Identify which inputs can influence what tools it runs.

None of this means every OpenClaw install is compromised. It means agent runtimes need the same treatment as any other privileged code from the internet: give it its own VM, its own credentials and a plan to rebuild it. On your main workstation, every OAuth token you hold is within its reach.