How to Run OpenClaw Safely (and How to Know You Shouldn't)

Somewhere in OpenClaw's first viral month, "how do I set this up" quietly became "how do I set this up without getting owned." Fair evolution: researchers found tens of thousands of instances exposed on the open internet (opens in new tab), and attackers flooded its skill marketplace with malicious packages (opens in new tab).

Here's the checklist up front, because if you're going to do this, do it right: isolate the machine, lock the gateway, vet every skill, treat your API keys like cash, cap the spend, and patch like it's your job, because it now is. Below is each step in practice, followed by the more useful question, which is whether you should be doing this at all.

The OpenClaw security checklist

1. Isolate it. A dedicated machine, VM, or container, not your daily laptop. An agent that can run shell commands should be running them somewhere where losing everything is an inconvenience, not a catastrophe. Your tax folder and your SSH keys should not share a filesystem with an experiment.
2. Lock the gateway. The control interface must not face the open internet, and it must require authentication. Most of the exposed-instance wave was configuration left open, not exotic exploitation. If you don't know whether yours is exposed, that's an answer too.
3. Vet skills like the supply-chain risk they are. Community skills are code that runs with your agent's permissions. Read them before installing, prefer well-known ones, and treat "new skill, few users, does something with credentials" as the red flag it is.
4. Practice key hygiene. Scoped API keys, stored properly, rotated on a schedule, and never in a config file that a leaked backup or an exposed instance can serve to strangers. A leaked key is someone else's usage on your bill.
5. Cap the spend at the provider. Set hard budget alerts and limits on the API account itself, because the software meters nothing on its own. (Why this matters is its own article.)
6. Patch on someone else's schedule. Security advisories arrive when they arrive; an unpatched agent with shell access ages like milk. Subscribe to releases and treat updates as non-optional.

None of this is exotic. It's the standard operational discipline of running any internet-adjacent service, applied to one with your accounts attached.

The honest test

Read the list again and notice what it assumes: a spare machine, comfort with networking, the habit of reading code before running it, and the ongoing attention of a part-time sysadmin. If that describes you and sounds like fun, genuinely, enjoy it. OpenClaw run by a careful operator is a fine piece of software.

The test is this: if any item on that checklist made you think "I'll figure that out later," you won't, and "later" is exactly when the meter runs and the instance sits open. Skipping steps doesn't make you an operator with a shortcut. It makes you the case study in someone's February write-up.

The alternative is not "no agent"

The reason this checklist exists is that the underlying thing (a persistent agent doing real work while you're away) is genuinely worth having. You just don't have to host it to have it.

On myAgents the checklist is the platform's problem: agents run sandboxed on the platform's infrastructure with no path to any machine you own, each one sees only the accounts you granted it, skills are part of the managed platform rather than a marketplace of strangers' code, and spending is prepaid with a daily ceiling and per-job caps built in. Setup is about two minutes and , no card.