Short answer: OpenClaw is as safe as the account it runs under, the machine it runs on, and the content it reads. That is true of any agent with shell, browser and messaging access, but OpenClaw's popularity and its skills marketplace put it in the spotlight, and security teams have now published what they found. This post lists the documented risks with their sources, then the concrete steps that reduce them.
The documented risks
1. Credential exposure and data exfiltration
Microsoft's Defender Security Research Team, writing in February 2026, put it first: agent state contains tokens and cached credentials, so "credentials and accessible data may be exposed or exfiltrated." Giskard documented a January 2026 deployment where environment variables and API keys loaded into a "private" DM session were available to anyone who could message the bot, files created in one DM session could be retrieved from another channel, and group chat members could read configuration files containing credentials.
2. Indirect prompt injection
OpenClaw agents read email, web pages, search results and shared feeds. Any of those can carry instructions disguised as content. Microsoft's team notes that when agents poll a shared feed, "a single malicious thread can reach many agents at once" and steer tool use across deployments. Giskard's summary is blunter: anything the agent ingests "can carry adversarial instructions embedded in otherwise benign-looking content," including third-party skills.
3. Skills are privileged code
Skills from ClawHub run inside the agent process with the agent's privileges. In Microsoft's words, "installing a skill is basically installing privileged code," and public reporting has documented malicious skills appearing in registries. A skill is a dependency you did not review, running as you.
4. State and memory manipulation
An injected instruction that survives the session is worse than one that does not. Configuration changes, newly trusted sources, and memory files are the persistence layer. Microsoft's guidance is to watch for "newly trusted sources, or changes in behavior across runs."
How to run it safely
Isolate the machine
Microsoft's baseline: "use a dedicated virtual machine or a separate physical device that is not used for daily work. Treat the environment as disposable." Do not run OpenClaw on the laptop that holds your work SSO session and your password manager. Reinstall regularly, and rebuild immediately if anything looks off.
Give it its own identity
Dedicated, non-privileged credentials with access only to non-sensitive data. If it needs a Google or GitHub account, make one for it. Scope OAuth grants to the minimum and use conditional access where your identity provider offers it.
Scope sessions and sandbox tools
From Giskard's hardening list: use per-peer or per-account-channel-peer session scoping for direct messages instead of the default shared session; enable sandboxing with session-scoped workspaces and no workspace access by default; keep strict tool allowlists and deny filesystem, runtime, gateway and admin tools to untrusted sessions.
Protect the Control UI
Keep it on a private network behind TLS, never pass tokens in query parameters, and leave the gateway bound to loopback. OpenClaw itself refuses to bind a non-loopback address without authentication; do not work around that refusal.
Treat skills like dependencies
Read the code before installing. Prefer skills with a maintainer you can name and a history you can read. Remove the ones you stopped using. Pin versions where the tooling allows it.
Watch what it actually does
Every mitigation above narrows the blast radius. None of them tells you when something got through. For that you need an observer that reads what the agent did, independently of the agent: which sessions ran, which tools they called, which files they touched, where they connected, and whether any of that departs from the agent's own normal.
ClawMetry does that part. It reads OpenClaw's session and channel transcripts from disk and the gateway's live event stream, and its behavioural detectors flag credential access (a session reading key material it never read before), network egress to hosts outside the learned baseline, privilege changes, and a file blast radius wider than usual, each with the spend at risk attached. Observation is read-only; enforcement is opt-in, ships off by default in dry-run mode, and stop and kill act on the process. It does not sandbox the agent and does not replace any step above. It is the alarm, not the wall.
So, is it safe?
Run on a disposable machine, under its own low-privilege identity, with scoped sessions, an allowlist of tools, reviewed skills and something watching the record: yes, with the same caveats as any autonomous agent. Run on your daily laptop with your real accounts and whatever ClawHub suggested: the researchers above have already shown how that ends.
Sources
- Microsoft Security Blog: Running OpenClaw safely: identity, isolation, and runtime risk (February 19, 2026)
- Giskard: OpenClaw security issues include data leakage and prompt injection
- CrowdStrike: What security teams need to know about OpenClaw
Related
The alarm, not the wall
Credential access, egress and privilege-change detection for OpenClaw. Read-only. Open source.
Get ClawMetry