Is OpenClaw safe to use?
OpenClaw can be configured for controlled use, but no installation is risk-free. Self-hosting gives you control over the server and configuration. It also makes you responsible for maintaining them.
Current OpenClaw documentation describes protective defaults, including gateway authentication and restricted access in common deployment paths. Check your installation rather than assuming every container, channel, or configuration behaves identically. Official security guidance
The practical questions are straightforward: who can message the assistant, which tools can it use, what data can it reach, and what happens if it follows the wrong instruction?
Four OpenClaw risks worth understanding
1. Gateway exposure and excessive access
The gateway provides access to your OpenClaw installation. Unnecessary network exposure, weak access controls, or leaked operator credentials can give someone authority they should not have.
Keep access private where practical, authenticate remote connections, and treat gateway credentials as sensitive administrative secrets. Gateway exposure guidance
2. Third-party skills and plugins
Installing a skill or plugin means trusting its instructions, code, and dependencies within the access available to it.
Review the publisher, source, requested permissions, and exact version before enabling it. ClawHub provides security scan information, but a passing scan is not a guarantee that a release is safe for your use case. ClawHub security audits
3. Prompt injection through content the assistant reads
An email, webpage, document, or incoming message can contain instructions designed to redirect the assistant. This risk exists even when you are the only person allowed to message it.
Reduce the potential damage with restricted tools, sandboxing, narrowly scoped accounts, and enforced approval requirements. Instructions telling the assistant to “be careful” are not a substitute for technical controls. OpenClaw prompt-injection guidance
4. Credentials and private data on the host
Configuration, session state, and related files may contain credentials or private information. A compromised account with sufficient permissions can expose them.
Restrict file access, separate the assistant from unrelated sensitive workloads, and protect backups. Supported secret references can reduce plaintext credentials in configuration, but they do not make a compromised host trustworthy. OpenClaw secrets management
What a more secure installation includes
The controls should match the workflows and information involved:
- Limited gateway exposure: private access where possible, with authentication and protected remote transport.
- Controlled senders: pairing, allowlists, and appropriate group policies.
- Restricted tools: enable only the capabilities each workflow needs.
- Isolation: separate accounts and sandboxing where appropriate, with limited filesystem access.
- Approval requirements: enforce review of sensitive actions through the tools and integrations that perform them.
- Reviewed extensions: inspect skills, plugins, dependencies, and permission changes before enabling updates.
- Protected credentials: restrict access, avoid unnecessary copies, and document rotation.
- Maintenance and recovery: review updates, monitor relevant events, limit log retention, and test restoration.
OpenClaw provides a configuration audit:
openclaw security auditUse its findings to identify configuration issues. A clean result is not a penetration test or a guarantee against every attack. Security CLI documentation
My OpenClaw setup service includes the controls agreed for your installation and documents what remains your responsibility.
Where your data goes
Self-hosted does not necessarily mean fully local.
When your setup uses an external model provider, requests send relevant input and context to that provider. Connected messaging services, search tools, and other integrations have their own data flows.
OpenClaw also supports local model configurations. Keeping a workflow local requires checking the entire workflow, including its tools and integrations—not just the model setting. Local model configuration
Before connecting sensitive information, establish:
- What stays on the server.
- What is sent to external services.
- What logs and backups retain.
- Who has administrative access.
- How data and credentials can be removed.
What access I need—and how it ends
Before work begins, I document the server access and integration permissions required for the agreed task.
Where practical, I use a separately identifiable account or SSH key. You retain your own administrative access. We agree how sensitive credentials will be provided, and you complete account approvals or pairing steps that require your participation.
Administrative access may allow me to read files on the server. I limit inspection to what the work requires and agree any necessary access to conversation content before using it for troubleshooting.
At handoff, you receive an access record covering:
- Accounts, keys, and permissions added.
- Credentials you should rotate.
- How to revoke each access method.
- Any access retained for ongoing support.
- Any diagnostic copies made and their deletion arrangements.
If you choose ongoing OpenClaw support, retained access is documented explicitly. When that engagement ends, the agreed support access is removed.
Revoking SSH access yourself
For a standard OpenSSH installation using an authorized_keys file, revocation involves removing the exact public-key entry from the relevant account’s configured authorization file. The location can differ between installations. OpenSSH configuration reference
Your handoff instructions should identify the account, file, and key fingerprint, and provide the exact steps for your server.
Removing a key does not by itself terminate existing sessions or revoke separate access through a VPN, hosting dashboard, or other credentials. Those access paths must be checked too.
OpenClaw security questions
Can OpenClaw read my WhatsApp messages?
Connecting WhatsApp allows OpenClaw to process messages available through that integration, subject to its configuration and channel policies. Confirm which conversations are in scope and where their content is sent before connecting a sensitive account.
Is self-hosting more secure than managed hosting?
Neither is automatically more secure. Compare access controls, isolation, updates, monitoring, incident handling, and data processing. Self-hosting gives you more operational control and more maintenance responsibility.
What if someone gets into my server?
Treat credentials and data reachable through the compromised access as potentially exposed. Contain the incident, preserve useful evidence, and rotate affected credentials from a trusted environment. Recovery may require rebuilding the host rather than changing a single password. OpenClaw incident-response guidance
Are ClawHub skills safe?
Evaluate each release individually. Review its source, permissions, dependencies, and scan findings. Install only what you understand and need; scan results do not replace that decision. Skill security guidance
Can my assistant be tricked into doing something?
Yes. Untrusted content can attempt to redirect its behavior. Restricting permissions and separating content-reading tasks from sensitive actions reduces the consequences of a successful attempt. Prompt-injection guidance
What happens to your access when we stop working together?
The access record defines what must be removed. At the end of the engagement, we revoke the agreed support access, review credentials that need rotation, and leave you with the documentation needed to maintain the installation.