OpenClaw is powerful precisely because it can act. The danger begins when a model, an untrusted plugin, a session, and a host computer share more authority than the task requires.
Why it matters: if an assistant can run unrestricted host commands, a mistaken instruction may become a system change. Response: move sensitive actions behind independently enforced policies and operator review. OpenClaw default model ↗
Why it matters: researchers documented malicious marketplace skills that attempted credential theft or prompted dangerous installs. Response: scrutinize skills, restrict execution and network reach, and independently approve sensitive operations. Unit 42 research ↗
Why it matters: a user's reported inbox-deletion incident illustrates why intent in a prompt is not the same as an enforceable approval for destructive actions. The reported incident was not independently verified by TechCrunch. Incident chronology ↗
Why it matters: networks, sandboxes, resource budgets, approvals and audit logs may live in different control planes. Clawsolator's design goal is a readable, reproducible path from request to outcome. See the XMAN workflow ↗
“Be careful” cannot reliably constrain a model that already has filesystem, mail, shell or credential access. The operating system, capability broker and operator policy must enforce the restriction independently.
Its documentation states that sandboxing and exec approvals are off by default for its trusted single-operator use case, that one gateway is one trust domain, and that native plugins run in-process. The project does provide configurable defenses, security auditing and active fixes. The issue is how easily an operator can end up with the wrong trust boundary.
That difference is critical: an insecure deployment is not proof every OpenClaw installation is insecure. But it means secure configuration, verification and continued maintenance are operational tasks, not optional extras.
SOURCE · OpenClaw: Why OpenClaw · SOURCE · OpenClaw trust model
Every item below maps to a concrete engineering control. Some are implemented in XMAN today; other capabilities remain planned or require independent test evidence.
Public reachability, tokens, browser pairing and channel scope can be misunderstood. An exposed login page is not itself proof of compromise.
Unsandboxed execution can reach files, SSH credentials and another agent’s state that the same OS account can access.
Long context, compaction and hostile source material can change behavior even when earlier instructions were clear.
Third-party skills may include scripts, exfiltration logic or risky dependency installers. A popular plugin is not a security review.
Multiple agent IDs do not necessarily imply mutually isolated OS identities or trust domains.
A button, timeout or model reply can report success even after an external action failed—or happened twice.
Agents should request a narrow capability from a manager that does not inherit the model’s instructions as authority.
Automatic resource requests can pass within saved operator ceilings. Privileged root operations are a separate high-risk path: the root-owned executor and signed one-use approval mechanism are future design work, not a shipped capability.
See the resource-daemon demonstration ↗An inbox operation reported to ignore stop commands. A GitHub incident describing cross-agent deletion. Malware-bearing third-party skills. Thousands of exposed gateways. These are different kinds of evidence, and we keep them separate.
Open the incident library ↗Containment must exist before the agent makes a mistake.THE SECURITY DESIGN PRINCIPLE
Read original incident sources and see exactly which controls have been demonstrated.
These are deployment and trust-boundary risks, not a claim that every OpenClaw installation is vulnerable. OpenClaw has its own audits, sandbox controls and hardening guidance. Clawsolator focuses on making defensive deployment and ongoing approvals easier to organize and verify.
When the control plane is reachable from the wrong network, an attacker may reach credentials or remote-execution surfaces.
A shared gateway is documented as one trust boundary; a separate agent name does not create a separate tenant.
An unsandboxed command tool running under the gateway user can modify files available to that account.
A convenient plugin can become a path to secret theft, malicious commands, or unintended network traffic.
A chat instruction such as “ask me first” may not survive context loss, misinterpretation, or prompt injection.
Personal, business, legal and health workflows can leak across a system if they inherit shared credentials or outbound access.
Read OpenClaw’s own security documentation ↗ See the XMAN control path →
OpenClaw’s documented default trust model assumes a trusted personal operator. That can be appropriate for a personal assistant but may be insufficient for unrelated users, confidential organizational domains or untrusted agents without further isolation, credential separation and approval controls. Review the exact version and configuration rather than assuming every installation is equally exposed.
Common risk categories include overly broad host tool permissions, exposed gateways, unreviewed third-party skills, shared secrets across trust domains and excessive network or filesystem access. These risks are not all unique to OpenClaw and depend on configuration and updates.
No. Clawsolator addresses deployment and governance boundaries around agents; upstream security patches, safe plug-in choices and ongoing updates remain necessary. Containerization and daemon approvals reduce some risks but do not guarantee prevention of all data disclosure or misuse.