09 · OpenClaw's Application-Layer Defenses
Source: the
nemoclaw-user-configure-securityskill (openclaw-controls.md).Every other doc in this set has been about the perimeter: the NemoClaw + OpenShell fences around the agent — the container, the network allowlist, the read-only filesystem, the inference routing. This doc is about the other half of the story: what OpenClaw itself does, inside the sandbox, to defend against bad inputs and bad agent behavior. This is the layer NemoClaw doesn't own — it delegates to OpenClaw — and it's the part most beginners don't know exists.
Why this doc matters
The mental model that docs 02–08 give you is: "if a malicious request slips past the YAML policy, everything falls over." That's not quite right. Even if the network layer admits something it shouldn't, there's another set of defenses that run inside OpenClaw: prompt-injection sanitization, a tool deny list, an environment-variable blocklist, rate limiters, and a built-in audit command that walks 50+ checks across your deployment. For a noob, the single most leveraged thing to learn from this whole page is:
openclaw security audit— one command, inside the sandbox, tells you most of what's wrong with your deployment.
Run that first, fix what it flags, and you've graduated from "I installed NemoClaw" to "I know whether my NemoClaw is actually safe."
Prompt injection — what OpenClaw filters before the agent sees it
OpenClaw treats inbound text from untrusted sources (channel DMs, web-fetch results, search results) as hostile by default and applies several normalizations before the Pi agent ever reads it:
| Control | What it does |
|---|---|
| Regex detection | Pattern-matches common injection vectors ("ignore all previous instructions", <system> tag spoofing, and similar) |
| Boundary wrapping | Wraps untrusted input in randomized XML boundary markers so the agent can tell "what the user actually said" from "what the web page tried to make the user say" |
| Unicode folding | Folds homoglyphs (visually-identical Unicode variants) to the canonical ASCII form so ＜system＞ (fullwidth) can't sneak past a check for <system> |
| Invisible character stripping | Removes zero-width characters that would otherwise be invisible to the agent's reader but still affect tokenization |
| Boundary sanitization | Strips fake boundary markers from input so an attacker can't forge their own "end of untrusted input" signal |
| Auto-wrapping of fetched content | browser.open(...) results and search-tool output are automatically wrapped as untrusted external content, regardless of who asked for them |
None of this is configurable from NemoClaw — it's upstream OpenClaw behavior. The relevant knob is "don't turn it off"; if you see references to allowInsecureAuth or dangerouslyDisableDeviceAuth in an OpenClaw config, treat them as red flags.
Tool policy pipeline — what the agent can actually call
OpenClaw gates every tool call through a multi-layer pipeline:
| Control | What it does |
|---|---|
| Deny list (default) | High-risk tools — exec, spawn, shell, fs_write, fs_delete, and others — are blocked from Gateway HTTP by default. They can still be invoked in-process by the local agent but not reached via the Gateway API from a remote client. |
| Policy pipeline | Every tool call is evaluated through: profile → provider → agent → sandbox → per-provider policies. Any one of them can deny. |
| Fail-closed semantics | If any hook errors or times out, the tool call is denied, not permitted. A broken guard is a strict guard. |
| Loop detection | Optional (disabled by default, enable with tools.loopDetection.enabled). Detects and blocks repeated identical tool call patterns — useful against agents that get stuck in loops trying to brute-force something. |
| Plugin approval | Approval workflow defaults to deny on timeout. A plugin that asks for permission and then has its approval request ignored does not get the permission. |
This is why doc 01 mentions /elevated on|off as a per-session exec elevation toggle — elevated bash is one of the tools gated by this pipeline, and you have to explicitly opt a session into it.
Environment variable blocklist
OpenClaw refuses to pass through environment variables that could be used for code injection, privilege escalation, or credential theft, regardless of what you set in your shell.
| Bucket | Examples |
|---|---|
| Always-blocked keys | NODE_OPTIONS, LD_PRELOAD, shell-injection vectors, crypto-mining variables, GIT_* hijacking paths |
| Override-blocked keys | Additional keys blocked unless explicitly overridden |
| Blocked prefixes | GIT_CONFIG_, NPM_CONFIG_, CARGO_REGISTRIES_, TF_VAR_ |
| Universal blocked prefixes | DYLD_, LD_, BASH_FUNC_ |
The takeaway: don't try to "just export something and run openclaw" — if it's on this list, it's silently dropped. Pass anything you genuinely need through NemoClaw's onboarding wizard or an OpenShell provider instead.
Rate limiting and flood protection
The OpenClaw Gateway runs its own auth rate limiting independent of any network-level defenses:
| Control | What it does |
|---|---|
| Auth rate limiter | Sliding-window rate limiter tracks failed authentication attempts per IP and per scope |
| Control plane limiter | Per-device write rate limiting on control-plane operations |
| WebSocket flood guard | Closes connections after repeated unauthorized attempts |
| Pre-auth budget | Limits the number of connections allowed before authentication completes |
You don't configure these; they're on by default. Their existence is why "just port-forward the Gateway to the open internet" is not as catastrophic as it would otherwise be — there's still defense in depth at the application layer. (It's still a bad idea; use Tailscale Serve/Funnel or SSH tunnels as doc 07 describes.)
CLI secret redaction
The openclaw CLI automatically redacts secret patterns — API keys, bearer tokens, provider credentials — from command output and error messages before they're logged. This applies to stdout, stderr, and thrown error messages.
Practical consequence: it's safe-ish to paste openclaw output into a bug report. It's not safe to paste raw ~/.nemoclaw/credentials.json or nemoclaw debug bundles without reviewing them first, because redaction is per-command-path, not a universal filter on the filesystem.
The one command a noob should memorize
openclaw security audit
Run this inside the sandbox (after nemoclaw my-assistant connect). It runs 50+ distinct automated checks across your deployment and prints the findings. The check categories include:
- Synced-folder leak detection — iCloud / Dropbox / OneDrive syncing sensitive directories off-disk
- Plaintext secrets in configuration files — tokens and keys where they shouldn't be
- Hooks hardening verification — whether your hooks are configured to fail-closed
- Gateway no-auth detection — a gateway accepting unauthenticated connections
- Sandbox misconfiguration scanning — the NemoClaw/OpenShell sandbox layer
- Weak-model susceptibility assessment — whether your active model is known to be easy to prompt-inject
- Multi-user exposure matrix — whether the host environment exposes your gateway to other accounts on the machine
- Node command policy validation — whether device-node actions are restricted
- Dangerous config flag scanning — explicit checks for
allowInsecureAuth,dangerouslyDisableDeviceAuth, and similar dangerous opt-outs
Treat any finding as a TODO, fix the easy ones first, and if you hit something you don't understand, search the upstream OpenClaw security docs for it.
Skill and extension supply-chain scanning
One more thing worth knowing: when you install an OpenClaw skill or extension, OpenClaw runs a built-in static-analysis scanner on it first. Critical findings block installation by default. This is especially relevant because doc 01 mentions ClawHub (clawhub.ai) as the plugin discovery + install surface — random plugins from ClawHub are not implicitly trusted, and the scanner is what stands between "I typed openclaw plugins install something" and "something is now running inside my sandbox".
If you want to install a plugin the scanner flagged, you have to explicitly override it. Don't do that unless you've read the source.
What NemoClaw does not add on this layer
NemoClaw's perimeter (network/filesystem/process/inference policies) is enforced by OpenShell. Everything on this page is upstream OpenClaw behavior that NemoClaw inherits unchanged. That means:
- If you take OpenClaw outside a NemoClaw sandbox (running it standalone on your laptop), all of this still applies — prompt filtering, tool deny list, env blocklist, audit command, redaction, extension scanner. They're baked into OpenClaw itself.
- Keeping OpenClaw up to date matters. NemoClaw pins a specific OpenClaw version via the blueprint digest (
min_openclaw_versioninblueprint.yaml). When NVIDIA ships a new NemoClaw blueprint that bumps the pinned OpenClaw, you get whatever new application-layer defenses landed upstream. Stale blueprint → stale defenses. This is why doc 05's "do not fight the tooling" rule exists. openclaw doctorandopenclaw security auditare different.doctoris a health check for misconfigured DM policies and channel setup;auditis the 50+ security check suite above. Run both; they catch different things.
Where this maps in the rest of the doc set
- Doc 01 covers the OpenClaw Gateway/Pi agent model that this layer runs inside.
- Doc 04 covers the NemoClaw/OpenShell perimeter — the complementary half.
- Doc 05 now has a credential-storage subsection describing how the host-side
~/.nemoclaw/credentials.jsonis protected. - This doc is everything else OpenClaw does on its own, above and beyond the perimeter.
The mental frame that ties it all together: NemoClaw fences the box, OpenClaw fences the brain. A noob setting up a NemoClaw deployment is responsible for both, and openclaw security audit is the cheapest tool for checking the second half.
← Back to 00-INDEX.md