ClawHosters
by Daniel Samer
5 min read
Your OpenClaw instance ships with almost zero ai agent security turned on. The gateway binds to loopback, which is good. But the tool access model? Wide open. Your agent can run any shell command, read any file your OS user can reach, and accept messages from anyone who finds your Telegram bot.
According to CrowdStrike's February 2026 advisory, over 135,000 OpenClaw instances are exposed across 82 countries. 12,812 of those were exploitable via remote code execution. And Permiso Security documented a fake weather skill on ClawHub that silently exfiltrated API keys to an attacker-controlled webhook. This isn't theoretical.
The fix takes about 60 seconds. OpenClaw has three permission layers, and once you understand them, the config is a single JSON file.
What ClawHosters Already Handles
If you're running on ClawHosters, infrastructure security is done. Container isolation, firewall rules, SSH hardening, brute force protection, automatic updates. You don't touch any of that.
But the application layer is still yours. Three things need configuring: who messages your bot, which tools it can use, and whether it can run shell commands. That's what this guide covers.
Self-hosting? You've got a longer list. The self-hosting vs managed comparison breaks down the full difference.
Layer 1: Who Can Message Your Bot
The dmPolicy setting controls who gets to talk to your agent. The default is pairing, which requires a one-time verification handshake. Sounds fine. But there's a better option.
Set it to allowlist and specify exact numeric Telegram user IDs in the allowFrom array. This is a hard gate. Nobody gets through unless they're on the list.
One thing that trips people up constantly: allowFrom requires your numeric Telegram user ID, not your @username. If you put @johndoe in there, it gets silently ignored. Your bot just stops responding and you have no idea why. Find your numeric ID by messaging your bot and checking openclaw logs --follow.
Layer 2: Which Tools the Agent Has
Controlling who messages your bot is only half the problem. Even with a locked allowlist, your agent might process content that contains hidden instructions. Palo Alto Networks Unit42 put it simply: agents with read-only access present a much lower threat surface than agents with write permissions.
OpenClaw's tool system has profiles and deny lists. Set the profile to messaging (lighter than the default standard) and explicitly deny the tool groups your agent doesn't need:
group:automationblocks cron jobs and gateway managementgroup:runtimeblocks exec, bash, and process toolsgroup:fsblocks filesystem access outside the workspacesessions_spawnandsessions_sendprevent multi-session attacks
The OWASP AI Agent Security Cheat Sheet recommends scoped tools with explicit allowlists. Same principle here. If your agent's job is answering Telegram messages, it doesn't need to write files or manage cron.
Layer 3: Shell Command Execution
This is the big one. By default, OpenClaw lets the agent run shell commands. That's the exec system.
Set exec.security to deny. Done. If you later need shell access for a specific use case, you can switch to allowlist mode and specify exactly which commands are permitted. The OpenClaw exec documentation covers all three modes.
The ask: "always" setting is belt and suspenders. It means even if you accidentally open up exec, you'll still get prompted before anything runs.
And keep elevated.enabled set to false. Elevated mode gives the agent access to cron management, gateway config, and session spawning. You don't want that.
The Hardened Config
Here's the complete config for ~/.openclaw/openclaw.json. Copy it, replace your Telegram ID, and you're done:
{
"tools": {
"profile": "messaging",
"deny": ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],
"fs": { "workspaceOnly": true },
"exec": { "security": "deny", "ask": "always" },
"elevated": { "enabled": false }
},
"channels": {
"telegram": {
"dmPolicy": "allowlist",
"allowFrom": ["YOUR_NUMERIC_TELEGRAM_ID"]
}
}
}
The OpenClaw security documentation calls this the hardened 60-second baseline. It closes the most common attack vectors without breaking your agent's ability to hold a conversation.
Check Your Work
After applying the config, run:
openclaw security audit
This scans your configuration and flags anything that's still open. If it comes back clean, you're good.
For the full security hardening walkthrough (including the ClawHosters infrastructure layer), check the complete security guide. And if you haven't tried ClawHosters yet, there's a free trial that ships with these security defaults already baked in.
