Microsoft: don't run OpenClaw on ordinary work machines

On 19 February 2026 the Microsoft Defender Security Research Team published a post titled "Running OpenClaw safely: identity, isolation, and runtime risk", and in it made a recommendation the Orca AI Incident Archive records against no other entry: OpenClaw "should be treated as untrusted code execution with persistent credentials", and "It is not appropriate to run on a standard personal or enterprise workstation." OpenClaw is a self-hosted agent runtime — the user installs it on their own machine, grants it accounts and tokens, and lets it install skills from a public registry and act on text it reads from anywhere. Microsoft's case is architectural, not a bug report: the runtime shifts the point of execution from static application code to content supplied at run time, and the controls around identity, input handling and privilege have not shifted with it. The post names no CVE, no campaign and no victim, and records no compromise. The full record sits in the Orca AI Incident Archive, where it is classified as a landmark policy entry with confidence grade A and no recorded real harm.

What the post said, and what it did not

The post runs about twelve minutes of reading and carries no disclosure machinery at all: no CVE identifier, no affected version range, no fixed build, no indicator of compromise tied to a real deployment. Microsoft Defender Security Research lists Idan Hen as a contributor. What it carries instead is a threat model and a deployment rule, which is why the archive files it as a policy record rather than an incident — severity info, confidence grade A, no recorded real harm, a single day-precision date.

The reasoning is compressed into one opening paragraph. OpenClaw "includes limited built-in security controls", the team writes, because the runtime "can ingest untrusted text, download and execute skills (i.e. code) from external sources, and perform actions using the credentials assigned to it." The consequence is stated in the same breath: this "effectively shifts the execution boundary from static application code to dynamically supplied content and third-party capabilities, without equivalent controls around identity, input handling, or privilege scoping."

Three risks follow, and they are worth reading in Microsoft's own words because most of the coverage that followed paraphrased them into vagueness:

• "Credentials and accessible data may be exposed or exfiltrated."

• "The agent's persistent state or 'memory' can be modified, causing it to follow attacker-supplied instructions over time."

• "The host environment can be compromised if the agent is induced to retrieve and execute malicious code."

Note what is absent from that list. There is no exploited flaw, no vulnerable function, no patch to ship. Microsoft is not saying OpenClaw has a security bug; it is saying that a program which decides what to do at run time, out of text it fetched, using credentials it was given, cannot be made safe by configuration on a machine that also holds the operator's real work. The recommendation that follows is correspondingly blunt — for most environments, "the appropriate decision may be not to deploy it."

Two supply chains, one execution loop

The mechanism the post describes is the convergence of what it calls the two supply chains of a self-hosted agent: untrusted code, meaning skills and extensions, and untrusted instructions, meaning external text. Most software has one or the other. A package manager pulls untrusted code but does not read the internet and decide what to run next; a chat model reads untrusted text but cannot install anything. OpenClaw does both in a single loop, and the loop runs under the user's own identity.

"Installing a skill is basically installing privileged code," the post says. Skills are "often discovered and installed through ClawHub, the public skills registry for OpenClaw", and in permissive deployments "the runtime may be allowed to execute the installation flow without human approval." The second supply chain is handled by Moltbook, which the post describes as an agent-focused platform and identity layer where agents post, read and authenticate through APIs — and therefore, in its phrasing, "a high-volume stream of attacker-influenceable content that agents ingest on a schedule." The compression is the point: "A single malicious post can therefore reach multiple agents."

The post then splits the trust boundary into three components, which is the most reusable part of the whole document: identity, meaning the tokens the agent uses to do work across SaaS APIs, repositories, mail and cloud control planes; execution, meaning the tools it can run that change state, including files, shell, infrastructure and messages; and persistence, meaning the ways it can keep changes across runs, through tasks, configuration and schedules. An agent that has all three is not an application with a permission prompt. It is a principal.

The poisoned skill, in five stages

Microsoft supplies one worked compromise chain, labelled as a representative scenario rather than a case report, and it is worth walking because its last two steps are the ones that defeat ordinary endpoint defences. The post prefaces it with a claim about the outside world — "Public reporting has documented malicious skills appearing in public registries", and in some cases "registry content has been straightforward malware packaged as a skill, rather than a subtle lookalike" — but names no registry entry, campaign, actor or victim, so the chain stands as a plausibility argument, not a reconstruction.

• Distribution. An attacker publishes a malicious skill to ClawHub, sometimes disguised as a utility and sometimes openly malicious, and promotes it through community channels; other times it is found organically through search and installed because installation is low-friction.

• Installation. A developer or the agent itself starts the install because the skill looks relevant to the task. In a permissive deployment, no human approves it.

• State access. The attacker goes after tokens, cached credentials, configuration data and transcripts, plus the durable instruction channels — task files, scheduled actions, agent configuration — that steer future runs.

• Privilege reuse. With valid identity material, the attacker acts through standard APIs and tooling, and the activity "often resembles legitimate automation unless strong monitoring and logging controls are in place."

• Persistence through configuration. What remains is durable configuration change: "new OAuth consents, scheduled executions, modified agent tasks, or tools that remain permanently approved."

The fifth step carries the post's sharpest sentence, and the one that best explains why this is a policy problem rather than a malware problem: "The objective is less about deploying malware and more about maintaining long-term control over the automation pathway." Security tools that look for a payload will find nothing. What they would have to catch is a consent grant, a cron entry or a tool that was quietly left approved.

The minimum posture Microsoft will accept

Microsoft does not leave the reader with "don't". It supplies a floor for organisations that decide to evaluate the runtime anyway, and the floor is stricter than a sandbox. The environment should be "a dedicated virtual machine or a separate physical device that is not used for daily work", and it should be treated as disposable. Credentials should be created solely for the agent's purpose, non-privileged, and rotated on the assumption that they are already compromised. Only non-sensitive data should be reachable. The agent's saved instructions and state should be reviewed regularly for unexpected persistent rules, newly trusted sources or behaviour that changes between runs. And a rebuild should be an expected control rather than an emergency: reinstall regularly, and rebuild immediately on anomalous behaviour.

One detail in the post is more useful than its length suggests. Backing up .openclaw/workspace/ captures the agent's working state without including credentials; backing up the entire .openclaw/ directory is simpler to restore but also captures tokens and credentials, and the post warns that may be inappropriate if credentials are suspected to be compromised. A team that backs up the whole directory and calls it disaster recovery has archived the thing the attacker wanted.

The guidance is also a product map

The second half of the post maps each recommended control to a Microsoft product: Microsoft Entra ID for least privilege and conditional access on agent identities, Microsoft Defender for Cloud Apps App Governance for OAuth inventory and consent drift, Microsoft Defender for Endpoint for the agent host, Microsoft Defender XDR for correlation, Microsoft Purview for endpoint data loss prevention, Microsoft Defender for Cloud for network egress, and Microsoft Sentinel where longer retention or automation is needed. That is ordinary practice for a vendor security blog and it is also worth naming plainly: the document recommending that a third-party agent runtime be contained is published by a company that sells the containment.

The hunting content is the part that survives that framing, because it is specific. The post supplies KQL queries against Defender XDR tables — DeviceProcessEvents, CloudProcessEvents, DeviceFileEvents, DeviceNetworkEvents and OAuthAppInfo — that look for process command lines and file names containing "openclaw", "moltbot" or "clawdbot", for clawhub install invocations with rare skill slugs, for extension-folder churn on developer endpoints, for new high-privilege OAuth applications, for listening services opened by agent processes, and for agent runtimes spawning cmd.exe, powershell.exe, pwsh.exe, bash, sh, curl or wget. Whatever one thinks of the product mapping, those queries are runnable by any Defender XDR customer on the day of publication, and they assume no prior knowledge of which hosts are running the runtime.

What is established, and what is not

Established, and corroborated: Microsoft published the post on 19 February 2026, and the quotations above are from it. Cybernews reported the warning on 23 February 2026 and TechRadar on 24 February 2026, both restating the two central sentences and the isolation guidance rather than testing them. Repeated searches did not surface coverage in The Register, BleepingComputer, Wired or TechCrunch, so the press wave around this post was small and derivative; no independent party has published a test of Microsoft's architectural claim, and the corroboration available confirms what Microsoft said, not whether it is right.

The relay also introduced an error worth flagging, because it shows how quickly a vendor warning about a third-party tool becomes a vendor warning about its own. Cybernews's report opens by describing OpenClaw as "Microsoft's AI assistant"; it is not. OpenClaw is a self-hosted runtime that Microsoft's Defender researchers examined, and the post itself draws the distinction structurally, contrasting self-hosted runtimes — where "you are responsible for the blast radius" and the host, plugins and local state all sit inside the trust boundary — with managed assistants and agent platforms, where the runtime and updates are centrally managed and controls centre on identity scopes, connector governance and data boundaries.

Not established: that any specific organisation has been compromised in the way the post describes. Microsoft asserts that public reporting has documented malicious skills in public registries, but the post attaches no campaign name, no count, no date and no victim, and this record therefore carries no real harm. Nor is the recommendation binding. No regulator issued it, no standard body adopted it, and nothing in the record shows a customer, auditor or insurer treating it as a requirement. It is a vendor's opinion about how its own customers should treat a tool it does not control — unusually categorical, and unenforceable.

What the post does change is the shape of the question a security team has to answer. Before 19 February 2026, the decision to run OpenClaw on a work laptop could be argued as a configuration and pilot-approval matter. After it, the argument has to be made against a document that says the runtime's own design, not its settings, is what puts the machine at risk — and that offers no version to upgrade to, no patch to apply, and no fix on the roadmap. Its remedy is a deployment pattern: isolate the runtime, constrain what it can reach, monitor it continuously, and be prepared to rebuild without delay.