Skipping OpenClaw’s network policy allowlist leaves your credentials exposed to any prompt injection that lands. The fastest way to set it up is ZenClaw — OpenClaw managed service, 9-second deploy, and the dashboard’s network policy panel applies in one click. No JSON, no iptables. This post covers the three preset policies, allowlist JSON examples, and how the self-host and ZenClaw experiences differ.
Why you need a network policy
LLMs get tricked by hidden instructions in messages and web pages. Without an egress allowlist, an agent can exfiltrate ~/.openclaw/credentials/ to an attacker’s server. Prompt injection is the dominant AI agent attack surface for a simple reason: every string the agent sees looks like a “user instruction” to it — whether it came from a web page, a third-party message, or a skill’s output. Egress control is the first line of defense.
OpenClaw’s state lives in ~/.openclaw/ (openclaw.json, sessions, agents, credentials, skills). credentials/ can hold Baileys WhatsApp sessions, LINE tokens, Telegram bot tokens — any single leak means the channel’s identity is hijacked. See Issue #9096 for related session protection discussion.
The three OpenClaw policy presets
OpenClaw abstracts network policy into three options: Open web (everything allowed), Locked down (everything blocked), and Custom (advanced) (allowlist a set of domains) — each matching a different risk tolerance. At a glance:
| Preset | Behavior | When to use |
|---|---|---|
| Open web | Allow all egress | Pure development / personal experiments |
| Locked down | Block everything, only allow what you explicitly add | Finance, healthcare, compliance-sensitive |
| Custom (advanced) | Allowlist a specific set of domains | Standard production |
Most SMBs pick Custom (advanced): write the needed domains explicitly, block everything else. The OpenClaw official docs have JSON schema examples.
Self-host: writing the JSON allowlist
Write a policy JSON, drop it in ~/.openclaw/ at the correct path, and confirm the gateway hot-reloaded it — details per the official docs. First-timers almost always miss at least one required domain. Starter allowlist:
{
"preset": "custom",
"allowlist": [
"api.openai.com",
"api.anthropic.com",
"generativelanguage.googleapis.com",
"api.telegram.org",
"api.line.me",
"graph.microsoft.com",
"github.com",
"ghcr.io",
"raw.githubusercontent.com",
"api.mycompany.com"
]
}What each one is for:
api.openai.com— GPT-4o callsapi.anthropic.com— Claude calls, see Anthropicgenerativelanguage.googleapis.com— Gemini callsapi.telegram.org— Telegram Bot API, see Telegram bot featuresapi.line.me— LINE Messaging APIgraph.microsoft.com— Microsoft Teams webhooksgithub.com/raw.githubusercontent.com— skill installs pull from hereghcr.io— Docker image registry
Top 3 self-host snags:
- Forgot the Docker registry — skill installs and version upgrades get blocked
- Forgot the in-house backend — order, CRM, database webhooks get blocked
- Opening
*.googleapis.comwholesale — unintentionally allows Google APIs you don’t need
The ZenClaw dashboard: one click
ZenClaw puts the three presets in the UI. Custom (advanced) is a visual allowlist editor — no JSON to hand-write, no gateway reload, and blocked requests surface in the UI. Flow:
- Sign in at zenclaw.ai, click “Hire AI Employees Now”
- If you haven’t deployed yet, click “Add New OpenClaw Installation” and wait 9 seconds
- On the instance card, find the network policy panel
- Pick a preset. Under Custom (advanced), fill in the allowlist
- Save — takes effect immediately
What you get:
- No JSON syntax required — UI forms cut down syntax errors
- Real-time feedback — blocked requests display the domain, add it to the allowlist right there
- NVIDIA enterprise sandbox pairing — ZenClaw plans include NemoClaw sandbox (NVIDIA enterprise sandbox runtime), adding a network isolation layer under egress control
- Apply one policy across multiple instances
Defense in depth: policy plus sandbox
A network allowlist is the first layer. If an attacker tampers with openclaw.json, they can escalate. The right approach is policy plus sandbox — two layers. Recommended architecture:
- Network allowlist (this post) — egress layer
- Sandboxed runtime — containers / OpenShell isolate the agent from the host
- Credentials mode 600, never committed to git
- Gateway bound to 127.0.0.1 with firewall blocking port 18789. See OpenClaw security hardening guide
ZenClaw plans ship with all of the above by default. Self-host means auditing each layer yourself. Per blink’s OpenClaw security stats, OpenClaw had accumulated around 138 known CVEs by April 2026 — without a network policy the attack surface is too wide.
Advanced: per-agent policies
Power user move: different agents get different policies. A “CS agent” can only reach Telegram / LINE / CRM APIs; a “marketing agent” can reach social platforms. OpenClaw supports per-agent policy. This matters for real workloads (see e-commerce AI employee playbook).
Self-host means managing multiple JSON files. ZenClaw’s dashboard provides a visual mapping between agents and policies. NemoClaw is NVIDIA’s security-hardened version, announced at GTC on 2026-03-16 as an Alpha early preview (see NVIDIA NemoClaw announcement) — it’s not production-ready yet, so for enterprise environments, pair it with ZenClaw’s managed service.
Wrap-up
The network policy allowlist is OpenClaw’s first line of defense. Self-host means writing JSON, managing reloads, and auditing domains. ZenClaw’s dashboard gets it done in one click. If you don’t want to spend time debugging why an API call was blocked, use ZenClaw — 9-second deploy, network policy panel, one click. The “Hire AI Employees Now” button on the homepage is the starting line.