Security Best Practices for OpenClaw: Hardening Your Self-Hosted AI Agent

When you self-host an AI agent like OpenClaw, you take full ownership of its security posture. Unlike managed SaaS platforms, every configuration choice — from environment variables to network rules — is yours to manage. This guide walks through the key security practices you should implement to harden your OpenClaw deployment.

Why Security Matters for AI Agents

AI agents like OpenClaw have access to powerful capabilities:

LLM API keys with direct billing implications
Messaging platform tokens (WhatsApp, Telegram, Discord)
File system access within the container
Network access to internal and external services

A misconfigured deployment could expose sensitive credentials, allow unauthorized access, or rack up unexpected API charges.

1. Environment Variable Security

The .env file is the heart of your OpenClaw configuration. Treat it as a secret vault.

Restrict File Permissions

# Set strict permissions — only the owner can read/write
chmod 600 .env

# Verify permissions
ls -la .env
# Expected: -rw------- 1 user user ... .env

Never Commit Secrets to Git

Ensure .env is in your .gitignore:

echo ".env" >> .gitignore

For team environments, use a secrets manager instead of sharing .env files:

# Example: Using Docker secrets
echo "sk-your-api-key" | docker secret create anthropic_api_key -

# Reference in docker-compose.yml
services:
  openclaw-gateway:
    secrets:
      - anthropic_api_key

secrets:
  anthropic_api_key:
    external: true

Rotate API Keys Regularly

Create a rotation schedule for all credentials:

| Credential | Rotation Frequency | How to Rotate | | ------------------- | ------------------ | -------------------------------- | | ANTHROPIC_API_KEY | Every 90 days | Regenerate in provider dashboard | | GATEWAY_TOKEN | Every 30 days | Update .env and restart | | Messaging tokens | Every 90 days | Re-authenticate via CLI |

2. Network Isolation

By default, Docker containers can communicate freely. Lock this down.

Create an Isolated Network

# docker-compose.yml
services:
  openclaw-gateway:
    networks:
      - openclaw-internal
    ports:
      - '127.0.0.1:18789:18789' # Bind to localhost only

networks:
  openclaw-internal:
    driver: bridge
    internal: false
    ipam:
      config:
        - subnet: 172.28.0.0/16

Bind to Localhost Only

Never expose the gateway to 0.0.0.0 in production:

# Bad — accessible from any network
ports:
  - "18789:18789"

# Good — only accessible from the host machine
ports:
  - "127.0.0.1:18789:18789"

Use a Reverse Proxy with TLS

Place Nginx or Caddy in front of OpenClaw for HTTPS:

server {
    listen 443 ssl http2;
    server_name openclaw.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/openclaw.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/openclaw.yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:18789;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

3. Container Hardening

Run as Non-Root User

# In your Dockerfile or docker-compose.yml
services:
  openclaw-gateway:
    user: "1000:1000"
    read_only: true
    tmpfs:
      - /tmp
    security_opt:
      - no-new-privileges:true

Limit Container Resources

Prevent a compromised container from consuming all host resources:

services:
  openclaw-gateway:
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 2G
        reservations:
          cpus: '0.5'
          memory: 512M

Enable Health Checks

services:
  openclaw-gateway:
    healthcheck:
      test: ['CMD', 'curl', '-fsS', 'http://localhost:18789/healthz']
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

4. Monitoring and Logging

Centralize Logs

Configure Docker to forward logs to a central location:

services:
  openclaw-gateway:
    logging:
      driver: 'json-file'
      options:
        max-size: '10m'
        max-file: '3'
        tag: 'openclaw-gateway'

Monitor for Suspicious Activity

Set up alerts for:

Unusual API usage — sudden spike in LLM API calls
Failed authentication attempts — repeated invalid gateway tokens
Container restarts — could indicate exploitation attempts
Network anomalies — unexpected outbound connections

# Simple monitoring with Docker stats
docker stats openclaw-gateway --format \
  "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}"

5. Sandbox Mode

OpenClaw supports agent sandboxing to isolate code execution:

# Enable in .env
OPENCLAW_SANDBOX=true

When enabled, the agent runs tasks in an isolated environment that:

Prevents direct file system access to the host
Limits network access to approved endpoints
Restricts system-level operations
Provides a clean environment for each task execution

6. Security Checklist

Before going to production, verify each item:

[ ] .env file has 600 permissions
[ ] .env is in .gitignore
[ ] Gateway binds to 127.0.0.1 only
[ ] TLS/HTTPS is enabled via reverse proxy
[ ] Container runs as non-root user
[ ] Resource limits are configured
[ ] Health checks are active
[ ] Logging is centralized with size limits
[ ] API keys have a rotation schedule
[ ] Sandbox mode is enabled
[ ] no-new-privileges security option is set
[ ] Docker images are regularly updated

Wrapping Up

Security is not a one-time setup — it is an ongoing process. By implementing these practices, you significantly reduce the attack surface of your OpenClaw deployment. Regularly audit your configuration, keep your Docker images updated, and monitor for anomalies.

For more details, check out the OpenClaw documentation and the Docker security best practices.

Why Security Matters for AI Agents

AI agents like OpenClaw have access to powerful capabilities:

LLM API keys with direct billing implications
Messaging platform tokens (WhatsApp, Telegram, Discord)
File system access within the container
Network access to internal and external services

A misconfigured deployment could expose sensitive credentials, allow unauthorized access, or rack up unexpected API charges.

1. Environment Variable Security

The .env file is the heart of your OpenClaw configuration. Treat it as a secret vault.

Restrict File Permissions

# Set strict permissions — only the owner can read/write
chmod 600 .env

# Verify permissions
ls -la .env
# Expected: -rw------- 1 user user ... .env

Never Commit Secrets to Git

Ensure .env is in your .gitignore:

echo ".env" >> .gitignore

For team environments, use a secrets manager instead of sharing .env files:

# Example: Using Docker secrets
echo "sk-your-api-key" | docker secret create anthropic_api_key -

# Reference in docker-compose.yml
services:
  openclaw-gateway:
    secrets:
      - anthropic_api_key

secrets:
  anthropic_api_key:
    external: true

# docker-compose.yml
services:
  openclaw-gateway:
    networks:
      - openclaw-internal
    ports:
      - '127.0.0.1:18789:18789' # Bind to localhost only

networks:
  openclaw-internal:
    driver: bridge
    internal: false
    ipam:
      config:
        - subnet: 172.28.0.0/16

Bind to Localhost Only

Never expose the gateway to 0.0.0.0 in production:

# Bad — accessible from any network
ports:
  - "18789:18789"

# Good — only accessible from the host machine
ports:
  - "127.0.0.1:18789:18789"

Use a Reverse Proxy with TLS

Place Nginx or Caddy in front of OpenClaw for HTTPS:

server {
    listen 443 ssl http2;
    server_name openclaw.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/openclaw.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/openclaw.yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:18789;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

3. Container Hardening

Run as Non-Root User

# In your Dockerfile or docker-compose.yml
services:
  openclaw-gateway:
    user: "1000:1000"
    read_only: true
    tmpfs:
      - /tmp
    security_opt:
      - no-new-privileges:true

Limit Container Resources

Prevent a compromised container from consuming all host resources:

services:
  openclaw-gateway:
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 2G
        reservations:
          cpus: '0.5'
          memory: 512M

Enable Health Checks

services:
  openclaw-gateway:
    healthcheck:
      test: ['CMD', 'curl', '-fsS', 'http://localhost:18789/healthz']
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

4. Monitoring and Logging

Centralize Logs

Configure Docker to forward logs to a central location:

services:
  openclaw-gateway:
    logging:
      driver: 'json-file'
      options:
        max-size: '10m'
        max-file: '3'
        tag: 'openclaw-gateway'

Monitor for Suspicious Activity

Set up alerts for:

Unusual API usage — sudden spike in LLM API calls
Failed authentication attempts — repeated invalid gateway tokens
Container restarts — could indicate exploitation attempts
Network anomalies — unexpected outbound connections

# Simple monitoring with Docker stats
docker stats openclaw-gateway --format \
  "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}"

5. Sandbox Mode

OpenClaw supports agent sandboxing to isolate code execution:

# Enable in .env
OPENCLAW_SANDBOX=true

When enabled, the agent runs tasks in an isolated environment that:

Prevents direct file system access to the host
Limits network access to approved endpoints
Restricts system-level operations
Provides a clean environment for each task execution

6. Security Checklist

Before going to production, verify each item:

[ ] .env file has 600 permissions
[ ] .env is in .gitignore
[ ] Gateway binds to 127.0.0.1 only
[ ] TLS/HTTPS is enabled via reverse proxy
[ ] Container runs as non-root user
[ ] Resource limits are configured
[ ] Health checks are active
[ ] Logging is centralized with size limits
[ ] API keys have a rotation schedule
[ ] Sandbox mode is enabled
[ ] no-new-privileges security option is set
[ ] Docker images are regularly updated

Wrapping Up

For more details, check out the OpenClaw documentation and the Docker security best practices.

Security Best Practices for OpenClaw: Hardening Your Self-Hosted AI Agent

More in Security

Axios ถูกฝังมัลแวร์: บทเรียนด้านความปลอดภัยสำหรับนักพัฒนา

Security Best Practices for OpenClaw: Hardening Your Self-Hosted AI Agent

More in Security

Axios ถูกฝังมัลแวร์: บทเรียนด้านความปลอดภัยสำหรับนักพัฒนา