RedShield guidance for Moltbot / OpenClaw users

Overview

What Is OpenClaw?

OpenClaw (previously named “Moltbot”, and prior to that, “Clawdbot”) is an open-source, self-hosted AI personal assistant that has gained rapid popularity in developer and technology circles in early 2026. Unlike cloud-based AI chatbots, OpenClaw runs locally on the user’s own hardware and integrates directly with messaging platforms (WhatsApp, iMessage, Telegram), email clients, calendars, file systems, and other applications. Its appeal lies in its ability to operate continuously in the background, maintain persistent memory across sessions, and take autonomous actions on the user’s behalf - responding to emails, managing schedules, executing scripts, and automating routine tasks with minimal user intervention.

Why There Are Security Concerns

OpenClaw’s design prioritises ease of deployment and capability over secure-by-default configuration. Security researchers have identified several categories of risk:

Exposed control interfaces. Researchers reported over 4,500 Moltbot instances reachable from the public internet due to misconfigured deployments (for example, container port publishing, cloud security groups, or reverse proxies). While Moltbot’s Control UI includes token authentication and device-pairing controls by default, those protections are sometimes weakened or disabled (for example via dangerouslyDisableDeviceAuth / allowInsecureAuth) or effectively bypassed by reverse-proxy trust misconfiguration. In these cases, exposed instances may leak API keys, OAuth tokens, messaging credentials, and conversation history; and if high-privilege tools are enabled, attackers may be able to act as the user or execute system commands.

No sandboxing by default. OpenClaw runs with the same privileges as the user account, meaning it has full access to files, credentials, and connected services. A single point of compromise can expose an entire digital footprint.

Supply chain risks. OpenClaw supports third-party “skills” (plugins) that run with the same authority as the core agent. Researchers demonstrated that malicious skills could be uploaded to the official registry, have their popularity artificially inflated, and be downloaded by unsuspecting users within hours.

Prompt injection vulnerabilities. Because OpenClaw processes external content (emails, web pages, messages), attackers can embed hidden instructions in that content to manipulate the agent into taking unintended actions, such as forwarding sensitive data to an external server.

Persistent memory amplifies impact. Unlike a typical application breach that exposes current session data, a compromised OpenClaw instance can expose months of stored conversations, behavioural patterns, and historical credentials.

Enterprise exposure. Security firm Token Security reported that 22% of its enterprise customers have employees actively using OpenClaw, likely without IT approval or oversight.

Purpose of This Document

This guidance is intended for individuals and organisations who are using or considering OpenClaw. It provides practical recommendations to reduce risk across installation, network configuration, isolation, credential management, plugin governance, prompt injection mitigation, and monitoring. For enterprises, it outlines two approaches: blocking OpenClaw as unapproved software, or permitting it under controlled conditions with appropriate safeguards.

OpenClaw behaves like a high-privilege automation layer: it can hold secrets, act on your behalf, and expose control surfaces if deployed carelessly. Treat it like privileged infrastructure, not a normal desktop application.

Here are some appropriate risk reduction steps:

1. Installation and Updates: Reduce “Fake OpenClaw” Risk First

Before you harden the runtime, make sure what you are running is genuine.

Only install OpenClaw from the official upstream source. Avoid unofficial repacks, “one-click” installers, and lookalike packages. Do not install editor extensions or add-ons unless the upstream project explicitly publishes and links to them. Pin versions and update deliberately.

2. Network Access: “Localhost Only” Is Necessary, But Not Sufficient

Never expose the control dashboard (port 18789) to the public internet.

Bind the service to 127.0.0.1 and also enforce this at the firewall or cloud security group level. If remote access is required, use a VPN or SSH tunnel with tight IP restrictions.

Avoid placing the dashboard behind a reverse proxy unless you fully understand and have tested the proxy configuration. Reverse proxies and container port publishing are common ways “localhost only” becomes internet-reachable.

3. Run in Real Isolation, Including Outbound Control

Running in a VM helps only if the VM is constrained. Use a dedicated VM or separate hardware, and do not run OpenClaw with admin or root privileges unless you have a specific, reviewed reason. Keep it off your primary workstation and away from shared drives and internal admin consoles.

Segment it from corporate networks and apply outbound egress controls - allowlist only the destinations it needs, such as specific AI endpoints and specific SaaS APIs. Without egress controls, a compromise can still lead to data theft and lateral movement.

4. Credentials: Assume Anything It Touches May Be Exposed

Use dedicated service accounts and API keys with least privilege and short lifetimes where possible. Do not use your primary credentials.

Avoid connecting OpenClaw to high-value systems such as password managers, identity administration, cloud root accounts, or anything with broad access.

OpenClaw maintains persistent memory across sessions, meaning a breach does not just expose current credentials - it can expose months of conversation history, behavioural patterns, and historical secrets.

If you have run OpenClaw with default settings or any form of external exposure, assume credentials and tokens may be compromised and rotate or revoke them immediately.

5. Skills and Plugins: Treat as Untrusted Code

Third-party skills are a supply chain risk. If you allow third-party skills, require source review, pin exact versions, and run them in the same restricted environment (no broad network access, no broad file access). Do not assume popularity means safety - researchers have demonstrated that download counts can be artificially inflated.

6. Prompt Injection: External Inputs Can Manipulate the Agent

Even if your network configuration is secure, OpenClaw can be manipulated through the content it processes. When the agent reads an email, summarises a webpage, or processes a message, hidden instructions in that content can cause unintended actions - such as forwarding sensitive data to an external address.

Mitigate this risk through the following measures:

Human-in-the-loop controls: Require manual approval for any write action. If OpenClaw attempts to send messages, forward emails, or execute commands after processing external content, the user should see an approval prompt before the action proceeds.

Privilege separation: Grant the agent read-only access wherever possible. If OpenClaw is summarising emails, it should not have the ability to send or delete them. Write access should require a separate, explicitly authorised session.

Outbound egress filtering: A common prompt injection payload attempts to exfiltrate data to an attacker-controlled server. Restricting outbound traffic to known, trusted endpoints (such as AI provider APIs) limits the damage a successful injection can cause.

7. Monitoring and Incident Response: Assume Mistakes Will Happen

Log access to the control interface and alert on unexpected access attempts. Monitor outbound connections and token usage for anomalies - new destinations, traffic spikes, or activity at unusual times.

Keep the host OS and dependencies patched and treat the deployment like a server you need to maintain.

If you detect anomalies, revoke tokens immediately and treat the host as compromised.

8. Enterprise Stance: Block or Controlled Pilot, Not “Ignore”

A blanket ban can drive usage into shadow IT. Choose one of two clear approaches:

Option A - Block and Monitor: Treat OpenClaw as unapproved software and block its use on corporate networks, while actively monitoring for unauthorised deployments.

Option B - Controlled Sandbox Pilot: Allow a controlled pilot with strict guardrails:

• Isolated network segment with outbound allowlisting

• Dedicated low-privilege service accounts only

• No password manager or identity admin integrations

• Security logging and EDR on the host

• Named owner with change control and an incident response plan

How RedShield Can Help

If your applications are behind RedShield’s 24/7 managed application security service, we can reduce OpenClaw-related risk through several measures:

• Access control enforcement: Deny-by-default policies for OpenClaw control interfaces and similar AI agent dashboards, permitting access only from approved VPN or IP ranges, or via mutual TLS.

• Header normalisation: Prevent “trusted localhost” misconfigurations that can expose internal interfaces to the internet.

• Bot defences: Detect and block automated scanning and exploitation attempts targeting exposed instances.

• In-flight patching: Deploy guardrails such as step-up authentication for high-risk actions, strict request validation, and response redaction where sensitive data might otherwise leak.

For more information, please contact your RedShield Solution Architect.