OpenClaw security: Risks and best practices

OpenClaw needs stricter security than a typical chatbot because it can run commands, access files, send emails, call APIs, and act across connected systems. Misconfigurations can affect your server, data, and external services.

OpenClaw security depends on where and how it runs. Self-hosting on a VPS gives you more control, but you’re responsible for server hardening, updates, secrets, access, backups, and monitoring.

Managed OpenClaw reduces that infrastructure security work, but it doesn’t remove every risk. You still need to manage connected apps, permissions, prompts, external inputs, and approval rules.

Does hosting impact OpenClaw security?

Yes, hosting does impact OpenClaw security because it changes who is responsible for the environment where the AI agent runs. OpenClaw security depends on more than the application itself. The server setup, network exposure, firewall rules, update process, backup routine, access controls, logging, monitoring, and secret storage all affect how much risk the agent introduces.

The same OpenClaw setup can be safer or riskier depending on how it is deployed. An OpenClaw instance running on a weak VPS with exposed ports, root-level permissions, and no monitoring creates more risk than one isolated in Docker, restricted by firewall rules, and accessible only through private networking. A managed OpenClaw platform can reduce the amount of infrastructure security work because the provider handles more of the hosting environment, maintenance, and recovery setup.

However, managed hosting does not make OpenClaw automatically secure. It mainly shifts part of the security workload away from server administration. Users still need to control what apps OpenClaw connects to, what permissions it receives, how prompts are handled, and which actions require human approval.

Is managed OpenClaw hosting more secure than setting it up yourself?

Managed OpenClaw can be safer for beginners and non-technical users because the hosting provider handles more of the infrastructure setup. This reduces common mistakes around Docker configuration, exposed ports, recovery tools, server permissions, and other server-level security settings.

Self-hosted OpenClaw can also be secure, but a manual OpenClaw setup requires more technical responsibility. Users need to understand VPS hardening, SSH access, firewall rules, Docker isolation, updates, backups, and monitoring. A self-hosted setup gives more control over the environment, but that control also means the user is responsible for securing every layer of it.

Managed hosting changes that trade off. It reduces server administration work, but it usually provides less full-root control than a manual VPS setup. This choice also affects OpenClaw costs, since self-hosting may require more setup and maintenance time, while managed hosting shifts more infrastructure work to the provider. Users who need deeper customization can use CLI access, where available, or move to a VPS setup when they need full control over the server environment.

Managed OpenClaw does not remove every security risk. Users still control automations, connected accounts, prompts, external inputs, and high-risk actions. For example, an over-permissioned email integration or a bot exposed to public messages can still create risk, even when the hosting environment is managed.

Self-hosted vs managed OpenClaw security responsibilities

Self-hosted OpenClaw requires the user to handle most security responsibilities, while managed OpenClaw shifts more of the infrastructure security to the provider, but still requires the user to manage app permissions and automation risks.

The main trade-off is control versus workload. Self-hosting gives users more control over the OpenClaw environment, but it also makes them responsible for securing that environment. Managed hosting reduces server-level security work, but it does not replace safe automation rules, limited permissions, and human approval for sensitive actions.

What managed OpenClaw hosting does not solve

Managed OpenClaw hosting helps with infrastructure security, but it does not remove every AI-agent risk. The hosting provider can reduce server-level work, but users still control what OpenClaw connects to, what inputs it receives, and which actions it can take.

Managed hosting does not automatically prevent prompt injection from websites, emails, chat messages, or other external content. It also does not make risky automations safe by default. If OpenClaw can send emails, edit files, make purchases, trigger refunds, change production systems, or call sensitive APIs, those actions still need clear limits and approval rules.

The same applies to integrations. Over-permissioned Gmail, Slack, Telegram, Discord, file storage, or API connections can create risk in both managed and self-hosted setups. Public chatbots and open channels also need extra care because unknown users may send instructions that try to manipulate the agent.

For this reason, managed OpenClaw users should still follow the checklist sections on human approval, external messages, chat integrations, logging, and low-risk automations. These controls help limit what the agent can do, show what it already did, and reduce the chance that one unsafe prompt or integration causes wider damage.

What sparked the OpenClaw security discourse

Proof-of-concept demos showed that malicious websites could embed hidden instructions in pages OpenClaw was asked to summarize, leading the agent to exfiltrate data or modify system files. This is what researchers have identified as prompt injection attacks.

Configuration issues amplified these risks. Some users exposed OpenClaw gateways to the public internet using default settings, inadvertently leaking API keys, OAuth tokens, and private chat histories. Researchers later confirmed that plaintext credentials were exposed through misconfigured endpoints and prompt-injection vectors.

Commodity infostealers such as RedLine, Lumma, and Vidar also began targeting OpenClaw installations – often before security teams even knew the software was running.

Because credentials and conversation context were stored in plaintext, attackers could steal not only access keys but also full records of workflows and user behavior, a phenomenon analysts described as cognitive context theft.

Together, these incidents highlighted a central reality: the risk is largely a function of deployment. An agent running with root permissions, public internet exposure, unrestricted command execution, and no human oversight presents a different security posture than one running as a restricted user, behind a VPN, with command allowlists and approval workflows.

This distinction matters because AI agents operate differently from traditional software. They run continuously, ingest natural language from multiple sources, and autonomously decide which tools to invoke. While a misconfigured web server may leak data, a misconfigured AI agent can delete databases, send fraudulent emails, or leak credentials within seconds.

Many OpenClaw incidents are not just “OpenClaw problems”; they are deployment, permissions, and exposure problems, which is why hosting choice directly affects the agent’s overall security posture.

What can OpenClaw access?

OpenClaw can access any connected system you give it permission to use, so its security risk depends on both the hosting environment and the sensitivity of these integrations:

• Email (IMAP, SMTP, Gmail, Outlook APIs). OpenClaw can read inboxes, process attachments, manage folders, and send emails. If compromised, an attacker could exfiltrate sensitive correspondence or send convincing phishing emails directly from your account.
• Team communication tools (Slack, Discord, WhatsApp, Telegram). These platforms rely on long-lived access tokens with broad permissions. A compromised agent could monitor private conversations, impersonate users, or send messages to mislead teams or conceal malicious activity.
• Calendars and scheduling systems. OpenClaw can create meetings, send invites, and analyze availability. While this seems benign, calendar data can be used to schedule fake meetings for phishing or to map team structures and working patterns.
• Browser automation. OpenClaw can navigate websites, fill forms, click buttons, and extract data. If you’ve configured it to access internal dashboards or financial accounts, session cookies and credentials become part of the attack surface.
• File system access. Depending on permissions, OpenClaw may read configuration files, access documents, and write data to disk. Running the agent with elevated privileges expands this access to system files and other users’ data.
• System command execution. This is where the power of automation meets the risk of security. OpenClaw can run shell commands, install software, modify services, and execute scripts. With unrestricted command execution, a single compromised input can cascade into full system control.
• External APIs. API keys extend OpenClaw’s reach to cloud infrastructure platforms, payment processors, and internal productivity tools. Each integration grants not just data access but also the ability to take actions.

OpenClaw acts as a bridge between systems, so if one entry point is compromised, such as a malicious email or web page, an attacker can move laterally through everything the agent is allowed to access. This is why each new system integration increases the agent’s blast radius.

For instance, if you configure an OpenClaw agent for customer support, you could give it access to email (to read requests), a database (to look up customer details), a payment processor (to issue refunds), and Slack (to notify the team).

A single prompt-injection attack in a support email could chain these permissions together – querying customer records, issuing fraudulent refunds, and posting misleading messages to Slack to mask the activity.

Managed hosting does not change the sensitivity of connected apps. If OpenClaw can access Gmail, Slack, files, APIs, or other external systems, those permissions still need to be limited based on what the agent actually needs to do.

The biggest OpenClaw security risks

Most OpenClaw security incidents fall into a few repeatable categories. In almost every case, the issue isn’t a flaw in the agent itself, but how it’s deployed, exposed, and permissioned.

These risks are most common in self-hosted setups, but some still apply to managed OpenClaw when users connect external apps, grant broad permissions, or allow high-risk actions without approval.

Weak VPS hardening

Many OpenClaw installations run on virtual private server (VPS) instances with default security settings: SSH exposed on port 22 with password authentication enabled, minimal firewall rules, delayed security updates, and services running with excessive privileges.

When OpenClaw runs on top of this weak foundation, any initial compromise becomes dangerous. An attacker who gains access through an unrelated vulnerability suddenly has an AI agent with broad system access that can automate reconnaissance, persistence, and lateral movement, which can accelerate the attack dramatically.

Exposed ports and services

OpenClaw’s gateway runs on port 18789 by default, with the Canvas host on port 18793. When these ports are exposed to the public internet, they become discoverable through routine port scanning.

Attackers actively probe VPS IP ranges for open services, and an unauthenticated or weakly protected OpenClaw instance is an easy target. If OpenClaw shares a server with other services, a single exposed endpoint can lead to broader compromise, such as leaking database credentials, SSH keys, or API tokens stored elsewhere on the system.

Using public gateways instead of private networking

For convenience, some users expose OpenClaw through public URLs, webhooks, or chatbots without strong authentication, rate limiting, or input validation. A public Telegram bot or email forwarding rule can unintentionally become a remote command interface.

No sandboxing or isolation

When OpenClaw runs directly on the host operating system, it inherits all the user account’s permissions. There’s no file system isolation, no network restrictions, and no resource limits to contain damage. Without sandboxing, a single compromised command runs with full user privileges.

Overly permissive skills and command execution

Granting OpenClaw unrestricted command execution is equivalent to giving every untrusted input root-level influence.

Many users enable broad permissions during testing and never tighten them later. This allows the agent to delete files, install software, modify services, or execute arbitrary code simply because nothing prevents it.

Unsafe secret storage

OpenClaw relies on API keys and credentials to interact with external systems, but storing these secrets in plaintext configuration files makes them trivial to steal once file access is gained.

Even environment variables can expose secrets to other processes running under the same user.

Prompt injection with tool execution

A successful injection can trigger file deletion, data exfiltration, or system changes through embedded instructions in emails, web pages, or chat messages.

This risk grows as OpenClaw processes untrusted inputs autonomously – summarizing unknown websites, reading emails from external senders, or monitoring public channels. Each input becomes a potential execution vector with real-world consequences.

OpenClaw security checklist for self-hosted setups

OpenClaw security issues are preventable with better configuration, a careful rollout, and basic OpenClaw best practices, such as limiting access, isolating the agent, and expanding permissions gradually. As OpenClaw’s development is still in its early stages, we can also expect ongoing improvements as the project matures.

That said, at the time of writing, there’s no standardized framework that guarantees the safe operation of AI agents. And as OpenClaw is self-hosted, you’re fully responsible for its security posture.

For that reason, before deploying OpenClaw and securing it, make sure you’re comfortable with server-level configuration, understand Linux security fundamentals, and know how to work with the command line, firewall rules, and system troubleshooting.

The exact steps will vary depending on whether you run it on a VPS, a local machine, or a private server, but the principles below focus on securing OpenClaw in a VPS environment, where misconfiguration tends to have the biggest impact.

1. Keep OpenClaw private by default

The safest OpenClaw setup is one that isn’t reachable from the public internet. So, avoid exposing dashboards, APIs, or agent endpoints unless there’s a clear and justified need.

Start with private access only. Configure OpenClaw to listen on 127.0.0.1 instead of 0.0.0.0, so it’s accessible only from the server itself.

For remote access, use an SSH tunnel: connect with ssh -L 8080:localhost:8080 user@your-vps.com, then access OpenClaw at http://localhost:8080 on your local browser.

Alternatively, VPN solutions create secure private networks that let you access OpenClaw without exposing yourself to the public internet.

As an extra layer of protection, block OpenClaw’s ports at the firewall level using Uncomplicated Firewall (UFW). Even if something is misconfigured later, firewall rules help ensure the service isn’t accidentally exposed. OpenClaw typically uses port 18789 for the gateway.

If it’s highly necessary to make your OpenClaw publicly accessible, put it behind strong authentication, rate limiting, and a reverse proxy such as NGINX. The proxy validates requests before they reach OpenClaw, adding inspection and filtering that the agent itself doesn’t provide.

2. Check open ports and close everything you don’t need

One of the fastest security wins is auditing which ports are exposed and closing anything OpenClaw doesn’t actively use.

Run sudo ss -tlnp or sudo netstat -tlnp on your VPS to see which services are listening and on which ports.

Look for unexpected entries, such as old development servers, database ports (3306, 5432), or services you enabled once and forgot about.

Close unnecessary ports, and for services that need to run but don’t need external access, bind them to localhost only (127.0.0.1) instead of all interfaces (0.0.0.0). This makes them accessible to applications on the same server but invisible to external scans.

Also, consider changing your default SSH port to a less common one. This can reduce the noise from automated scans and brute-force attempts.

Real protection comes from firewall rules that explicitly allow only what’s needed and block everything else. Changing ports can cut down bot noise, but it’s not a substitute for proper security controls.

3. Harden SSH access before you do anything else

SSH is the foundation of VPS security, and one of the most common paths attackers use to gain access. Before securing OpenClaw itself, make sure your server access is properly locked down.

First, make sure you use only trusted SSH tools like PuTTY when accessing your server. Reputable clients reduce the risk of credential leaks and man-in-the-middle attacks.

Then switch to SSH keys for logging in, and disable password authentication entirely. This eliminates brute-force password attacks completely.

Restrict which users or IP addresses can connect, if possible. For users with static IPs, configure your firewall to accept SSH only from those addresses. This prevents attackers from even attempting connections.

4. Never run OpenClaw as root

Running OpenClaw as root means any mistake or exploit gives attackers complete system control. A misconfigured command or successful prompt injection becomes catastrophic when the agent operates with the highest privilege level.

Create a dedicated Linux user specifically for OpenClaw, run all OpenClaw processes as this user, store configuration in this user’s home directory, and grant only the minimum permissions needed for OpenClaw to function.

This containment limits damage. If OpenClaw is compromised, the attacker can only affect what the OpenClaw user can access. Recovery becomes simpler because you know the scope of potential modifications.

5. Restrict what OpenClaw can do with an allowlist

Without limits, OpenClaw can execute anything it’s asked to – intentionally or not. Command allowlisting flips the security model from “block specific dangerous things” to “permit only approved actions.”

Start with read-only Linux commands like ls, cat, df, ps, or top. These let OpenClaw gather information without modifying anything. Add write permissions carefully by allowing file creation in specific directories, not in system paths or configuration folders.

Never grant unrestricted access to package managers, system modification tools, or destruction commands. Use Linux permissions, AppArmor, or restricted shell configurations to enforce these limits technically, not just through agent behavior.

Each new capability you give to OpenClaw should be a deliberate decision, not an accident. Adjust Linux permissions and expand them gradually as you confirm safe operation.

6. Require human approval for high-risk actions

Human-in-the-loop approval means OpenClaw proposes actions but waits for your explicit confirmation before executing anything with significant impact. Always configure approval requirements on your OpenClaw instance for critical actions, including:

• Sending emails or messages to external recipients
• Deleting or modifying files
• Making purchases, refunds, or financial transactions  
• Deploying code or changing production systems
• Running shell commands with write access
• Accessing or exfiltrating sensitive data

You can manage OpenClaw’s approval settings in the gateway configuration and in the Mac system settings for exec approvals. However, these protections have an important limitation: the approval system can be modified via API access if the gateway is compromised.

This means, as explained in the previous steps, strong gateway security is highly critical to maintaining your approval workflows.

7. Store API keys and tokens safely

OpenClaw needs credentials to access email, messaging platforms, cloud APIs, and AI providers. Storing these secrets in plaintext configuration files makes them easy to steal, as anyone with file access can recover your entire integration stack.

Instead, store API keys as environment variables so they’re never written to config files or version control systems. Set them in your shell environment or systemd service file, and OpenClaw will read them at startup without ever saving them to disk.

For stronger protection, use a secret manager like AWS Secrets Manager or an encrypted vault that injects credentials at runtime. These tools provide short-lived tokens that rotate automatically, limiting the window of opportunity if a credential leaks.

Additionally, rotate your API keys regularly, or do so immediately if you suspect compromise. Make rotation straightforward by using secret management rather than hunting through multiple config files.

Never commit API keys to version control, and ensure credential files have restrictive permissions (chmod 600) and are readable only by the user you set up for OpenClaw.

8. Isolate OpenClaw with Docker or a sandbox

Instead of running OpenClaw directly on your host system, use Docker or another sandboxing approach to create boundaries.

A Docker container runs OpenClaw in an isolated environment with its own filesystem, restricted network access, and CPU and memory resource limits. The container can’t see your host system’s files, access other processes, or make arbitrary network connections. This isolation limits the blast radius in case something goes wrong.

Mount only the specific directories OpenClaw needs and leave everything else inaccessible. Use minimal base images, run as a non-root user inside the container, and configure explicit network rules for which external services the container can reach.

Even if an attacker fully compromises the OpenClaw process, they’re contained within the Docker environment with no direct path to your host system, other services, or sensitive files outside the mounted volumes. The container becomes your security boundary.

9. Be careful with browser automation and external messages

Prompt injection risk increases sharply when OpenClaw processes untrusted content. When the agent visits websites to extract information, those pages can embed hidden instructions designed to influence its behavior.

The same risk applies to emails and chat messages from unknown senders. An attacker might include concealed text, such as white-on-white instructions, knowing you’ve asked OpenClaw to summarize your inbox or messages.

This risk is higher when using older or less capable language models, which are generally more susceptible to following malicious instructions embedded in otherwise harmless content.

To reduce exposure, limit browser automation to allowlisted domains you control and use read-only browser sessions that can’t access authenticated services. Never allow OpenClaw to browse arbitrary websites while logged into sensitive accounts.

For email and chat processing, use strict source allowlists and assume all external input is potentially hostile. Add human review before OpenClaw takes action based on information extracted from untrusted sources.

➡️ Dive deep into how these risks are also reflected in the emerging AI browsers.

10. Lock down chat integrations and bot access

Restrict command acceptance to specific user IDs. On Telegram, verify the sender’s user ID before processing any command. On Discord, check both server ID and user roles.

Never let your OpenClaw bot join public servers or channels where strangers can send it messages.

Use private channels and servers rather than public ones. Enable multi-factor authentication on the accounts OpenClaw uses for chat integrations – if an attacker compromises your Telegram account, MFA adds an extra barrier to authenticated sessions.

Configure chat integrations to use short-lived session tokens that expire after hours or days rather than permanent credentials. Regular re-authentication creates natural break points where compromised sessions stop working.

Also, review bot permissions carefully: does it need to delete messages and manage users, or just send and receive in private chats? Minimal permissions reduce damage if bot tokens leak.

11. Turn on logging so you can audit actions

Configure OpenClaw to log every action with context that enables investigation. At a minimum, log:

• Commands executed and their parameters
• Files accessed or modified
• API calls and integrations triggered
• Who or what requested each action (user, automated schedule, external message)
• Success or failure status

Use structured logging (JSON format) rather than unstructured text. Structured logs make it easy to search and filter. Queries like “Show me all file deletions in the last 24 hours,” or “Which APIs were called from external email triggers?” become trivial with proper formatting.

On Linux systems, system-level logs can be reviewed using the journalctl command, which makes it easier to audit OpenClaw’s activity, trace failures, and investigate suspicious behavior over time. Consider forwarding logs to a separate system or append-only storage so attackers who compromise OpenClaw can’t delete evidence.

Review logs weekly to build a baseline understanding of normal behavior. This makes anomalies obvious when they appear.

12. Update OpenClaw and dependencies safely

Staying up to date reduces exposure to known issues, but updates should be deliberate, not rushed. OpenClaw is a young, rapidly evolving software, so it updates frequently and adds security improvements as the community discovers and patches vulnerabilities.

Follow a simple routine: create a VPS snapshot first, update one component at a time, test that core workflows still function, and keep the snapshot for 24-48 hours in case subtle issues appear. This keeps security improvements from becoming availability problems.

Monitor the OpenClaw GitHub repository for security releases and patch announcements. When vulnerabilities become public, attackers develop exploits quickly – delayed patching leaves you exposed during the window between disclosure and your update.

Additionally, the Python packages, Node modules, or system libraries OpenClaw uses also have vulnerabilities. Tools like pip-audit for Python or npm audit for Node identify outdated packages with known security issues.

13. Start with low-risk automations and expand slowly

The safest way to deploy OpenClaw is to treat it like production software, even for personal use.

Start with read-only reporting: daily email summaries, weather and calendar briefings, aggregated news from RSS feeds. These operations consume data and generate text but don’t modify systems or trigger external actions. Run these for days or weeks to validate stability.

Next, add low-stakes write operations: saving generated reports to specific directories, posting summaries to private chat channels, and creating calendar events. These have consequences but a limited scope. Mistakes mean cleaning up files or deleting spurious calendar entries.

Only after demonstrating reliable operation should you enable higher-risk capabilities, such as sending emails to external addresses, executing system commands that modify configuration, browser automation with logged-in accounts, or managing production infrastructure.

Then, make sure each expansion includes conscious evaluation.

OpenClaw security checklist for managed hosting

Managed OpenClaw hosting reduces server-level security work, but users still need to secure the parts they control: account access, connected apps, automation permissions, external inputs, logs, and high-risk actions.

1. Protect your Hostinger account

Use a strong, unique password for your Hostinger account and enable two-factor authentication (2FA) or multi-factor authentication (MFA). Avoid sharing account access unless another user truly needs it. If you work with a team, give each person the lowest access level they need instead of sharing one account.

2. Limit connected app permissions

Only connect the apps OpenClaw needs for the workflows you plan to run. Avoid broad Gmail, Slack, Telegram, Discord, file system, or API permissions unless the automation requires them. Review connected app permissions regularly and remove access that is no longer needed.

3. Keep high-risk actions behind approval

Require human approval before OpenClaw performs actions that can affect users, money, files, or production systems. This includes sending emails, deleting or editing files, running commands, making payments or refunds, and changing live services. Approval rules keep automation useful without giving the agent unrestricted control.

4. Treat external messages as untrusted input

Emails, websites, chat messages, and public channels can contain prompt-injection instructions. Treat these inputs as untrusted, especially if OpenClaw can summarize, respond to, or act on them. Use allowlists where possible, and don’t let unknown users command the bot directly.

5. Review logs and agent activity

Check what OpenClaw did, not just whether the automation worked. Review logs for unexpected tool calls, external messages, file changes, API actions, or repeated failed tasks. Logs help you catch risky behavior before it becomes a larger security issue.

6. Start with low-risk automations

Start with read-only or reversible automations such as summaries, briefings, reminders, and reports. Add write actions only after you trust the setup, understand the permissions, and have approval rules in place for sensitive tasks.

What should you automate first with OpenClaw?

When you’re getting started with OpenClaw, the safest approach is to start with automations that are useful but low-risk. These help you understand how the agent behaves without giving it deep system access or irreversible powers.

Make your first OpenClaw automations read-only, reversible, and easy to audit, including:

• Daily or weekly briefings. Have OpenClaw summarize news sources, documentation updates, or internal notes and send you a short report. This requires minimal permissions and no system changes.
• Inbox or message summaries. Let OpenClaw summarize emails or messages you receive, rather than replying or taking action. This keeps the agent in an “observe-only” role while you evaluate its accuracy.
• Scheduled reports. Generate periodic summaries from logs, dashboards, or databases without allowing OpenClaw to modify anything. Reporting builds confidence without expanding the blast radius.
• Reminders and task tracking. Use OpenClaw to create reminders or compile task lists from your notes or chats, without granting file deletion, command execution, or external write access.

These are the safest first workflows for both self-hosted and managed OpenClaw users because they let you test the agent’s behavior before permitting it to change files, send messages, or trigger actions in connected systems.

Treat every new automation as an experiment. Run OpenClaw in a sandboxed or isolated environment, connect only the integrations you need, and avoid combining multiple systems at once.

After each change, review the logs to see exactly what actions were taken, which tools were invoked, and whether anything unexpected happened. If something feels unclear, roll back and simplify before adding more capabilities.

The author

Larassatti D.

Larassatti Dharma is a content writer with 4+ years of experience in the web hosting industry. She has populated the internet with over 100 YouTube scripts and articles around web hosting, digital marketing, and email marketing. When she's not writing, Laras enjoys solo traveling around the globe or trying new recipes in her kitchen. Follow her on LinkedIn

More from Larassatti D.