A founder set up an AI agent on his own last month. YouTube tutorial. Weekend project. Got it running, connected to email, Slack, gave it shell access.
No Docker sandbox. No firewall rules. API keys in a plaintext .env file.
At 4am, someone found an exposed port. By the time he woke up, his server was compromised. We spent 6 hours cleaning up. Rotating every credential. Rebuilding from backup.
This is the third story like this I've heard this year. Here's how to not be the fourth.
Why AI Agent Security Is Different
A traditional web application has a defined attack surface. HTTP endpoints, a database, maybe some file storage. You know what needs protecting.
An AI agent has access to everything you've connected it to. That typically includes:
- Email (read every message, send as you)
- Calendar (see your entire schedule, create events)
- Slack (post in any channel, read all messages)
- File system (read and potentially write documents)
- Shell access (execute commands on the server)
- API keys (for every connected service)
If an attacker compromises your agent, they don't get a web page. They get your business. Every email. Every document. Every credential the agent uses.
Security isn't optional. It's the foundation.
Layer 1: Docker Sandboxing
Your AI agent should never run directly on the host operating system. Docker containers provide isolation that limits what a compromised agent can do.
Minimal Docker Configuration
version: '3.8'
services:
openclaw:
image: node:22-slim
user: "1000:1000" # Non-root user
volumes:
- ./workspace:/home/agent/workspace:rw
- ./config:/home/agent/.openclaw:ro # Read-only config
environment:
- NODE_ENV=production
restart: unless-stopped
security_opt:
- no-new-privileges:true
read_only: true
tmpfs:
- /tmp:size=100M,noexec
cap_drop:
- ALL
cap_add:
- NET_BIND_SERVICE # Only if needed
networks:
- agent-network
deploy:
resources:
limits:
cpus: '2.0'
memory: 2G
networks:
agent-network:
driver: bridge
What each setting does:
user: "1000:1000"— Runs as non-root. If the agent is compromised, the attacker has limited user permissions.read_only: true— Container filesystem is read-only. The agent can't modify system files or install malware.no-new-privileges— Prevents privilege escalation. Can't use setuid binaries.cap_drop: ALL— Removes all Linux capabilities. The agent can't mount filesystems, change network settings, or modify kernel parameters.tmpfs: noexec— Temporary directory exists in memory and doesn't allow executing binaries.- Resource limits — Prevents a runaway process from consuming all server resources.
Network Isolation
The agent should only be able to reach the specific API endpoints it needs:
# docker-compose.override.yml
services:
openclaw:
dns:
- 1.1.1.1
# For strict isolation, use an egress proxy
# that only allows connections to known API hosts
For maximum security, run an egress proxy (like Squid) that whitelists only the domains your agent needs:
# squid.conf whitelist
acl allowed_hosts dstdomain api.openai.com
acl allowed_hosts dstdomain api.anthropic.com
acl allowed_hosts dstdomain gmail.googleapis.com
acl allowed_hosts dstdomain slack.com
acl allowed_hosts dstdomain www.googleapis.com
http_access allow allowed_hosts
http_access deny all
If the agent is compromised, it can't reach command-and-control servers. It can only talk to the APIs it legitimately uses.
Layer 2: Credential Management
API keys are the crown jewels. Treat them accordingly.
Never Use Plaintext
The most common security failure we see: a .env file in the home directory with every API key in plaintext.
# NEVER DO THIS
OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxx
SLACK_BOT_TOKEN=xoxb-xxxxxxxxxxxxxxxx
GMAIL_CLIENT_SECRET=xxxxxxxxxxxxxxxx
If your server is compromised, these keys give the attacker immediate access to every connected service.
Use OpenClaw's Credential Encryption
OpenClaw encrypts credentials using a keyring-based system:
openclaw configure --section llm
openclaw configure --section slack
openclaw configure --section google-workspace
Credentials are encrypted at rest and only decrypted in memory when needed. Even if someone gets access to the config files, they can't read the keys without the keyring password.
Rotate Keys Regularly
Set calendar reminders to rotate API keys every 90 days. When rotating:
- Generate the new key in the provider's dashboard
- Update OpenClaw's config with the new key
- Verify the agent works with the new key
- Revoke the old key
Don't skip step 4. Old keys sitting in a provider's dashboard are a liability.
Scope Keys Minimally
Most API providers let you scope keys to specific permissions. Use the narrowest scope possible:
- Gmail: Use separate read and send keys if the provider supports it
- Slack: Bot token with only the channels and actions needed
- OpenAI: Set spending limits on the key
- CRM: Read-only key for the agent, separate admin key for you
If the agent only needs to read email, don't give it send permission. If it only needs one Slack channel, don't give it access to the whole workspace.
Layer 3: SSH Hardening
If your server is accessible via SSH (and it probably is), lock it down.
Disable Password Authentication
# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
MaxAuthTries 3
AllowUsers youradmin
ClientAliveInterval 300
ClientAliveCountMax 2
SSH keys only. No passwords. No root login. This eliminates brute-force attacks entirely.
Use a Non-Standard Port
# /etc/ssh/sshd_config
Port 2222 # Anything other than 22
This won't stop a targeted attacker, but it eliminates 99% of automated scanning bots that only try port 22.
Install Fail2ban
sudo apt install fail2ban
Configure /etc/fail2ban/jail.local:
[sshd]
enabled = true
port = 2222
maxretry = 3
bantime = 3600
findtime = 600
Three failed login attempts = banned for an hour. Repeat offenders get progressively longer bans.
Layer 4: Firewall
Use ufw (Ubuntu) or iptables to restrict network access:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp # SSH
sudo ufw allow 443/tcp # HTTPS (if running a webhook endpoint)
sudo ufw enable
Only open the ports you absolutely need. Every open port is a potential entry point.
Layer 5: Monitoring and Alerting
Security isn't just prevention. It's detection.
Log Everything
# OpenClaw logging config
logging:
level: info
file: /var/log/openclaw/agent.log
rotate: daily
retain: 30
include:
- api_calls
- credential_access
- shell_commands
- email_actions
- file_access
Set Up Alerts
Monitor for unusual behavior:
- Agent making API calls outside normal hours
- Sudden spike in API usage (could indicate credential theft)
- Failed authentication attempts
- New outbound connections to unknown hosts
- Shell commands the agent doesn't normally run
Tools like osquery, auditd, or even a simple log-watching script can catch these patterns.
Daily Security Check
Add a security check to your agent's heartbeat:
## Security Check
- Verify all SSL certificates are valid
- Check for unauthorized SSH logins in auth.log
- Verify Docker container is running with correct security options
- Check disk space (full disks can cause unexpected behavior)
- Verify credential files haven't been modified
Layer 6: Backup and Recovery
Assume breach. Plan for recovery.
Automated Backups
# Daily backup of agent config and workspace
0 3 * * * tar -czf /backup/openclaw-$(date +%Y%m%d).tar.gz \
/home/agent/.openclaw /home/agent/workspace
Store backups off-server. If the server is compromised, backups on the same machine are useless.
Recovery Playbook
Document the recovery steps before you need them:
- Take the server offline
- Rotate ALL credentials (every API key, every token)
- Notify affected services (Gmail, Slack, CRM)
- Rebuild from backup on a fresh server
- Re-authenticate all integrations
- Review logs to determine what was accessed
- Update security measures to prevent recurrence
Practice this playbook once. A recovery plan you've never tested isn't a plan. It's a wish.
The 40% Rule
When we deploy agents for clients, roughly 40% of our time is security configuration. Not because it's complicated in theory, but because doing it right requires attention to detail across multiple layers.
Docker sandboxing. SSH hardening. Credential encryption. Network isolation. Monitoring. Backup. Each layer is straightforward individually. Together, they create a security posture that makes your agent safe to run in production.
Skip any layer and you're leaving a gap. It's the gaps that get exploited.
Let Us Handle It
If security hardening sounds like a lot of work, it is. That's why we do it for you.
Every OpenClaw Setup deployment includes the full security stack: Docker sandboxing, SSH hardening, credential encryption, firewall configuration, Fail2ban, monitoring, and backup. All configured for your specific setup.
$999. One-time. No security subscriptions. No "premium security tier."
Book a call and we'll make sure your agent is locked down before it reads its first email.
Running an agent without security? Fix it now. Our Mac Mini setup guide covers the basics, or reach out at openclawsetup.dev/meet for the full hardening treatment.