The 5 Security Mistakes Everyone Makes Setting Up OpenClaw

OpenClaw is incredible. You get a full AI agent — running Claude, with tool access, persistent memory, and real-time messaging — on your own infrastructure. It's the closest thing to having a personal AI that actually does things.

But here's the problem: most people set it up wrong.

I've audited dozens of OpenClaw deployments and written a 66-page production guide on getting it right. The same five mistakes show up in nearly every self-deployed instance. Some of them are subtle. Some of them are terrifying.

Let's go through them.

---

Mistake #1: Exposing Docker Ports to the Public Internet

This is the big one. It's also the most common.

The default Docker setup for many services binds ports to 0.0.0.0 — which means "listen on every network interface, including the public one." If your EC2 security group allows inbound traffic on those ports (and many people open them up "temporarily" during setup), your OpenClaw instance is directly reachable from anywhere on the internet.

That means anyone can:

• Send messages to your agent
• Trigger tool executions on your server
• Potentially access your connected integrations (Jira, Slack, Stripe, etc.)

What this looks like in practice:

# docker-compose.yml — THE WRONG WAY
ports:
  - "3000:3000"   # Exposed to the world

The fix: Don't expose ports publicly at all. Use a mesh VPN like Tailscale to create a private network between your devices and your server. Your agent is only reachable from devices on your Tailscale network — zero open ports, zero attack surface from the internet.

# docker-compose.yml — THE RIGHT WAY
ports:
  - "127.0.0.1:3000:3000"   # Only accessible locally/via VPN

Combined with a properly configured Tailscale setup, your instance becomes invisible to port scanners and automated attacks. I've run production agents for months with zero unsolicited connection attempts — because there's nothing to connect to from the outside.

---

Mistake #2: Storing Secrets in Plain Text (or Worse, in Git)

You'd be surprised how many OpenClaw setups have API keys hardcoded directly in configuration files. Or stored in a .env file that got committed to a Git repository. Or sitting in a docker-compose.yml that's world-readable.

When your agent has access to your Anthropic API key, your Jira token, your Stripe key, and your Slack bot token, a single exposed credential becomes a breach of everything.

Common patterns I see:

# config.yaml — DON'T DO THIS
anthropic_key: sk-ant-api03-abc123...
jira_token: ATATT3xFfGF0...
stripe_key: sk_live_51O...

The fix: Every secret goes in a .env file that is:

1. Listed in .gitignore (never committed)
2. Readable only by the Docker container user (chmod 600)
3. Referenced via environment variables in your compose file

# docker-compose.yml
environment:
  - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
  - JIRA_TOKEN=${JIRA_TOKEN}

For production deployments, I also recommend encrypting the .env file at rest and only decrypting it during container startup. If someone gains filesystem access, they still can't read your keys without the decryption passphrase.

---

Mistake #3: No Resource Limits on the Container

OpenClaw agents can execute code, make API calls, and run shell commands. If something goes wrong — an infinite loop, a runaway process, a prompt injection that triggers recursive tool calls — your container can consume all available CPU and memory, taking down the entire server.

Without resource limits, a single bad interaction can:

• Max out your EC2 CPU credits (and your bill)
• Exhaust system memory, killing other processes
• Fill your disk with logs or generated files
• Run your Anthropic API bill into hundreds of dollars in minutes

The fix: Set explicit resource constraints in your Docker Compose file:

services:
  openclaw:
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 1G
        reservations:
          cpus: '0.25'
          memory: 256M

Also configure OpenClaw's built-in loop detection and cost controls. Set a maximum number of tool calls per conversation turn, a maximum token budget per interaction, and enable the cost tracking features. These are your last line of defense against runaway behavior.

---

Mistake #4: Running as Root Inside the Container

Many Docker setups run processes as the root user inside the container. This means if an attacker (or a misbehaving agent) manages to escape the application layer, they have root-level access to the container's filesystem — and potentially to the host system if there's a container escape vulnerability.

How to check if you're affected:

# Run this to check your container user
docker exec openclaw whoami
# If this returns "root", you have a problem

The fix: Create a non-root user in your Dockerfile and run the application as that user:

RUN useradd -m -s /bin/bash openclaw
USER openclaw

Additionally, use Docker's security options to drop unnecessary Linux capabilities:

services:
  openclaw:
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL

This follows the principle of least privilege. Your agent doesn't need the ability to modify system network interfaces or load kernel modules — so don't give it those capabilities.

---

Mistake #5: No SSH Hardening on the Host

Your EC2 instance is the foundation everything runs on. If someone compromises SSH access, they own everything — your agent, your secrets, your integrations.

Default SSH configurations are designed for convenience, not security. I regularly see OpenClaw servers running with:

• Password authentication enabled (brute-forceable)
• Root login allowed (single password = full access)
• Default port 22 (targeted by every automated scanner)
• No fail2ban or rate limiting

The fix: Lock down SSH properly:

# /etc/ssh/sshd_config
PasswordAuthentication no       # Key-based only
PermitRootLogin no              # No root SSH
Port 22                         # Keep default (Tailscale makes port irrelevant)
MaxAuthTries 3                  # Lock out after 3 failures

Install fail2ban to automatically block IPs after repeated failed attempts:

sudo apt install fail2ban
sudo systemctl enable fail2ban

But honestly? If you're using Tailscale correctly (see Mistake #1), SSH isn't even reachable from the internet. Your firewall should block all inbound connections on all ports from public IPs. SSH only works over the Tailscale network. This is defense in depth — the firewall stops the attack, SSH hardening is the backup.

---

The Compound Effect

Any one of these mistakes is survivable. But most self-deployed OpenClaw instances have all five. And the combination is dangerous:

• Public ports + plaintext secrets = anyone can steal your API keys
• No resource limits + no loop detection = a single prompt injection burns through your Anthropic credits
• Root container + no SSH hardening = a compromised agent could pivot to the host system

The good news: every one of these is fixable. The bad news: fixing them properly requires understanding Docker networking, Linux security, VPN architecture, and cloud infrastructure patterns — which is a lot to learn when you just want a working AI assistant.

---

What I Didn't Cover

This article covers the five most common mistakes, but there's more to a production-grade deployment:

• Automated backup strategies for agent memory and configuration
• Log rotation and monitoring (so your disk doesn't fill up)
• Graceful container restart policies
• Update strategies for OpenClaw itself
• Integration security (least-privilege API tokens, webhook validation)
• Cost alerting and budget caps

I cover all of this — and much more — in my 66-page OpenClaw Starter Kit and in the deployments I do for clients.

---