Understand Gateway and Secret Controls
NemoClaw applies gateway access controls when the selected agent runtime exposes an in-sandbox gateway or dashboard. CLI secret redaction and runtime-specific memory guidance apply across guide variants.
The OpenClaw gateway authenticates devices that connect to the Control UI dashboard. NemoClaw hardens these defaults at image build time.
Device Authentication
Device authentication requires each connecting device to go through a pairing flow before it can interact with the gateway.
Gateway Bind Address
NemoClaw binds the OpenShell gateway to loopback by default.
Gateway Compatibility Container
On Linux hosts whose glibc is older than the OpenShell gateway binary requires, NemoClaw can run openshell-gateway in a Docker compatibility container so the Docker-driver gateway still starts. This path requires the explicit opt-in NEMOCLAW_OPENSHELL_GATEWAY_CONTAINER_PATCH=1.
Refer to OpenShell Gateway Compatibility Review for the unchanged compatibility-container source-of-truth boundaries.
Insecure Auth Derivation
The allowInsecureAuth setting controls whether the gateway permits non-HTTPS authentication.
OpenClaw’s security audit keeps NemoClaw-managed loopback allowInsecureAuth findings and provenance-known loopback device-auth opt-out findings visible as accepted findings instead of counting them as unexplained active findings.
Device-auth findings record whether the opt-out came from NemoClaw’s managed onboarding compatibility behavior or an operator-provided NEMOCLAW_DISABLE_DEVICE_AUTH=1; an opt-out with missing provenance remains active.
For audit reporting, NemoClaw treats a non-loopback CHAT_UI_URL, an onboard-time NEMOCLAW_DASHBOARD_BIND=0.0.0.0, or WSL’s default all-interface dashboard forward as remote dashboard exposure.
For an explicit NEMOCLAW_DASHBOARD_BIND=0.0.0.0 bind, use the same setting on later connect calls.
If the sandbox was created without that explicit setting, NemoClaw refuses the remote forward until you recreate it with NEMOCLAW_DASHBOARD_BIND=0.0.0.0 nemoclaw onboard --recreate-sandbox; this keeps the generated audit state aligned with the host exposure state.
On WSL, the ready summary still uses a loopback URL, but the generated audit configuration leaves the device-auth and insecure-auth findings active.
For an explicit remote bind with a loopback CHAT_UI_URL, NemoClaw disables device auth and enables OpenClaw’s Host-header origin fallback because the browser’s remote origin is not known at image-build time.
Both settings expand access and must remain explicit; use HTTPS or an SSH local forward when possible.
In that state, NemoClaw does not add the loopback-only audit suppressions, so the resulting device-auth, insecure-auth, and Host-header fallback findings remain active.
The generated configuration uses exact audit check IDs and flag details, records why each setting is present, and leaves the original severity and remediation under suppressedFindings in JSON output.
The audit also reports that suppressions are active so you can review the accepted risk. These suppressions change audit reporting only. They do not make either flag safe, weaken enforcement, or suppress unrelated findings.
Review the accepted findings and their recorded reasons:
Remove the underlying risky condition when dashboard compatibility no longer requires it.
Remove these suppressions only after the pinned OpenClaw audit contract test proves that OpenClaw natively classifies intentional loopback development HTTP without them, or after NemoClaw onboarding defaults CHAT_UI_URL to https://localhost with a generated local certificate.
Regression contracts: test/generate-openclaw-config-security-audit.test.ts locks generated suppression scope, test/openclaw-security-audit-suppressions-real.test.ts locks the pinned OpenClaw check IDs and details, and test/e2e/live/dashboard-remote-bind.test.ts proves a clean-host remote bind leaves all three risky findings active.
The preceding removal condition applies to all three contracts.
Auto-Pair Client Allowlist
The auto-pair watcher automatically approves device pairing requests from recognized clients, so you do not need to manually approve the Control UI.
Approve Administrative Scopes Manually
NemoClaw automatically approves only the operator.pairing, operator.read, and operator.write scopes.
It never automatically approves operator.admin.
Operations that require that scope, such as creating a cron job, need your explicit approval.
From the host, open the prepared connect shell:
In that shell, run the administrative command once to create the pending request, and note the exact requestId in the failure.
Then inspect the pending requests:
Find that exact requestId, and verify that its client, device, and requested scopes match the operation you just attempted.
Approve that request by its requestId:
Retry the original administrative command after the approval succeeds.
Approve only the exact requestId emitted by your command and only the client, device, and scopes you expect.
Do not approve an unexpected client or an unrelated operator.admin request.
CLI Secret Redaction
The CLI automatically redacts secret patterns (API keys, bearer tokens, provider credentials) from command output and error messages before logging them.
Memory Secret Scanner
The NemoClaw plugin blocks the agent from writing likely secrets (API keys, tokens, private keys) into persistent memory files.
The scanner intercepts Write, Edit, and similar tool calls targeting memory and workspace paths before they reach disk.