OpenClaw showed up out of nowhere and became one of the fastest-growing open-source projects ever, racking up 100,000 GitHub stars in just weeks. It is genuinely useful and changes how you work with AI. But all that power comes with security trade-offs you need to understand before hitting install.
The creator has been upfront: “Most non-techies should not install this.” He is not being modest. OpenClaw gives an AI agent the ability to run shell commands, read your files, send messages as you, and access your accounts. Handle it carelessly and it is a security nightmare. Configure it properly and it is manageable.
This guide walks through what OpenClaw can access, how its security model actually works, the real risks security researchers have found, and specific steps to lock down your setup.
What OpenClaw Can Access on Your Machine
OpenClaw is not some cloud service you log into. It is software running on your own hardware – Mac Mini, Raspberry Pi, Linux VPS, whatever. Because it runs locally, what it can do depends entirely on what you give it.
Out of the box, OpenClaw has access to:
Filesystem: Read, write, and edit files across your system. The workspace lives at ~/.openclaw/workspace/ but tools can reach other paths depending on your configuration.
Shell execution: Run arbitrary commands through bash or exec. Install software, change system settings, run scripts – whatever.
Network: Make HTTP requests, hit APIs, connect to external services.
Browser control: Drive a Chrome/Chromium instance, navigate sites, take screenshots, upload files, interact with web apps.
Messaging: Send and receive messages via WhatsApp, Telegram, Slack, Discord, Signal, iMessage, and others you configure.
Device nodes: Paired iOS or Android devices let OpenClaw access the camera, record the screen, grab location data, and send notifications.
Memory and context: Full conversation history, indexed memories, and session transcripts stored locally.
This is not a bug. It is the whole point. OpenClaw is built to be an agent that actually does things for you. The question is not whether it has power – it is whether you have constrained that power properly.
Tool Policies and Approval Modes
OpenClaw uses a tool policy system to control what the AI can execute. You need to understand this because the defaults might be broader than you expect.
Default Tool Access
In the main session – direct chats with you, the owner – OpenClaw defaults to full tool access. The agent can run bash commands, read and write files, control the browser, use all configured integrations. That makes sense for a personal assistant you control directly.
For non-main sessions – group chats, DMs from others – the defaults vary. Recent versions added sandboxing options to isolate these.
Three Security Modes
Deny: The tool is completely unavailable. The AI cannot touch it.
Ask: The tool needs explicit approval before running. You get a prompt asking whether to allow the action.
Allow: The tool runs automatically without asking.
Configuring Tool Policies
Set tool policies globally or per-agent in ~/.openclaw/openclaw.json:
{
"agents": {
"defaults": {
"tools": {
"policy": "ask",
"deny": ["exec", "browser"],
"allow": ["read", "web_search"]
}
}
}
}
For group chats and untrusted channels, enable sandbox mode:
{
"agents": {
"defaults": {
"sandbox": {
"mode": "non-main"
}
}
}
}
This runs non-main sessions inside Docker containers with restricted access.
Exec Approvals
The exec tool – shell command execution – needs special attention. Configure exec approvals to require confirmation for dangerous commands:
{
"exec": {
"approvals": {
"enabled": true,
"patterns": [
"rm -rf",
"sudo",
"chmod",
"> /etc/"
]
}
}
}
Patterns support wildcards. Any command matching an approval pattern triggers a confirmation prompt.
Network Exposure Risks: Port 18789
Network exposure is one of the most serious risks with OpenClaw. Security researchers have found tens of thousands of instances exposed to the internet, many completely unprotected.
The Gateway Port
OpenClaw’s Gateway runs on port 18789 by default. This WebSocket-based control plane lets the CLI, web interface, mobile apps, and other clients talk to the system.
If you bind the Gateway to 0.0.0.0 without authentication, anyone who finds your IP can connect and start issuing commands.
What Researchers Actually Found
In early 2026, security firms published some alarming numbers:
- Bitsight spotted over 30,000 exposed OpenClaw instances in a two-week period
- SecurityScorecard found 40,000+ exposed instances, with 63% having vulnerabilities
- Over 12,000 instances were exploitable via remote code execution
- Many leaked API keys, Telegram bot tokens, Slack credentials, and conversation histories
Most exposures were not sophisticated hacks. They were basic misconfigurations: users opened port 18789 to the internet without authentication, or used weak passwords.
Default Bind Settings
By default, OpenClaw binds to 127.0.0.1 – localhost only. This is safe. Problems happen when users switch to 0.0.0.0 or lan without adding proper authentication.
# Safe: localhost only
openclaw gateway --port 18789
# Risky: accessible from anywhere WITHOUT auth
openclaw gateway --bind 0.0.0.0 --port 18789
Authentication Options
OpenClaw supports several Gateway authentication modes:
None: No authentication. Only safe on localhost.
Password: Requires a password for connections. Set via gateway.auth.password or OPENCLAW_GATEWAY_PASSWORD environment variable.
Token: Uses tokens for authentication, usually for API access.
Tailscale: Integrates with Tailscale for identity-based access.
If you must expose the Gateway, always enable password or token authentication:
{
"gateway": {
"bind": "0.0.0.0",
"port": 18789,
"auth": {
"mode": "password",
"password": "your-strong-password-here"
}
}
}
Credential Storage Security
OpenClaw stores various credentials on disk. You should know where they live and how they are protected.
Where Credentials Live
WhatsApp: ~/.openclaw/credentials/whatsapp/<accountId>/creds.json
Telegram bot tokens: Config file or environment variable; can use channels.telegram.tokenFile
Discord bot tokens: Config or environment variable
Slack tokens: Config under channels.slack.*
Pairing allowlists: ~/.openclaw/credentials/<channel>-allowFrom.json
Model auth profiles: ~/.openclaw/agents/<agentId>/agent/auth-profiles.json
Legacy OAuth: ~/.openclaw/credentials/oauth.json
File Permissions
OpenClaw creates files with standard permissions by default. Tighten them:
# Lock down the OpenClaw directory
chmod 700 ~/.openclaw
# Ensure config files are not world-readable
chmod 600 ~/.openclaw/openclaw.json
chmod 600 ~/.openclaw/credentials/*.json
The openclaw security audit --fix command can apply these automatically.
Handling API Keys
OpenClaw needs API keys for LLM providers. These live in auth profiles or environment variables.
Best practices:
– Use environment variables instead of hardcoding in config files
– Rotate keys regularly
– Use separate keys for different agents if possible
– Never commit config files with keys to version control
What Gets Logged
Session transcripts live in ~/.openclaw/agents/<agentId>/sessions/*.jsonl. These contain full conversation history, including sensitive information. Any user or process with filesystem access can read them.
Recent versions redact some sensitive data from logs, but treat the entire ~/.openclaw directory as sensitive.
How to Harden Your OpenClaw Setup
Locking down OpenClaw means layering defenses: network access, authentication, tool restrictions, and monitoring.
Use a Firewall
On a VPS or dedicated server, restrict port 18789:
# UFW (Ubuntu/Debian)
ufw default deny incoming
ufw allow from YOUR_HOME_IP to any port 18789
ufw enable
# iptables
iptables -A INPUT -p tcp --dport 18789 -s YOUR_HOME_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 18789 -j DROP
Run Behind Tailscale
Tailscale gives you a secure mesh network without exposing ports publicly. OpenClaw has built-in Tailscale support:
{
"gateway": {
"tailscale": {
"mode": "serve"
}
}
}
Modes:
– serve: Tailnet-only access (private to your Tailscale network)
– funnel: Public HTTPS via Tailscale Funnel (still requires authentication)
When using Tailscale, keep gateway.bind set to loopback. OpenClaw enforces this.
Use SSH Tunnels
For remote access without exposing the Gateway directly:
# On your local machine, forward remote port 18789 to localhost
ssh -L 18789:localhost:18789 user@your-openclaw-server
# Then access via localhost:18789 on your local machine
This keeps the Gateway bound to localhost on the server while still allowing remote access.
Run the Security Audit
Run the built-in security audit regularly:
# Basic audit
openclaw security audit
# Deep audit with live probing
openclaw security audit --deep
# Auto-fix common issues
openclaw security audit --fix
The audit checks:
– Inbound access policies (DMs, group policies, allowlists)
– Tool blast radius with open rooms
– Network exposure and authentication
– Browser control exposure
– Local disk permissions
– Plugin allowlists
– Configuration drift
Sandbox Untrusted Sessions
If you allow group chat access or DMs from others, enable sandboxing:
{
"agents": {
"defaults": {
"sandbox": {
"mode": "non-main",
"docker": {
"image": "openclaw/sandbox:latest"
}
}
}
}
}
This runs non-owner sessions in isolated Docker containers with limited filesystem access.
Control DM Access
By default, unknown senders on Telegram, WhatsApp, and other channels get a pairing code and their messages are not processed until you approve them.
Configure strict DM policies:
{
"channels": {
"telegram": {
"dmPolicy": "pairing"
},
"discord": {
"dmPolicy": "pairing"
}
}
}
To approve someone:
openclaw pairing approve telegram <code>
Never set dmPolicy to open unless you fully understand what you are doing.
Limit Group Chat Access
For group chats, use allowlists and require mentions:
{
"channels": {
"telegram": {
"groups": {
"groupPolicy": "allowlist",
"requireMention": true
}
}
}
}
This ensures the bot only responds in approved groups and only when explicitly mentioned.
Disable Dangerous Tools for Untrusted Contexts
Consider a restrictive tool policy for non-main sessions:
{
"agents": {
"defaults": {
"tools": {
"policy": "ask",
"deny": ["exec", "write", "edit", "browser", "nodes"],
"allow": ["read", "web_search", "web_fetch"]
}
}
}
}
This prevents untrusted users from executing commands, modifying files, or controlling the browser.
Common Mistakes That Expose Your Instance
Most exposed OpenClaw instances were not hacked. They were simply misconfigured. Here is what goes wrong:
Binding to 0.0.0.0 without authentication: The Gateway defaults to localhost for a reason. Switching to 0.0.0.0 without password auth leaves you wide open.
Weak passwords: A 6-character password is not enough for internet-exposed services. Use long, random passwords or skip password auth and use Tailscale instead.
Opening port 18789 on cloud firewalls: Many users open port 18789 in their cloud provider’s firewall without IP restrictions or Gateway auth.
Running old versions: Security issues get fixed fast. Most exposed vulnerable instances were outdated. Keep OpenClaw updated with openclaw update.
Leaving DM policies open: Setting dmPolicy to open lets anyone message your bot. Combine that with permissive tool policies and you have handed the internet a remote shell.
Storing credentials in git: Never commit openclaw.json or credential files to GitHub. Attackers scan for these within minutes.
Ignoring the security audit: The built-in audit catches most misconfigurations. Run it regularly, especially after changes.
Pairing nodes without restrictions: Paired iOS/Android devices can execute system.run commands on the host. If you do not need this, disable it or set exec approvals to “security” mode.
Privacy: What Data Goes to LLM Providers
OpenClaw sends your messages and context to LLM providers to generate responses. Here is what actually gets sent.
What Gets Sent
Your prompts: Everything you type goes to the configured LLM.
Tool results: If the AI uses a tool, the results go to the LLM to inform its response.
Conversation history: Previous messages in the session provide context.
System prompts: OpenClaw injects prompts defining the agent’s behavior, available tools, and constraints.
Memory context: If memory is enabled, relevant past conversations may be included.
What Stays Local
Credentials: API keys and tokens never leave your machine.
File contents: Unless explicitly read by a tool, your files stay local.
Browser session data: Cookies and local storage in the controlled browser stay local unless the AI reads them.
Minimizing Data Exposure
Use local models: OpenClaw supports Ollama and other local LLMs. These keep all processing on your hardware.
Review the system prompt: Check the injected files (AGENTS.md, SOUL.md, etc.) to understand what context goes to the LLM.
Disable memory if not needed: Memory features send context to the LLM. Disable if you prefer session-only conversations.
Be careful with personal data: Do not paste passwords, financial details, or sensitive information into chats that go to cloud LLMs.
How OpenClaw Compares to Other AI Agents
vs. ChatGPT / Claude Web Interface
Web interfaces run in the cloud with no local system access. They cannot read your files, run commands, or send messages. Much safer, but also far less capable.
OpenClaw trades safety for capability. It can do more because it has more access.
vs. Claude Desktop App
The Claude Desktop app runs locally and can access files you explicitly provide. It has some local tool capabilities but is more restricted than OpenClaw.
OpenClaw goes further with shell execution, persistent integrations, and multi-channel access.
vs. Custom GPTs / Assistants API
OpenAI’s Assistants run in the cloud with controlled tool access. They cannot execute arbitrary code on your machine.
OpenClaw runs on your hardware with full system access, making it more powerful but requiring more careful security configuration.
vs. Other Local AI Agents
Projects like LocalAI and Ollama focus on running models locally. They typically lack the broad tool integration and multi-channel messaging that OpenClaw offers.
OpenClaw is unique in combining local execution with deep integration into messaging platforms and system tools.
The Trade-off
OpenClaw sits at the extreme end of the capability/security spectrum. It can do more than almost any other AI assistant, but it also demands more security awareness than almost any other AI assistant.
If you want something that “just works” without security configuration, OpenClaw is not for you. If you are willing to configure it carefully, the capabilities are unmatched.
Final Recommendations
Is OpenClaw safe? It can be, if you treat it like the powerful system tool it is.
Do:
– Run the security audit regularly
– Keep OpenClaw updated
– Use Tailscale or SSH tunnels instead of exposing port 18789
– Enable sandboxing for non-main sessions
– Restrict DM and group chat access with pairing and allowlists
– Set strong passwords if you must expose the Gateway
– Review and tighten tool policies
– Monitor your logs for unusual activity
Do not:
– Expose port 18789 to the internet without authentication
– Run old versions with known vulnerabilities
– Set DM policies to open without understanding the risks
– Give OpenClaw access to systems you cannot afford to compromise
– Ignore the security warnings in the documentation
OpenClaw is a tool for tinkerers who understand the risks. If that is you, it is incredibly powerful. If that is not you, wait for the ecosystem to mature or use more restricted alternatives.
The security model is not broken. It is just your responsibility.