OpenClaw Security Hardening - A Complete Checklist

Why Security Matters More for AI Agents

An AI agent is not a static web application. It reasons, takes actions, accesses files, executes commands, and interacts with external services. A compromised OpenClaw instance does not just leak data -- it can actively do things on your behalf. That makes security hardening not just best practice, but essential.

This checklist covers the full stack: the underlying server, the OpenClaw installation itself, the AI models it talks to, and the operational practices that keep everything safe over time. Work through each section methodically. Security is cumulative -- skipping one area can undermine everything else.

Server-Level Hardening

SSH Configuration

SSH is how you access your server and how OpenClaw manages remote connections. Locking it down is your first priority.

Disable password authentication. Use SSH key pairs exclusively. Edit /etc/ssh/sshd_config and set:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

After making changes, restart the SSH service. Make sure you have your SSH key added before disabling password auth -- locking yourself out of your own server is a common mistake.

Change the default SSH port. Moving SSH off port 22 does not stop a determined attacker, but it eliminates the vast majority of automated scanning bots that hammer port 22 constantly. Pick a high port number (e.g., something in the 20000-60000 range) and update your sshd_config accordingly.

Limit SSH access by user. If your server has multiple user accounts, restrict which ones can log in via SSH using the AllowUsers directive.

Set idle timeout. Configure ClientAliveInterval and ClientAliveCountMax to automatically disconnect idle SSH sessions. This prevents forgotten sessions from becoming attack vectors.

Firewall Configuration

A firewall ensures only expected traffic reaches your server. On Ubuntu/Debian, ufw is the simplest option. On CentOS/RHEL, use firewalld.

At minimum, your firewall rules should:

Allow SSH on your chosen port (not 22 if you changed it)
Allow HTTP (80) and HTTPS (443) if your agent serves web traffic
Allow the specific ports OpenClaw uses for its API and WebSocket connections
Deny everything else by default

ufw default deny incoming
ufw default allow outgoing
ufw allow <your-ssh-port>/tcp
ufw allow 443/tcp
ufw enable

Review your rules periodically. It is common to add temporary rules during debugging and forget to remove them.

System Updates

Keep your operating system and all installed packages up to date. Unpatched vulnerabilities in the Linux kernel, OpenSSL, or other system libraries can be exploited regardless of how well OpenClaw itself is configured.

Enable automatic security updates where possible. On Ubuntu, the unattended-upgrades package handles this. On other distributions, equivalent tools exist.

Set a calendar reminder to review and apply non-automatic updates at least monthly.

Fail2Ban

Install and configure Fail2Ban to automatically block IP addresses that show signs of brute-force attacks. It monitors log files for repeated failed authentication attempts and creates temporary firewall rules to ban offending IPs.

Configure it to watch your SSH logs at minimum. If your OpenClaw instance exposes any web-facing authentication, configure Fail2Ban to monitor those logs as well.

OpenClaw Application Security

API Key Management

Your OpenClaw instance holds API keys for AI model providers (Anthropic, OpenAI, etc.), and potentially for other services like databases, messaging platforms, and DNS providers. These keys are the most sensitive data in your deployment.

Never commit API keys to version control. Use environment variables or a .env file that is excluded from your repository via .gitignore.

Use the minimum required permissions for each key. If an AI provider offers scoped API keys, create a key that only has the permissions your agent needs. Avoid using admin-level or unrestricted keys.

Rotate keys regularly. Set a rotation schedule -- quarterly is a reasonable starting point. If you suspect any key has been exposed, rotate it immediately.

Set spending limits on AI provider accounts. Most providers (Anthropic, OpenAI) let you configure monthly spending caps. This limits the damage if a key is compromised and used to run up charges.

Tool and Permission Restrictions

OpenClaw agents can execute commands, access files, browse the web, and interact with external APIs through skills and tools. Not every agent needs all of these capabilities.

Apply the principle of least privilege. Each agent should only have access to the tools and system resources it actually needs for its job. An agent that answers customer questions does not need file system write access. An agent that processes data does not need outbound web browsing.

Restrict file system access paths. If an agent needs to read or write files, limit it to specific directories rather than giving it access to the entire file system. This prevents an agent (or a prompt injection attack exploiting the agent) from accessing sensitive system files.

Review installed skills. Skills from ClawHub extend your agent's capabilities, but each one is also additional attack surface. Only install skills you actively use, and remove ones you no longer need. Before installing a skill, review what permissions and system access it requires.

Authentication and Access Control

If your OpenClaw instance is accessible over the network (not just localhost), authentication is critical.

Use strong authentication for the management interface. Whether you access OpenClaw through myHermy's web panel or your own interface, use strong unique passwords and enable two-factor authentication where available.

Restrict management access by IP. If you always administer your Claw from the same location, restrict management interface access to your IP address or VPN range using firewall rules or application-level access controls.

Use separate credentials for each service. Do not reuse the password for your VPS login, your AI provider account, your DNS provider, and your OpenClaw management interface. Use a password manager.

Network Security

TLS Everywhere

All traffic to and from your OpenClaw instance should be encrypted with TLS.

Use Let's Encrypt for free SSL certificates. Tools like Certbot make this straightforward. Set up automatic certificate renewal -- Let's Encrypt certificates expire every 90 days.

Enforce HTTPS. Redirect all HTTP traffic to HTTPS. Never transmit API keys, authentication tokens, or conversation data over unencrypted connections.

Verify TLS on outbound connections. When your OpenClaw agent connects to external APIs, ensure it validates TLS certificates and does not skip certificate verification. Disabling TLS verification (even in development) is a habit that leads to man-in-the-middle vulnerabilities.

Network Isolation

Run OpenClaw in an isolated network environment when possible. If you are on a cloud provider, use private networks or VPCs to keep your agent's internal traffic off the public internet.

Separate the management plane from the data plane. If your agent serves external users (via WhatsApp, Telegram, etc.), the management interface should not be accessible on the same network path. Use different ports, different IP bindings, or a VPN for management access.

Limit outbound connections. By default, your agent can make outbound connections to any host on the internet. If your agent's use case only requires communicating with specific services, consider restricting outbound traffic to only those destinations using firewall rules.

AI-Specific Security

Prompt Injection Defenses

Prompt injection is the most significant security threat specific to AI agents. We have a dedicated post on this topic, but the hardening checklist items are:

Never trust user input as instructions. Treat all user messages and external data as untrusted content that could contain injection attempts.
Use system prompts to define boundaries. Clearly instruct the model on what it should and should not do, and what kind of requests it should refuse.
Validate agent actions before execution. For high-risk operations (deleting files, sending messages, making API calls), implement confirmation steps or approval workflows.
Sanitize data from external sources. If your agent reads web pages, emails, or files provided by users, that content could contain embedded instructions. Treat it as untrusted.

Model Output Validation

Do not blindly execute everything an AI model returns. If your agent generates code to run, commands to execute, or API calls to make, validate the output before acting on it.

Check that generated commands only use allowed tools and access allowed paths
Verify that API calls target expected endpoints
Implement rate limiting on agent actions to prevent runaway loops

Conversation Data Privacy

AI agent conversations often contain sensitive information -- personal data, business details, authentication credentials that users accidentally share.

Control conversation logging. Decide what gets logged and what does not. If you log full conversations for debugging, ensure those logs are stored securely and access-controlled.

Understand your AI provider's data policies. When you send conversation data to Claude, GPT-4, or other cloud models, understand how that provider handles the data. Most major providers do not train on API data by default, but verify this for your specific plan and provider.

Implement data retention policies. Do not keep conversation history indefinitely. Define how long you retain data and implement automated cleanup.

Monitoring and Incident Response

Log Monitoring

Enable and centralize logging. Your server's system logs, OpenClaw application logs, and access logs should all be monitored. At minimum, set up log rotation so your disk does not fill up, and review logs regularly for anomalies.

Watch for unusual patterns:

Sudden spikes in API usage (could indicate a compromised key or runaway agent)
Failed authentication attempts (brute-force attacks)
Unexpected outbound connections (compromised agent phoning home)
File system changes outside expected directories

Alerting

Set up alerts for critical events. Most cloud providers offer basic monitoring and alerting. For a lightweight self-hosted option, tools like Uptime Kuma can monitor availability, and simple scripts can watch log files for specific patterns.

At minimum, set up alerts for:

Server unreachable (downtime)
High CPU or memory usage sustained over time
AI API spending approaching your budget limit
Failed SSH login attempts exceeding a threshold

Incident Response Plan

Have a plan before you need one. At minimum, know how to:

Revoke and rotate all API keys quickly
Block network access to and from your server (firewall lockdown)
Identify what an attacker accessed by reviewing logs
Restore from a known-good backup

Backups

Back up your OpenClaw configuration, agent definitions, and any persistent data regularly. Store backups in a separate location from your primary server. Test restoration periodically -- a backup you have never tested restoring is not a real backup.

If you use myHermy, the export configuration feature provides a way to capture your agent setup. For self-hosted deployments, back up your environment files, agent configurations, installed skills, and any data directories.

Operational Security Practices

Regular Audits

Schedule periodic security reviews. Every month, spend thirty minutes reviewing:

Which API keys exist and whether they are all still needed
Which skills are installed and whether they are all still used
Which users or SSH keys have access to the server
Whether all software is up to date
Whether firewall rules still match your current requirements

Development vs. Production Separation

Never use your production OpenClaw instance for testing or experimentation. Maintain a separate development environment for trying new skills, testing prompt changes, and experimenting with configurations. This prevents accidental exposure of production data and keeps your live agent stable.

Stay Informed

Follow OpenClaw's release notes and security advisories. When security patches are released, apply them promptly. Join the community channels to stay aware of newly discovered vulnerabilities or attack patterns targeting AI agents.

The AI security landscape evolves rapidly. Techniques that were considered safe six months ago may have known bypasses today. Staying current is an ongoing responsibility, not a one-time task.

The Checklist Summary

Use this as a quick reference. Each item maps to a detailed section above.

Server:

SSH key-only authentication enabled
SSH port changed from default
Firewall configured with deny-all default
Automatic security updates enabled
Fail2Ban installed and configured

Application:

API keys stored in environment variables, not in code
API provider spending limits configured
Agent tool permissions restricted to minimum needed
Unused skills removed
Management interface secured with strong auth

Network:

TLS enabled on all connections
HTTP redirected to HTTPS
Management access restricted by IP or VPN
Outbound connections limited where possible

AI-Specific:

System prompts define clear boundaries
Agent actions validated before execution
External data treated as untrusted
Conversation data retention policy defined

Operations:

Logging enabled and monitored
Alerts configured for critical events
Backups running and tested
Monthly security audit scheduled
Development and production environments separated