When Microsoft's Defender Security Research Team publishes a blog post telling you how to run specific software safely, you should probably pay attention. Doubly so when the blog post is 12 minutes long and includes hunting queries for detecting compromised instances across your fleet.
This week, Microsoft published "Running OpenClaw safely: identity, isolation, and runtime risk." It's the most thorough security analysis of OpenClaw from a major vendor yet, and the conclusions are stark.
Their recommendation, stated plainly: "It is not appropriate to run on a standard personal or enterprise workstation."
Let that sink in. Microsoft — a company not known for alarmist security guidance — is saying you should not run OpenClaw on your regular computer.
The Three Pillars
Microsoft's analysis organizes OpenClaw's risk into three components that form the agent's "security boundary":
Identity — the tokens and credentials the agent uses to do work. SaaS APIs, code repositories, email, cloud control planes. When you connect OpenClaw to your services, you're giving it your identity.
Execution — the tools the agent can run that change state. File operations, shell commands, infrastructure changes, messages. OpenClaw doesn't just read — it acts.
Persistence — the ways the agent keeps changes across runs. Tasks, configuration, schedules. A compromised agent can install persistent changes that survive restarts and affect future behavior.
The key insight is that these three components form a loop. The agent uses its identity to execute actions, those actions persist changes, and those changes influence future execution. An attacker who compromises any part of this loop gains leverage over the entire system.
The Two Supply Chains
Microsoft identifies something that hasn't gotten enough attention: OpenClaw has two supply chains, and both are vulnerable.
The code supply chain: skills, extensions, plugins. These are essentially programs that run with the agent's permissions. Installing a skill from ClawHub is functionally identical to running untrusted code on your machine. Microsoft's analysis documents how malicious skills can access agent state (tokens, cached credentials, configuration) and modify durable instructions that persist across runs.
The instruction supply chain: external text that the agent ingests. Slack messages, emails, web pages, social feeds. If the agent reads content from an external source, that content can contain hidden instructions — prompt injection. Microsoft notes that in multi-agent settings, "a single malicious thread can reach many agents at once."
These two supply chains converge inside the agent's execution loop. Untrusted code can read untrusted instructions, and untrusted instructions can trigger untrusted code. The attack surface isn't additive — it's multiplicative.
Microsoft's Minimum Safe Posture
Here's what Microsoft says you must do if you insist on running OpenClaw:
-
Run only in isolation. Dedicated VM or separate physical device. Not your daily-use computer. Treat the environment as disposable.
-
Use dedicated credentials and non-sensitive data. Create accounts and tokens that exist solely for the agent. Assume compromise is possible. Plan for regular rotation.
-
Monitor for state manipulation. Regularly review the agent's saved instructions for unexpected persistent rules, newly trusted sources, or behavior changes across runs.
-
Back up state for rapid rebuild. Snapshot
.openclaw/workspace/regularly. Be ready to wipe and rebuild. -
Treat rebuild as an expected control. Don't try to fix a potentially compromised instance. Destroy it and rebuild. Persistence may appear as subtle configuration changes rather than obvious malware.
These aren't suggestions. Read the language: "should be treated as a baseline." This is what Microsoft considers the floor for safe operation.
What Default OpenClaw Does
Now compare Microsoft's requirements to what happens when someone follows a standard OpenClaw tutorial:
| Microsoft Recommends | Default OpenClaw |
|---|---|
| Dedicated VM, not your workstation | Runs directly on your laptop |
| Dedicated credentials | Uses your personal API keys and tokens |
| Non-sensitive data only | Full access to your filesystem |
| Regular state monitoring | No built-in state auditing |
| Disposable environment with rebuild plan | Persistent installation on your machine |
The gap between Microsoft's minimum recommendations and what most people actually do is enormous. It's not that users are ignoring security guidance — it's that the security guidance requires infrastructure expertise that most OpenClaw users don't have.
Setting up a dedicated VM, configuring it properly, creating dedicated credentials, implementing monitoring, and maintaining rebuild procedures — that's a multi-hour project for someone who knows what they're doing. For someone who doesn't, it's an insurmountable barrier that results in running OpenClaw exactly the way Microsoft says you shouldn't.
What This Validates
We've been writing about OpenClaw security since we launched Clawdy in December. The themes in Microsoft's analysis aren't new to us:
- We said don't run OpenClaw on your personal machine. Microsoft says the same thing with institutional authority.
- We said the blast radius of a compromised local agent is your entire digital life. Microsoft's "end-to-end attack scenario" describes exactly that.
- We said isolated infrastructure with dedicated credentials is the minimum viable security posture. Microsoft calls it "the baseline."
The difference is that when we say it, we're a startup with an obvious incentive. When Microsoft's Defender Security Research Team says it — with KQL hunting queries and MITRE ATT&CK mappings — the conversation changes.
How Clawdy Addresses Each Pillar
Let me be specific about how Clawdy maps to Microsoft's three-pillar framework:
Identity. Clawdy's AI proxy handles model API calls separately from the OpenClaw instance. Your OpenRouter, Anthropic, or OpenAI credentials never touch the agent's server. If the instance is compromised, the attacker gets access to a cloud server, not your API keys.
Execution. Each Clawdy deployment runs on an isolated cloud instance with its own filesystem, network, and process space. The agent can execute whatever it needs to on that instance — but "that instance" is a disposable cloud server, not your laptop with your SSH keys, browser sessions, and password manager.
Persistence. Because the environment is isolated and managed, rebuilding is trivial. If you suspect compromise, destroy the instance and deploy a fresh one. Your data lives separately from the agent's execution environment.
Microsoft's blog post is essentially describing the architecture we built, written by people who arrived at the same conclusions independently. That's validating, but it's also concerning — because it means the security problems are obvious to anyone who looks, and most OpenClaw users aren't looking.
The Bottom Line
Microsoft's guidance isn't controversial. It's basic security hygiene applied to a new category of software. The problem is that basic security hygiene requires infrastructure that most people don't have.
If you're running OpenClaw on your laptop right now, Microsoft is telling you to stop. If you need to keep running it, they're telling you to move it to an isolated environment with dedicated credentials and rebuild procedures.
You can do that yourself — set up a VM, configure the network, create dedicated accounts, build monitoring, maintain backups. Or you can let someone else handle it.
Every recommendation Microsoft makes, Clawdy ships by default. Isolated infrastructure, dedicated credentials, API key proxying, managed rebuilds. Deploy in under 60 seconds at clawdy.app.