# I Exposed My AI Agent to the Internet: An OpenClaw Security Guide

Summary: A practical OpenClaw security guide covering loopback binding, Docker sandboxing, SSH hardening, credential protection, and cloud firewall setup.
Canonical: https://www.dharmikjagodana.com/blogs/how-to-secure-openclaw-on-cloud
Updated: 2026-10-22
Author: Dharmik Jagodana

Tags: [#AI Agents](https://www.dharmikjagodana.com/blogs/tags/ai-agents.md), [#OpenClaw](https://www.dharmikjagodana.com/blogs/tags/openclaw.md), [#Security](https://www.dharmikjagodana.com/blogs/tags/security.md), [#DevOps](https://www.dharmikjagodana.com/blogs/tags/devops.md)

## OpenClaw Security: What I Learned the Hard Way

_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.

### First, Understand What You're Protecting

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.

### My Security Checklist (The Short Version)

Before the 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.

### Network Security: Keep It Private

#### The Default Ports

OpenClaw uses two main ports:

| Port | Service | What It Does |
| --- | --- | --- |
| 18789 | Gateway (WebSocket) | Main communication channel |
| 18793 | Canvas Host | Web UI for control interface |

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

#### What I Actually Do

I bind the gateway to loopback only:

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

For remote access, I use SSH tunnels:

```bash
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.

### Firewall Rules

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

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

### Credential Management: Where Things Often Go Wrong

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 I've Learned

**Store secrets in environment files, not configs**:

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

**Lock down the directory**:

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

**Run the security audit**:

```bash
openclaw security audit --deep
```

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

```bash
openclaw security audit --fix
```

### The Credential Theft Risk

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.

### Authentication: Control Who Can Talk to Your Agent

#### DM Access Policies

OpenClaw has different policies for who can DM your bot:

| Policy | What It Means | My Take |
| --- | --- | --- |
| `disabled` | Ignore all DMs | Maximum lockdown |
| `pairing` | Requires approval code | **My default** |
| `allowlist` | Only pre-approved users | Good for teams |
| `open` | Anyone can DM | Only for public bots |

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 Isolation

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

```json
{
  "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.

### Sandboxing: The Nuclear Option (In a Good Way)

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 Modes

| Mode | What It Does |
| --- | --- |
| `off` | No sandboxing (only for trusted environments) |
| `non-main` | Sandbox all sessions except main |
| `all` | Sandbox everything |

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 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

### Prompt Injection: The AI-Specific Threat

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 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.

### Cloud-Specific Recommendations

#### AWS (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 Cloud

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

#### DigitalOcean

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

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

### System Hardening (The Basics, But Critical)

#### Run as Non-Root

Never run OpenClaw as root. Create a dedicated user:

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

#### SSH Hardening

```bash
# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
```

Use SSH keys only. Period.

#### Automatic Updates

```bash
sudo apt install unattended-upgrades fail2ban
```

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

### Monitoring: Know When Something's Wrong

I check OpenClaw logs regularly:

```bash
openclaw logs --limit 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.

### Final Thoughts

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._

New posts show up on X.

[Follow new posts on X](https://x.com/dharmikjagodana)

[All posts](https://www.dharmikjagodana.com/blogs.md)

## Related

- [The Commands I Never Let an AI Agent Run (and How I Sandboxed OpenClaw)](https://www.dharmikjagodana.com/blogs/ai-agent-commands-never-run-openclaw-sandbox.md): An AI agent security checklist for commands I never let an agent run alone: deletes, force pushes, secrets, and anything on the production database.
- [5 Best Computer-Use Tools for AI Agents (and How to Run Them Safely) (2026)](https://www.dharmikjagodana.com/blogs/best-computer-use-tools-for-ai-agents.md): Computer use tools for AI agents, compared for builders who let a model use a screen. Five vendor options and the shared safety rules. Last checked 2 Nov 2026.
- [5 Best AI Agent Sandboxes for Solo Builders (2026)](https://www.dharmikjagodana.com/blogs/best-ai-agent-sandboxes-for-solo-builders.md): AI agent sandboxes for a solo builder, compared on price, free credit, and MCP. Five ways to run agent code, from the vendor pages checked Oct 26, 2026.