OpenClaw Security Best Practices: How to Deploy AI Agents Without Exposing Your Organization

TL;DR

Quick Answer: OpenClaw is a powerful open-source AI agent, but its default configuration prioritizes convenience over security. With over 135,000 exposed instances, a critical RCE vulnerability (CVE-2026-25253), and hundreds of malicious skills in its marketplace, teams need to actively harden their deployments. This guide walks through seven concrete best practices, each with specific configuration examples, to help you run OpenClaw securely and stay compliant.

OpenClaw has become the most popular open-source AI agent platform in a matter of months, crossing 247,000 GitHub stars since its November 2025 launch. Teams use it to automate workflows across email, calendars, messaging platforms, and cloud services, all from a self-hosted, local-first architecture.

But that rapid adoption has come with serious security incidents. In February 2026, researchers documented the first AI agent infostealer attack, where Vidar malware exfiltrated gateway tokens, cryptographic keys, and behavioral guidelines from OpenClaw installations. SecurityScorecard found over 135,000 exposed instances across 82 countries. And more than 820 malicious skills were discovered on ClawHub, OpenClaw's official marketplace.

The good news: OpenClaw provides the configuration knobs to lock things down. Most organizations just haven't turned them yet.

Here are seven security best practices every team should implement before, or immediately after, deploying OpenClaw.

1. Lock Down Network Bindings

The problem: OpenClaw's default configuration binds the gateway to 0.0.0.0:18789, which means it listens on all network interfaces, including the public internet. This is the single biggest reason SecurityScorecard found 135,000+ exposed instances, with 12,812 directly exploitable via remote code execution.

The fix: Bind the gateway to localhost only and enable authentication.

1{
2  gateway: {
3    mode: "local",
4    bind: "loopback",
5    auth: { mode: "token", token: "replace-with-a-long-random-token" }
6  }
7}

Key recommendations:

• Set gateway.bind to "loopback" so the gateway only accepts connections from your local machine
• Enable gateway.auth with either "token" or "password" mode, never leave it unauthenticated
• If you need remote access, use a VPN or Tailscale rather than exposing the port directly
• Disable mDNS broadcasting to prevent network discovery by setting discovery.mdns.mode to "off" or using the environment variable OPENCLAW_DISABLE_BONJOUR=1

If you must use a reverse proxy, configure trustedProxies explicitly and ensure your proxy overwrites (not appends) the X-Forwarded-For header to prevent IP spoofing.

2. Manage Secrets Properly

The problem: OpenClaw stores sensitive data in plaintext config files on disk by default. The openclaw.json file contains your gateway token. The device.json file holds cryptographic keys. Channel credentials sit in ~/.openclaw/credentials/. Any infostealer, compromised dependency, or file-reading vulnerability can grab these in seconds.

The fix: Treat agent configuration files like SSH keys or API tokens.

Set proper filesystem permissions:

1chmod 700 ~/.openclaw/
2chmod 600 ~/.openclaw/openclaw.json
3chmod 700 ~/.openclaw/credentials/
4chmod 700 ~/.openclaw/agents/*/

Use environment variables for sensitive values:

1export OPENCLAW_GATEWAY_PASSWORD="your-strong-password"
2export OPENCLAW_GATEWAY_TOKEN="your-long-random-token"

Key recommendations:

• Never commit openclaw.json, device.json, or soul.md to version control. Add them to .gitignore
• Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, or 1Password CLI) to inject credentials at runtime rather than storing them on disk
• Use scoped, read-only tokens wherever possible. If the agent only needs to read from an API, do not give it write access
• Prefer short-lived credentials over long-lived ones, and rotate them on a regular schedule
• If your agent has a memory feature, verify it never persists secrets in conversation history or session transcripts

For a deeper dive on this topic, see our guide on secrets management for startups.

3. Enforce Least Privilege for Tool Access

The problem: OpenClaw can execute shell commands, read and write files, control a browser, schedule cron jobs, spawn sub-agents, and more. Out of the box, many of these capabilities are enabled, giving the agent a broad attack surface if compromised.

The fix: Default to deny, then explicitly allow only the tools your use case requires.

1{
2  tools: {
3    profile: "messaging",
4    deny: [
5      "group:automation",
6      "group:runtime",
7      "group:fs",
8      "sessions_spawn",
9      "sessions_send"
10    ],
11    fs: { workspaceOnly: true },
12    exec: { security: "deny", ask: "always" },
13    elevated: { enabled: false }
14  }
15}

Key recommendations:

• Start with the "messaging" tool profile, which provides a restricted baseline, then add specific tools as needed
• Deny group:automation (cron/scheduling), group:runtime (code execution), and group:fs (filesystem operations) unless your workflow explicitly requires them
• Set exec.security to "deny" and exec.ask to "always" so the agent cannot run shell commands without explicit approval
• Keep elevated mode disabled. This prevents the agent from performing host-level execution when its sandbox is unavailable
• Restrict filesystem access to the workspace directory only with fs.workspaceOnly: true
• Block sessions_spawn and sessions_send to prevent the agent from delegating tasks to sub-agents without your knowledge

For multi-agent setups, create separate agent profiles with different permission levels. A public-facing agent should have far fewer permissions than your personal automation agent.

4. Vet Third-Party Skills Before Installing

The problem: ClawHub, OpenClaw's official skill marketplace, suffered a massive supply chain poisoning campaign. Security audits found 820+ malicious skills out of 10,700 total, and 36% of all listed skills contained detectable prompt injection. Malicious skills delivered infostealers, exfiltrated credentials to external webhooks, and hid reverse shell backdoors inside functional code.

The fix: Treat skill installation like adding a dependency to your production codebase.

1{
2  plugins: {
3    allow: ["@scope/trusted-plugin@1.2.3"]
4  }
5}

Key recommendations:

• Audit every skill's source code before installation, especially looking for suspicious network calls, filesystem access, or credential reads
• Use explicit allowlists in your configuration. Only install skills from verified publishers with established track records
• Pin exact versions to prevent supply-chain attacks via malicious updates
• Review unpacked skill code in ~/.openclaw/extensions/ before enabling
• Restart the gateway after any plugin change to ensure clean state
• Watch for typosquatted skill names, one of the primary attack vectors in the ClawHavoc campaign

This mirrors the same discipline you should apply to npm dependencies and any other third-party code.

5. Enable Logging and Monitoring

The problem: Without an audit trail, you have no visibility into what the agent is doing, what commands it executes, what data it accesses, or whether an attacker has taken control. Session transcripts and logs are your only forensic evidence during an incident.

The fix: Enable log redaction, retain transcripts, and integrate with your existing monitoring stack.

1{
2  logging: {
3    redactSensitive: "tools",
4    redactPatterns: [
5      "sk-[a-zA-Z0-9]+",
6      "ghp_[a-zA-Z0-9]+",
7      "internal\\.yourcompany\\.com"
8    ]
9  }
10}

Key recommendations:

• Keep tool redaction enabled (the default) to prevent secrets from appearing in logs
• Add custom redaction patterns for your organization's tokens, internal hostnames, and API keys
• Regularly prune old session transcripts stored in ~/.openclaw/agents/<agentId>/sessions/*.jsonl to limit exposure if the filesystem is compromised
• Forward agent logs to your SIEM or centralized logging platform for correlation with other security events
• When sharing diagnostics or asking for support, always use openclaw status --all, which produces redacted output
• Monitor for unusual patterns: unexpected outbound network connections, large file reads, or commands executed outside normal hours

6. Run the Built-In Security Audit Regularly

The problem: Configuration drift is real. Settings change, new skills get installed, permissions get loosened for "quick tests" and never tightened back. Without regular checks, your hardened configuration can silently degrade.

The fix: Use OpenClaw's built-in security audit tool as part of your routine.

1# Standard security check
2openclaw security audit
3
4# Deep probe that tests live gateway configuration
5openclaw security audit --deep
6
7# Auto-fix common issues like file permissions
8openclaw security audit --fix
9
10# Machine-readable output for automation
11openclaw security audit --json

What the audit checks:

• Inbound access policies (DM and group allowlists)
• Tool blast radius (elevated tools combined with open rooms)
• Network exposure (bind address, authentication, Tailscale configuration)
• Browser control exposure (remote nodes, relay ports)
• Filesystem permissions and symlink attacks
• Plugin safety and version pinning
• Policy drift (sandbox configuration vs. runtime mode mismatch)

Key recommendations:

• Run openclaw security audit --deep after every configuration change
• Include the audit in your CI/CD pipeline or scheduled maintenance tasks
• Use the --json output to feed results into your compliance monitoring tools
• Review audit warnings for any dangerously* flags in your configuration, these are explicit security overrides that should be justified and documented

7. Align with Compliance Frameworks

The problem: AI agents are privileged service accounts that access email, APIs, cloud services, and internal resources. Most organizations have not incorporated them into their access control policies, asset inventories, or risk assessments. Auditors are starting to ask about them.

The fix: Treat OpenClaw deployments as in-scope assets for your compliance program.

For SOC 2:

• Document all AI agent deployments as part of your system description (CC6.1)
• Apply access controls to agent credentials and API tokens
• Maintain audit logs of agent actions and data access patterns
• Include agent compromise in your incident response procedures

For ISO 27001:

• Add AI agents to your asset inventory and classify them by sensitivity (Annex A.5.9)
• Apply access control policies to agent configurations and credentials
• Include agents in your change management process, configuration changes should go through approval
• Perform risk assessments specific to AI agent deployments (Risk Assessment Guide)

Key recommendations:

• Maintain an inventory of every OpenClaw instance running in your environment, including version, configuration, and installed skills
• Assign ownership for each deployment, someone should be accountable for its security posture
• Define clear escalation paths for suspected agent credential theft
• Map the blast radius for each agent: which systems and data can it access?
• Include AI agent compromise scenarios in your next tabletop exercise

The Hardened Baseline: A Starting Point

If you are setting up OpenClaw for the first time, or want to reset an existing deployment to a secure default, here is a complete hardened configuration:

1{
2  gateway: {
3    mode: "local",
4    bind: "loopback",
5    auth: { mode: "token", token: "replace-with-long-random-token" }
6  },
7  session: { dmScope: "per-channel-peer" },
8  tools: {
9    profile: "messaging",
10    deny: [
11      "group:automation",
12      "group:runtime",
13      "group:fs",
14      "sessions_spawn",
15      "sessions_send"
16    ],
17    fs: { workspaceOnly: true },
18    exec: { security: "deny", ask: "always" },
19    elevated: { enabled: false }
20  },
21  channels: {
22    whatsapp: {
23      dmPolicy: "pairing",
24      groups: { "*": { requireMention: true } }
25    }
26  },
27  browser: {
28    ssrfPolicy: {
29      dangerouslyAllowPrivateNetwork: false
30    }
31  },
32  logging: {
33    redactSensitive: "tools"
34  },
35  discovery: {
36    mdns: { mode: "off" }
37  }
38}

Start here, then selectively enable features as your use case requires. Every permission you add should be deliberate, documented, and reviewed.

Conclusion

OpenClaw is a genuinely useful tool, but its default configuration was designed for quick setup, not production security. The incidents of early 2026 proved that threat actors are already targeting AI agents as high-value targets. Gateway tokens, API keys, behavioral guidelines, and session data are all worth stealing.

The best practices in this guide are not theoretical. They map directly to the attack vectors that have already been exploited in the wild: exposed network bindings, plaintext credential storage, malicious marketplace skills, and unchecked agent permissions.

Securing OpenClaw is not fundamentally different from securing any other privileged service in your infrastructure. It just requires recognizing that your AI agent deserves the same rigor you apply to your servers, databases, and CI/CD pipelines.

Need help integrating AI agent security into your compliance program? Bastion helps SaaS companies build security programs that account for emerging threats, including AI agent deployments. Get started today.

Sources

• OpenClaw Security Documentation
• SecurityScorecard: How Exposed OpenClaw Deployments Turn Agentic AI Into an Attack Surface
• Hudson Rock: Infostealer Infection Targeting OpenClaw Configurations
• DataCamp: OpenClaw Security Best Practices
• Auth0: Securing OpenClaw Developer Guide
• NVD: CVE-2026-25253
• CrowdStrike: What Security Teams Need to Know About OpenClaw