I Exposed My AI Agent to the Internet — Here’s How I Secured My OpenClaw Deployment

Deploying an AI agent that can run shell commands on your server? Here's everything I wish someone had told me about security.

When I first deployed OpenClaw on a cloud server, I made a rookie mistake. I left the gateway port exposed to the internet. No password. No firewall rules. Just raw, unauthenticated access to an AI that could execute any shell command on my machine.

Nothing bad happened. I got lucky.

But that wake-up call made me dig deep into OpenClaw security. After weeks of research, hardening configurations, and learning from the security community, I've compiled everything I know about keeping an OpenClaw deployment safe.

If you're running — or planning to run — OpenClaw on cloud infrastructure, this guide is for you.

OpenClaw isn't a chatbot. It's an AI agent with real capabilities:

• Shell access: It can run any command your user account can run
• File system access: Read and write files anywhere you have permissions
• Network access: Connect to APIs, databases, and external services
• Messaging integration: Send messages via WhatsApp, Telegram, Slack, Discord
• Browser automation: Control web browsers for automation tasks

This power is exactly why OpenClaw is useful. But it's also why security isn't optional — it's the whole ballgame.

The uncomfortable truth: Most OpenClaw security incidents aren't sophisticated attacks. They're misconfigurations. An agent running as root, exposed to the internet, with no command restrictions is fundamentally different from one running as a restricted user, behind a VPN, with proper sandboxing.

Before diving into details, here's the checklist I use for every deployment:

• Gateway bound to 127.0.0.1 (loopback only)
• Ports 18789 and 18793 blocked from public access
• Gateway authentication token enabled
• DM policy set to pairing or allowlist
• ~/.openclaw directory permissions set to 700
• API keys stored in environment files (not config.json)
• Running as non-root user
• Docker sandboxing enabled
• SSH hardened (key-only auth, no root login)
• Firewall configured (UFW or iptables)

Now let me explain why each of these matters.

The default portsThe Default Ports

OpenClaw uses two main ports:

My rule: Neither of these should ever be accessible from the public internet without authentication.

What i actually doWhat I Actually Do

I bind the gateway to loopback only:

# In config.json
{
  "bind": "loopback"
}

For remote access, I use SSH tunnels:

ssh -L 18789:localhost:18789 myserver

Or better yet, I use Tailscale. It creates a private network between my devices with zero-config encryption. The gateway stays on loopback, but I can access it from anywhere on my Tailnet.

Even with loopback binding, I add firewall rules as defense-in-depth:

# UFW rules
sudo ufw deny 18789
sudo ufw deny 18793
sudo ufw allow from 127.0.0.1 to any port 18789

API keys are the crown jewels. If an attacker gets your ANTHROPIC_API_KEY, they can run up your bill and access Claude through your account. If they get your messaging tokens, they can impersonate your bot.

What ive learnedWhat I've Learned

Store secrets in environment files, not configs:

# ~/.openclaw/.env
ANTHROPIC_API_KEY=sk-ant-...
TELEGRAM_BOT_TOKEN=...

Lock down the directory:

chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/.env
chmod 600 ~/.openclaw/config.json

Run the security audit:

openclaw security audit --deep

This checks file permissions, exposed ports, and common misconfigurations. If it finds issues, run:

openclaw security audit --fix

Here's something I didn't know until I started researching: commodity infostealers (like RedLine and Lumma) are actively targeting OpenClaw installations. They're not just after API keys — they want the full workflow context, including message history and tool configurations.

This is why I treat the ~/.openclaw directory like I treat my SSH keys: locked down, backed up securely, and never exposed.

Dm access policiesDM Access Policies

OpenClaw has different policies for who can DM your bot:

I use pairing for personal deployments. When someone tries to DM my bot, they need an approval code that I provide. It's a small friction that prevents random people from interacting with my agent.

Session isolationSession Isolation

If you're running a bot that multiple people can access (like in a Discord server), enable session isolation:

{
  "session": {
    "dmScope": "per-channel-peer"
  }
}

This prevents one user's conversation context from leaking into another user's session. Critical for any multi-user deployment.

Docker sandboxing is my favorite security feature in OpenClaw. It runs agent commands inside isolated containers, preventing the AI from accessing your host system directly.

Sandbox modesSandbox Modes

For production deployments, I use non-main at minimum. This means my main session (personal access) runs on the host, but any other sessions run in containers.

Why sandboxing mattersWhy Sandboxing Matters

Even if an attacker tricks the AI into running malicious commands (prompt injection), the sandbox limits the damage:

• File system isolation: Can't access host files
• Network isolation: Default network: "none" prevents data exfiltration
• Resource limits: Prevents runaway processes from crashing the server
• Non-root execution: Limits blast radius of any exploit

This is the attack vector that keeps me up at night. Prompt injection tricks the AI into following hidden instructions embedded in:

• User messages
• Web pages the agent fetches
• Emails or documents the agent processes
• External data sources

My defense strategyMy Defense Strategy

1. Lock down inbound access — Pairing mode by default
2. Sandbox tool execution — Even if the AI is tricked, damage is contained
3. Use strong models — Claude Opus 4+ has better instruction-following
4. Limit tool access — Only enable tools the agent actually needs
5. Human oversight — Critical commands require approval

There's no perfect defense against prompt injection yet. The best approach is defense-in-depth: multiple layers so that if one fails, others catch it.

Aws ec2lightsailAWS (EC2/Lightsail)

• Use Security Groups to block ports 18789/18793 from public
• Use IAM roles instead of hardcoded AWS credentials
• Consider AWS Secrets Manager for API keys

Google cloudGoogle Cloud

• Configure firewall rules at VPC level
• Use Cloud IAP for secure access without VPN
• Use Secret Manager for credentials

DigitaloceanDigitalOcean

Their 1-Click Deploy is actually pretty good out of the box:

• Non-root execution
• Docker isolation
• Hardened firewall
• Private DM pairing by default

Run as non rootRun as Non-Root

Never run OpenClaw as root. Create a dedicated user:

sudo useradd -m -s /bin/bash openclaw
sudo -u openclaw openclaw start

Ssh hardeningSSH Hardening

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no

Use SSH keys only. Period.

Automatic updatesAutomatic Updates

sudo apt install unattended-upgrades fail2ban

Security patches should apply automatically. Fail2ban blocks brute-force attempts.

I check OpenClaw logs regularly:

openclaw logs --tail 100

Things I look for:

• Unexpected command executions
• Authentication failures
• Sessions from unknown sources
• High API usage spikes

For production, I'd recommend sending logs to a centralized system (Loki, CloudWatch, etc.) and setting up alerts.

OpenClaw is incredibly powerful. That power comes with responsibility.

The good news: most security risks come from misconfigurations, not sophisticated attacks. If you follow the checklist in this guide, you're ahead of most deployments.

The key principles:

1. Keep it private — Loopback binding, SSH tunnels, VPN access
2. Lock down credentials — Environment files, proper permissions
3. Sandbox execution — Contain the blast radius
4. Enable authentication — Pairing mode, gateway tokens
5. Monitor everything — Logs, alerts, regular audits

Stay safe out there.

Have questions about OpenClaw security? Find me on Twitter/X or drop me an email. Always happy to chat about AI agent security.