OpenClaw Security Hardening Guide for VPS Deployments

OpenClaw is powerful because it can connect to tools, files, browsers, APIs, messaging platforms, and automation workflows. That same power also makes security important. If OpenClaw is deployed on a VPS, the server may become the source of truth for agent state, workspace files, logs, credentials, integrations, and remote access.

This guide explains how to harden an OpenClaw VPS deployment by reducing public exposure, securing the Gateway, limiting tool permissions, protecting secrets, enabling sandboxing, controlling browser access, and preparing a basic incident response plan.

For most users, the safest OpenClaw VPS setup is simple: keep the Gateway private, access it through SSH tunneling or a private network such as Tailscale or WireGuard, use strong token-based authentication, enable firewall rules, keep OpenClaw updated, and separate trust boundaries across different VPS instances or OS users.

OpenClaw Security Checklist

Use this checklist before running OpenClaw on a production or always-on VPS:

• Keep the OpenClaw Gateway bound to loopback unless remote access is absolutely required.
• Use SSH tunneling, Tailscale, WireGuard, or another VPN for remote access.
• Require a long random gateway token or strong authentication for any non-loopback access.
• Do not expose the OpenClaw Gateway directly to the public internet.
• Use SSH keys instead of password-based SSH login.
• Enable a firewall and only allow required ports.
• Keep OpenClaw, Docker, Node.js, and operating system packages updated.
• Run OpenClaw under a dedicated Linux user instead of using your main administrative account.
• Use one Gateway per trust boundary.
• Enable sandboxing for tool execution when possible.
• Avoid giving agents unnecessary shell, filesystem, browser, or network access.
• Use dedicated browser profiles for OpenClaw instead of personal daily-use browser profiles.
• Disable browser password managers and sync inside agent-controlled browser profiles.
• Protect API keys, tokens, workspace files, and logs.
• Back up OpenClaw state and workspace files regularly.
• Run OpenClaw security audits after configuration changes.

Why OpenClaw Needs Security Hardening

OpenClaw should not be treated like a normal web application or static website. An OpenClaw agent may be able to read files, execute tools, access APIs, automate browser sessions, connect to chat platforms, and act on behalf of a user or business workflow.

If an attacker gains access to the OpenClaw Gateway or a tool-enabled agent, the impact may include:

• Access to OpenClaw configuration files.
• Exposure of API keys, model provider credentials, bot tokens, or integration secrets.
• Access to workspace files, logs, transcripts, and generated outputs.
• Unauthorized agent commands.
• Abuse of connected messaging platforms such as Slack, Discord, Telegram, WhatsApp, or other channels.
• Browser session abuse if the agent controls a logged-in browser profile.
• Unwanted file changes, command execution, or data exfiltration.

The safest approach is to assume that OpenClaw has meaningful delegated authority. Give it only the access it needs, keep remote access private, and split different users or trust levels across separate environments.

Use One Gateway Per Trust Boundary

OpenClaw is best treated as a personal assistant or single-trust-boundary system. A trust boundary means a group of users, agents, credentials, files, and tools that are allowed to share the same authority.

For a personal deployment, one user can run one Gateway on one VPS. For a business deployment, a team can share one OpenClaw environment only if every user is trusted to operate within the same delegated permission set.

Do not use one shared OpenClaw Gateway for mutually untrusted users. If different users, departments, customers, or projects should not share access, split them into separate environments.

Recommended isolation patterns include:

• Separate VPS instances for different users or teams.
• Separate OpenClaw Gateways for different trust boundaries.
• Separate Linux users for different deployments on the same server.
• Separate credentials, bot tokens, browser profiles, and workspace directories.
• Separate backups and logs for each environment.

This matters because a shared tool-enabled agent can often act with the same permissions regardless of which allowed user triggered the action. Session labels and chat identifiers should not be treated as strong authorization boundaries.

Keep the OpenClaw Gateway Private

The OpenClaw Gateway is the most important surface to protect. It controls state, workspace access, device pairing, tool execution, and communication between clients and nodes.

The safest default is to keep the Gateway bound to loopback and access it privately. In practice, this means the Gateway listens only on the VPS itself and is reached through a secure tunnel or private network.

Preferred access methods include:

• SSH tunnel from your laptop to the VPS.
• Tailscale private network access.
• WireGuard VPN access.
• Private management network where available.

Avoid exposing the Gateway directly on a public IP address. If you must bind the Gateway to a LAN, tailnet, or other non-loopback interface, require strong authentication and restrict access with firewall rules.

Use Strong Gateway Authentication

Gateway authentication should use a long, random token or another strong authentication method. Do not rely on a short or human-created password for an agent system that may control tools, files, APIs, and browser sessions.

A good gateway token should be:

• Long.
• Randomly generated.
• Unique to that OpenClaw deployment.
• Stored securely.
• Rotated if exposed.
• Not reused across other services.

Do not paste gateway tokens into public tickets, chat rooms, screenshots, or documentation. If a token may have been exposed, rotate it immediately and review logs for unexpected connections or device registrations.

Update OpenClaw Regularly

Keeping OpenClaw updated is a security requirement, not just a maintenance task. In 2026, the ClawJacked vulnerability showed why Gateway authentication, local WebSocket assumptions, device registration, and rate limiting matter. OpenClaw patched the issue in version 2026.2.25.

Before running OpenClaw on an always-on VPS, verify your installed version and update regularly.

openclaw --version

If you installed OpenClaw through npm, pnpm, Docker, or another package method, use the appropriate update process for your installation. After updating, restart the Gateway and run a security audit.

openclaw security audit

For deeper checks, use:

openclaw security audit --deep

If OpenClaw reports fixable issues, review them carefully before applying changes. Some auto-fixes may tighten policies, permissions, redaction, or access settings.

openclaw security audit --fix

Secure SSH Access to the VPS

Because the VPS hosts OpenClaw state and configuration, SSH access must be hardened. If an attacker gains SSH access, they may be able to read OpenClaw files, modify configuration, steal tokens, change tools, or access logs.

Recommended SSH hardening steps:

• Use SSH keys instead of passwords.
• Disable password login when possible.
• Disable direct root password login.
• Use a dedicated administrative user with sudo privileges.
• Restrict SSH access by IP address when practical.
• Keep OpenSSH updated.
• Use fail2ban or equivalent protection for repeated login attempts.

Example SSH configuration hardening options may include:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

After changing SSH configuration, test a second SSH session before closing the first one so you do not accidentally lock yourself out.

Enable a Firewall

A VPS running OpenClaw should have a default-deny firewall posture. Only required services should be exposed. For many deployments, SSH is the only public port that needs to be reachable.

Example UFW baseline:

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw enable
ufw status verbose

If you use a VPN such as WireGuard or a private network such as Tailscale, allow OpenClaw access only through that private interface. Do not open the Gateway port to the public internet unless you fully understand the risk and have authentication, firewall restrictions, TLS, logging, and monitoring in place.

The OpenClaw Gateway commonly uses port 18789. In a hardened deployment, that port should usually remain private and reachable only through loopback, SSH tunneling, VPN, or a trusted private network.

Run OpenClaw Under a Dedicated Linux User

Do not run OpenClaw as root unless there is a specific reason and you understand the implications. A dedicated Linux user helps limit accidental access to system-wide files and makes it easier to manage permissions, logs, backups, and service ownership.

Example:

adduser openclaw
usermod -aG docker openclaw

Use the dedicated user for OpenClaw application files, workspace data, configuration, and runtime services. Keep administrative tasks separate from normal agent operation.

Protect OpenClaw State, Workspace, and Credentials

OpenClaw state and workspace directories can contain sensitive data. Depending on your configuration, they may include credentials, tokens, auth profiles, transcripts, logs, browser data, integration settings, workspace files, and generated outputs.

Recommended practices:

• Restrict file permissions on OpenClaw configuration and state directories.
• Do not store OpenClaw state inside public web directories.
• Do not sync sensitive OpenClaw directories to insecure shared folders.
• Do not make workspace files world-readable.
• Keep secrets out of screenshots, public tickets, and documentation.
• Use environment variables, secret files, or secret managers where appropriate.
• Back up state and workspace files securely.

Review permissions regularly:

ls -la ~/.openclaw

For a single-user VPS deployment, OpenClaw configuration and credential files should generally be readable only by the OpenClaw user and trusted administrators.

Enable Sandboxing for Tool Execution

Sandboxing reduces the blast radius of agent tool execution. When sandboxing is enabled, OpenClaw can run tools inside isolated sandbox backends instead of directly on the host. Docker is commonly used for this purpose.

Sandboxing is not a perfect security boundary, but it can materially reduce risk by limiting filesystem and process access when an agent uses tools incorrectly or responds to malicious instructions.

Sandboxing is especially important when agents can:

• Run shell commands.
• Read and write files.
• Edit code or configuration.
• Use browser automation.
• Process untrusted content.
• Interact with files from customers, users, or public websites.

Recommended sandboxing practices:

• Enable sandboxing for non-owner or high-risk agent sessions.
• Prefer per-agent or per-session sandbox scope over one shared sandbox for all sessions.
• Avoid unnecessary host bind mounts.
• Keep sandbox images minimal.
• Do not mount secrets into sandbox containers unless required.
• Limit network access for sandboxes when possible.
• Review any elevated tools that bypass sandbox restrictions.

If sandboxing is disabled, tool execution may run on the host. That means the agent may have direct access to the VPS filesystem and processes available to the OpenClaw runtime user.

Limit Tool Permissions

Do not give every agent full shell, filesystem, browser, and network access by default. Start with the smallest tool permissions that still allow the workflow to function.

Useful permission patterns include:

• Read-only agents for research or monitoring tasks.
• Agents without shell access for messaging-only workflows.
• Agents with restricted workspace directories instead of full filesystem access.
• Separate agents for sensitive and non-sensitive workflows.
• Manual approval for destructive or high-risk actions.

Review any tool that can:

• Execute commands.
• Write or delete files.
• Access secrets.
• Send messages externally.
• Control a browser.
• Call internal APIs.
• Reach private networks.

Tool permissions should be treated as real security permissions. If a user can send instructions to a tool-enabled agent, that user may be able to cause the agent to use those tools.

Harden Browser Automation

Browser automation is one of the highest-risk OpenClaw features because a browser may already be logged into accounts, dashboards, email, cloud services, or internal applications. If an agent controls that browser, the agent may be able to act with the browser user's permissions.

Recommended browser hardening steps:

• Use a dedicated browser profile for OpenClaw.
• Do not use your personal daily browser profile for agent automation.
• Disable browser password managers in the agent profile.
• Disable browser sync in the agent profile where possible.
• Use isolated download directories.
• Treat downloaded files as untrusted.
• Do not expose browser control ports to the public internet.
• Keep browser control access on a private network or tailnet.
• Disable browser proxy routing when you do not need it.

If OpenClaw controls a browser profile that is logged into business systems, treat that profile as sensitive production access. Separate browser profiles by workflow and trust level.

Control Private Network and Internal URL Access

Agents that can browse the web may encounter prompt injection, malicious websites, redirects, or pages designed to trick automation systems. If browser automation can reach private network addresses, internal dashboards, metadata services, or localhost-only systems, the risk increases.

Recommended practices:

• Block private and internal network destinations unless explicitly required.
• Use allowlists for internal hosts that the agent is allowed to reach.
• Do not allow broad access to localhost, private IP ranges, metadata services, or internal dashboards.
• Keep browser automation separated from privileged administrative sessions.
• Review any workflow that combines external web browsing with internal system access.

This is especially important for agents that perform web research, scrape pages, process user-submitted links, or automate browser sessions against multiple websites.

Secure Messaging Channels and Group Access

If OpenClaw is connected to chat platforms, messaging channels, or team workspaces, harden who can talk to the agent and when the agent should respond.

Recommended practices:

• Use pairing or allowlists for direct messages.
• Require explicit mentions in group chats.
• Do not allow every workspace member to trigger tool-enabled actions by default.
• Use separate bot accounts for personal and business workflows.
• Use separate agents for different teams or trust levels.
• Do not connect a shared team agent to personal accounts or browser profiles.
• Review chat logs for unexpected commands or repeated failed attempts.

Group chats are especially risky because prompt injection, accidental mentions, or malicious users can steer a shared tool-enabled agent. If a shared agent has access to files, shell commands, browser sessions, or business APIs, restrict who can trigger it.

Review Plugins, Skills, and Third-Party Integrations

OpenClaw integrations can extend what agents are able to do. That makes third-party plugins, skills, tools, and community packages part of your security boundary.

Before installing a plugin or skill, review:

• Who maintains it.
• What permissions it requests.
• Whether it can execute code.
• Whether it can read or write files.
• Whether it can access secrets or tokens.
• Whether it connects to external services.
• Whether the source code is available for review.
• Whether it is actively maintained.

Do not install plugins or skills just because they are convenient. Install only what you need, remove what you do not use, and keep integrations updated.

Protect Logs and Transcripts

Logs and transcripts can contain sensitive information even when the main application is configured correctly. Agent conversations may include pasted secrets, file contents, internal URLs, API responses, command output, customer data, or operational details.

Recommended log hardening practices:

• Keep sensitive-data redaction enabled.
• Add custom redaction patterns for your environment.
• Avoid sharing raw logs publicly.
• Use redacted diagnostic commands when asking for support.
• Prune old transcripts and logs if long retention is not required.
• Restrict file permissions on logs and transcript directories.
• Back up only the logs you actually need.

When sharing troubleshooting information with support or a vendor, review it for tokens, URLs, hostnames, customer data, and private file paths first.

Back Up State and Workspace Files

In a VPS deployment, the server may own the OpenClaw state and workspace. If the VPS is deleted, corrupted, compromised, or misconfigured, you may lose agent state, configuration, logs, and files.

Back up:

• OpenClaw state directories.
• Workspace directories.
• Configuration files.
• Credential references and secret files, if appropriate.
• Docker Compose files and deployment scripts.
• Important logs and audit records.

Security matters for backups too. Store backups in a protected location, restrict access, and encrypt them when possible. If a backup contains tokens, API keys, browser state, or private files, treat it as sensitive production data.

Use DDoS Protection for Availability

DDoS protection does not replace application security, authentication, firewall rules, or gateway hardening. However, it can help preserve availability for public-facing infrastructure and remote-access services.

If your OpenClaw VPS supports business workflows, customer-facing automation, or remote team access, choose a VPS provider with strong network reliability and DDoS mitigation options. This helps reduce downtime from network-layer attacks while you continue to secure the application layer separately.

Psychz cVirtual is a good fit for OpenClaw users who want an always-on VPS with NVMe storage, unmetered bandwidth, DDoS protection options, Linux control, and global data center choices.

Recommended OpenClaw VPS Hardening Baseline

For most OpenClaw VPS deployments, use the following baseline:

Basic Incident Response Plan

If you suspect that your OpenClaw VPS, Gateway, token, agent, or integration has been compromised, act quickly. Do not assume the issue is limited to one chat or one command.

1. Contain

• Stop the OpenClaw Gateway if needed.
• Block public access to exposed ports.
• Disable affected integrations.
• Revoke suspicious device pairings.
• Disconnect high-risk browser sessions.
• Preserve logs before deleting or rebuilding anything.

2. Rotate Secrets

• Rotate gateway tokens.
• Rotate model provider API keys.
• Rotate bot tokens for messaging channels.
• Rotate OAuth credentials where applicable.
• Rotate any credentials that appeared in logs, transcripts, or workspace files.

3. Audit

• Review OpenClaw logs and transcripts.
• Check recent device registrations.
• Review shell history and system logs.
• Check for unexpected files, tools, plugins, or configuration changes.
• Run OpenClaw security audit.
• Review firewall rules and exposed ports.

4. Rebuild if Needed

If host compromise is likely, rebuild the VPS from a clean image instead of trying to repair it in place. Restore only trusted configuration and workspace data. Rotate secrets before bringing the deployment back online.

Why Host OpenClaw on a Hardened VPS?

A VPS gives OpenClaw a persistent, isolated environment that can stay online even when your laptop is off. It also gives you more control over firewall rules, backups, operating system updates, storage, and network access.

Running OpenClaw on a VPS is especially useful when you need:

• 24/7 agent availability.
• Persistent state and workspace storage.
• Remote access from multiple devices.
• Better separation from your personal laptop.
• Dedicated browser or automation profiles.
• Controlled firewall and private network access.
• Reliable backups and recovery options.

For users who want an always-on OpenClaw environment, Psychz cVirtual provides NVMe storage, unmetered bandwidth, DDoS protection options, Linux control, and global data center locations. Start with a VPS sized for your OpenClaw workload, then scale CPU, RAM, and storage as your agents and automation workflows grow.

OpenClaw Security FAQ

Is OpenClaw safe to expose to the public internet?

In most cases, no. The safer approach is to keep the OpenClaw Gateway private and access it through SSH tunneling, Tailscale, WireGuard, or a VPN. If you expose any OpenClaw service beyond loopback, require strong authentication and restrict access with firewall rules.

What is the safest way to access OpenClaw on a VPS?

The safest common approach is to keep the Gateway bound to loopback and access it through an SSH tunnel or private network. This avoids placing the Gateway directly on the public internet.

Should I use a password or token for OpenClaw Gateway authentication?

A long random token is preferable to a short human-created password. Human-created passwords are easier to guess, reuse, or leak. If a password is used, it should be long, unique, random, and stored securely.

Does sandboxing make OpenClaw completely safe?

No. Sandboxing reduces risk, but it is not a perfect security boundary. It is still important to restrict tools, protect secrets, update software, review plugins, and avoid exposing the Gateway publicly.

Should I run OpenClaw as root?

No, not for normal deployments. Run OpenClaw under a dedicated Linux user whenever possible. This helps limit the impact of mistakes, misconfigurations, or compromised agent workflows.

Can multiple users share one OpenClaw Gateway?

Only if they are in the same trust boundary. If users are mutually untrusted, belong to different customers, or should not share the same credentials and tool permissions, use separate Gateways, OS users, or VPS instances.

How often should I run an OpenClaw security audit?

Run a security audit after installation, after changing configuration, after enabling new integrations, after exposing any network surface, and as part of regular maintenance.

What should I back up for OpenClaw?

Back up OpenClaw state, workspace files, configuration files, deployment scripts, and any important logs. Protect backups because they may contain sensitive data, tokens, transcripts, and private files.

Is DDoS protection enough to secure OpenClaw?

No. DDoS protection helps with network availability, but it does not replace gateway authentication, private access, firewall rules, software updates, sandboxing, or credential protection.

What is the most important OpenClaw security rule?

Do not expose powerful agent control surfaces unnecessarily. Keep the Gateway private, use strong authentication, restrict tools, and separate trust boundaries.

Final Recommendation

The best OpenClaw security posture is private by default. Keep the Gateway on loopback or a private network, require strong authentication, use SSH tunneling or VPN access, enable firewall rules, run OpenClaw under a dedicated user, restrict tools, enable sandboxing where possible, and protect logs, secrets, browser profiles, and backups.

OpenClaw can be a useful always-on AI agent platform, but it should be deployed like a privileged automation system. Treat the VPS, Gateway, workspace, credentials, browser sessions, and integrations as sensitive infrastructure. Start with the smallest access that works, then expand permissions only when there is a clear operational need.