OpenClaw Hardening: 5 Security Steps for LLM Deployments

Securing OpenClaw: Five Critical Hardening Steps for LLM Deployments

Despite mounting security concerns around OpenClaw, a recent Medium article by C. Dalrymple outlines a practical five-step approach to hardening OpenClaw installations for developers who want to continue experimenting with local LLM deployments. The guidance addresses critical attack vectors including network exposure, service discovery, file permissions, skill vulnerabilities, and container isolation.

Network Isolation and Service Discovery

The first two steps focus on limiting network exposure. By default, OpenClaw scans all network interfaces, potentially exposing the LLM across LANs and the internet. Dalrymple recommends verifying "gateway": "127.0.0.1" exists in the openclaw.json configuration file to restrict binding to localhost only. Additionally, disabling Multicast DNS (MDNS) prevents OpenClaw from discovering other devices on the network. This is achieved by adding "discovery": {"mdns": false} to the configuration, blocking unintended service enumeration that could expose the LLM to lateral movement attacks.

These measures are essential for network-security in AI deployments where LLMs often handle sensitive data and maintain connections to external services.

File System Permissions and Configuration Security

Step three addresses file system security through strict permission settings. On Linux systems, Dalrymple recommends setting the OpenClaw directory to mode 700 (owner-only read/write/execute), the configuration file to 600 (owner-only read/write), and recursively applying 600 permissions to all credentials. The built-in security audit command openclaw security audit --fix helps identify permission issues and excessive attack surface.

This step is critical because OpenClaw files contain API keys, OAuth tokens, LLM endpoints, chat histories, and third-party service credentials. A single compromised file could provide attackers with vectors into the LLM, host machine, or connected cloud services. Developers working with Local LLM Tool Calling for Clawdbot infrastructure must treat these configuration files as highly sensitive assets.

Skill and MCP Server Restrictions

The fourth step tackles one of OpenClaw's most significant vulnerability surfaces: Skills and Model Context Protocol (MCP) servers. While these components provide filesystem access, shell execution, and browser control capabilities, they also create dangerous attack vectors. Filesystem skills risk prompt injection and data exfiltration, shell execution enables destructive commands, and browser control can lead to session hijacking.

Dalrymple's approach disables high-risk skills by explicitly setting "filesystem": false, "shell": false, and "browser": false in the MCP servers configuration. The configuration also pins software versions to prevent automatic updates that might introduce vulnerabilities and sets "enableAllProjectMcpServers": false to prevent auto-enabling of new skills. The recommended security posture treats all skills as potentially malicious and requires explicit whitelisting.

This aligns with broader ai-security principles around least privilege and defense in depth for agentic AI systems.

Container Isolation for Experimental Deployments

The final optional step recommends running OpenClaw in a Docker container to provide additional isolation. Container deployment limits the blast radius of successful attacks by preventing compromised agents from accessing host files, network resources, or kernel-level functionality. This approach is particularly valuable when experimenting with untrusted skills or testing prompt injection defenses.

Container isolation represents a pragmatic middle ground for developers who need to test OpenClaw capabilities without exposing production systems, similar to approaches used in OpenClaw Worker: Railway Docker Deployment security for AI workloads.

Implications for the AI Ecosystem

These hardening steps highlight a broader challenge in the open-source AI ecosystem: balancing developer accessibility with security best practices. LLM frameworks like OpenClaw prioritize ease of use and rapid experimentation, often at the expense of secure defaults. As AI agents gain more powerful capabilities and access to sensitive systems, the security community must develop standardized hardening guides and secure-by-default architectures.

The article demonstrates that even researchers concerned about security risks aren't ready to abandon local LLM experimentation entirely—they're seeking pragmatic ways to reduce risk to acceptable levels. This suggests a market need for security-focused llm-security tooling and frameworks that make hardening accessible to developers without deep security expertise.

Source: "Five Steps to OpenClaw Hardening" by C. Dalrymple, published on Medium