4
CourseMolt 1Chapter 4
Molt 1: The Hatchling
10 min read

Secure Your Setup

Lock down your OpenClaw instance before it becomes someone else's. Sandbox mode, token scoping, tool restrictions, and the security audit.

4 of 10

Don't Be One of the 954

Warning

Right now, 954 OpenClaw instances are exposed on Shodan with open gateway ports and zero authentication. That's 954 people who just handed their entire digital life to the internet.

You just got Telegram working. Your lobster is alive and chatting. It feels great. But before you move on, we need to have the talk.

This chapter takes 10 minutes. Skip it and you might become a cautionary tale.

Understand What You're Actually Running

OpenClaw isn't ChatGPT in a browser tab. It's not a toy you close when you're done.

It's a 24/7 agent with access to your shell, your files, your browser, and every service you've connected to it. It runs while you sleep. It runs while you're at work. And anyone who can message it can potentially trigger those capabilities.

That Telegram bot you just set up? If the wrong person gets access, they're one clever prompt away from:

  • Reading your files
  • Running commands on your machine
  • Accessing any service you've connected

This isn't fear-mongering — it's just how agents work. The good news? Locking it down is straightforward.

Enable Sandbox Mode

Sandbox mode runs every OpenClaw session inside a Docker container instead of directly on your machine. If something goes wrong, the damage stays inside the container. Your real files, your real system — untouched.

Open your config:

nano ~/.openclaw/openclaw.json

Find the agents section and add the sandbox config inside agents.default:

{
  "agents": {
    "default": {
      "sandbox": {
        "mode": "all",
        "scope": "session",
        "workspaceAccess": "none"
      }
    }
  }
}

This tells OpenClaw: every session gets its own container, no access to the host workspace.

Tip

You'll need Docker installed for sandbox mode to work. If you don't have it yet, grab it from docker.com. Check the OpenClaw docs for the sandbox setup script if you run into issues.

Run the Security Audit

OpenClaw has a built-in security audit that checks for common misconfigurations. Run it:

openclaw security audit

If it finds issues, you can auto-fix the easy ones:

openclaw security audit --fix

This tightens permissions on your credentials, session directories, and config files.

Tip

Get in the habit of running openclaw security audit after any config change. It catches things you'll forget about.

Scope Your API Tokens

This is the mistake 99% of beginners make. When connecting services like GitHub or Google, people give OpenClaw the keys to the whole kingdom.

Don't do that.

  • GitHub: Don't give full repo access. Use public_repo or scope to specific repos
  • Google: Don't give full account access. If you just need calendar, only grant calendar permissions
  • Everything else: Use readonly wherever possible

Why does this matter? If your agent ever gets manipulated — through a prompt injection, a malicious skill, or just a misunderstanding — it can only do what the token allows. A readonly GitHub token can't delete your repos. A calendar-only Google token can't read your emails.

Minimum permissions, maximum safety.

Restrict Tool Access

By default, OpenClaw has access to a lot: file read/write, shell execution, browser control, and more. You don't have to leave it that way.

Think about what you actually need your agent to do, and lock down the rest:

  • Maybe you allow file reading and web search but block shell execution entirely
  • Maybe you allow everything except browser control
  • Maybe you're strict about everything until you trust a specific skill

Sandbox limits the blast radius if something goes wrong. Tool restrictions limit what can happen in the first place. Use both.

Check the OpenClaw docs for the full tool policy config — it uses an allowlist/denylist approach in your openclaw.json.

Keep It Private

This one's simple but people get it wrong all the time:

Warning

Never add your personal OpenClaw bot to a group chat. Every person in that chat effectively has shell access to your server. Treat your OpenClaw bot like a terminal window — only people you trust should be able to talk to it.

Remember the allowedUsers list in your Telegram config? That's your first line of defense. Only user IDs in that list get responses. Keep it tight.

If you need group functionality down the road, use strict allowlists so only approved users can interact. We'll cover that in a later molt.

Restart Your Gateway

None of these security settings apply until you restart:

openclaw gateway restart

Verify it's running with the new config:

openclaw gateway status

Before You Move On

Run through this checklist before proceeding to Molt 2:

  • [ ] Sandbox mode enabled
  • [ ] Security audit passing
  • [ ] API tokens scoped to minimum permissions
  • [ ] Tool restrictions configured (if applicable)
  • [ ] Private access only (no group chats)
  • [ ] Gateway restarted after changes

Takes 10 minutes to set up properly. Saves you from being one of the 954 exposed instances on Shodan. Don't be lazy about this one.

In the next chapter, we'll build a security agent that handles all of this for you — running audits, checking configs, and sending you updates when something needs attention. Because the best security is the kind that doesn't rely on you remembering to do it.

Challenge

Run openclaw security audit after applying the security settings from this chapter. Screenshot the output showing all checks passed — that's your proof you've completed Molt 1 with a properly secured setup.