Security Guide

Security models, sandboxing, and best practices for OpenClaw (formerly Clawdbot and Moltbot)

Important: OpenClaw connects to real messaging surfaces. Treat inbound DMs as untrusted input. This guide explains how to secure your OpenClaw installation.

Security Model Overview

OpenClaw uses a layered security approach:

  • DM Pairing - Unknown senders require explicit approval
  • Sandboxing - Group and untrusted sessions can run in isolated containers
  • Tool Policies - Granular control over which tools agents can use
  • Allowlists - Control who can interact with your assistant
  • Local-First - All data stays on your machine

Default DM Access (Pairing)

Default behavior on Telegram/WhatsApp/Signal/iMessage/Microsoft Teams/Discord/Google Chat/Slack:

  • DM Pairing (dmPolicy="pairing") - Unknown senders receive a short pairing code
  • The bot does not process messages from unpaired contacts
  • Approve with: openclaw pairing approve <channel> <code>
  • Once approved, the sender is added to a local allowlist

Opening DM Access

To allow public DMs (not recommended for most users):

  • Set dmPolicy="open"
  • Include "*" in the channel allowlist (allowFrom)
  • This allows anyone to message your assistant

Warning: Only use open DM policy if you understand the security implications and have proper sandboxing configured.

Sandbox Configuration

Default Behavior

  • Main Session: Tools run on the host with full access (for trusted use)
  • Non-Main Sessions: Can be configured to run in Docker sandboxes

Enabling Sandboxing

To sandbox group chats and non-main sessions:

Sandbox Configuration 
{
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "non-main"
      }
    }
  }
}

This runs non-main sessions (groups/channels) inside per-session Docker sandboxes. Bash commands then run in Docker for those sessions.

Sandbox Tool Policies

Default Allowlist:

  • bash, process, read, write, edit
  • sessions_list, sessions_history, sessions_send, sessions_spawn

Default Denylist:

  • browser, canvas, nodes, cron
  • discord, gateway

You can customize these lists per session or globally.

Group Chat Security

For group chats, OpenClaw provides several security layers:

  • Group Allowlists - Control which groups the bot can access
  • Mention Gating - Require @mentions in groups (default)
  • Sandboxing - Groups can run in isolated Docker containers
  • Activation Modes - Control when the bot responds

Example Group Configuration

Group Security Config 
{
  "channels": {
    "telegram": {
      "groups": {
        "*": {
          "requireMention": true
        },
        "123456789": {
          "requireMention": false,
          "activation": "always"
        }
      }
    }
  }
}

Authentication & Access Control

Gateway Authentication

The Gateway can be secured with:

  • Token Authentication - Required for non-loopback binds
  • Password Authentication - Set via gateway.auth.mode
  • Loopback-Only - Default binding to 127.0.0.1 for local access

Remote Access Security

For remote Gateway access:

  • SSH Tunnels - Encrypted tunnel to localhost
  • Tailscale - Secure VPN with authentication
  • Gateway Tokens - Required for non-loopback access

Never expose the Gateway directly to the internet without proper authentication.

Agent Social Networks (Moltbook)

Connecting your OpenClaw agent to social networks like Moltbook introduces additional security considerations:

Security Risks

  • Prompt Injection: Malicious agents or posts can attempt to manipulate your agent through prompt injection attacks
  • Cross-Agent Manipulation: Agents can interact freely, potentially tricking each other into leaking data or running destructive commands
  • Supply Chain Risks: Skills that fetch updates from external servers create potential supply chain attack vectors
  • Data Exposure: Your agent may share information about its work, experiences, and potentially your workflows
  • Untrusted Network: Social networks are untrusted environments where agents from various sources interact

Mitigation Strategies

To secure your agent when connecting to social networks:

  • Use Sandboxing: Configure Moltbook interactions to run in sandboxed sessions
  • Isolate Deployment: Run OpenClaw in a VM, Docker container, or dedicated hardware
  • Network Restrictions: Block outbound access except to approved endpoints
  • Monitor Activity: Enable verbose logging and monitor what your agent posts
  • Review Skills: Manually review skill files before installation, especially those from external sources
  • Manual Control: Some users prefer to start/stop the gateway manually for social network interactions
  • Least Privilege: Use restrictive tool policies and file system permissions

For detailed security analysis of AI agent social networks, see: Security Risks in AI Agent Social Networks

Data Privacy

OpenClaw is designed for privacy:

  • Local Storage - All data stored on your machine
  • No Cloud Sync - Your conversations never leave your device
  • Encrypted Credentials - Channel credentials stored securely
  • LLM Provider - Only your chosen LLM provider receives messages (Anthropic, OpenAI, etc.)

Note: When connecting to social networks like Moltbook, your agent's posts and interactions are publicly visible. Review what your agent shares to ensure you're comfortable with the information being exposed.

Your workspace, memories, and configuration are stored as files you can inspect, edit, or delete at any time.

Enterprise and Business Deployment

Deploying OpenClaw in business or enterprise environments requires additional security considerations:

Shadow IT Risks

Employees may install OpenClaw without IT approval, creating shadow IT risks. This can lead to:

  • Unauthorized access to company data and systems
  • Exposure of sensitive information through agent interactions
  • Compliance violations (GDPR, HIPAA, etc.)
  • Security vulnerabilities from misconfigured deployments
  • Unmonitored access to production resources

Enterprise Security Recommendations

  • IT Policy: Establish clear policies about AI agent usage in business environments
  • Approved Deployments: Only allow OpenClaw on approved, isolated systems (VMs, containers)
  • Access Controls: Implement strict allowlists and DM pairing for all channels
  • Monitoring: Enable comprehensive logging and monitoring for all OpenClaw instances
  • Network Isolation: Deploy in isolated network segments with restricted outbound access
  • Regular Audits: Use openclaw doctor and security scanning tools regularly
  • Employee Training: Educate staff about security risks and proper usage
  • Data Classification: Restrict access to sensitive data directories and systems

For detailed analysis of enterprise security concerns, see: OpenClaw AI Runs Wild in Business Environments

Best Practices

Recommended Security Setup

  1. Use DM Pairing - Keep default pairing policy for DMs
  2. Enable Sandboxing - Sandbox non-main sessions for groups
  3. Configure Allowlists - Explicitly allow trusted contacts
  4. Use Mention Gating - Require mentions in group chats
  5. Run Doctor - Regularly run openclaw doctor to check for misconfigurations
  6. Review Logs - Monitor Gateway logs for suspicious activity
  7. Keep Updated - Regularly update OpenClaw for security patches
  8. Isolate Deployments - Use VMs, Docker containers, or dedicated hardware for production use

Security Checklist

  • ✅ DM pairing enabled for all channels
  • ✅ Group allowlists configured
  • ✅ Sandboxing enabled for non-main sessions
  • ✅ Gateway bound to loopback or secured with authentication
  • ✅ Regular security audits with openclaw doctor
  • ✅ Credentials stored securely
  • ✅ LLM provider credentials secured

Running Security Checks

Use the built-in doctor command to check your security configuration:

Security Check 
openclaw doctor

This will surface:

  • Risky DM policies
  • Misconfigured sandbox settings
  • Missing authentication
  • Security warnings

Related Documentation