Every OpenClaw and n8n tutorial I have read arrives at the same instruction: point an HTTP Request node at http://127.0.0.1:18789 and you are done. The problem is that the address is not an API.
It is an agent holding a shell on whatever machine it happens to be running on.
A NemoClaw n8n integration runs in both directions and keeps both of them inside the sandbox. n8n calls the OpenClaw gateway over loopback when a step needs judgment; OpenClaw calls an n8n webhook when it needs deterministic multi-step execution, and NVIDIA's OpenShell runtime sits underneath, deciding which of those calls is allowed to leave the box at all.
The wiring is nearly identical to the bare version.
What a NemoClaw n8n integration actually is
NemoClaw is a Docker sandbox with a policy engine and an inference proxy, wrapped around a stock OpenClaw install. Per NVIDIA's NemoClaw documentation, the installer is a single command:
curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash
That starts the last-known-good installer and an onboarding wizard. The wizard asks which agent runtime you want (OpenClaw is the default), which inference provider to route through, whether to wire up a messaging channel, and which policy tier to apply. Those answers decide most of what follows.
Inside the sandbox, the agent has read-write access to /sandbox, /tmp, /dev/null, and /dev/pts. Everything else it needs is mounted read-only, including /usr, /lib, /etc, and /var/log. Enforcement uses Landlock, the Linux Security Module, on a best-effort basis, so you want a kernel at 5.13 or newer for it to apply at all. Ubuntu 22.04 and later qualify.
None of that is new, exactly. It is the same principle I used at GreenHat Webs when I set up the deployment pipeline: developers had full access to dev, limited access to staging, and no access at all to production. Deployment errors dropped by half, and not because anyone became more careful. The path that could cause damage stopped being reachable by accident.
Direction one: n8n calls the sandboxed agent
n8n reaches the agent the same way it always did, over loopback, because NemoClaw binds the gateway to 127.0.0.1 by default. The relevant setting is NEMOCLAW_GATEWAY_BIND_ADDRESS=127.0.0.1, and the documentation is unambiguous about leaving it there.
If n8n runs on the same host, it’s simple. Add an HTTP Request node, target the gateway on port 18789, and store the gateway token as a Header Auth credential in n8n rather than pasting it into the node. Use this direction for the steps that need a model to decide something: classify an inbound support email, judge whether a product description has drifted off-brand, decide if a refund request is genuine, summarize a ticket thread into a one-line disposition.
If n8n runs somewhere else, resist the obvious fix. Rebinding the gateway to 0.0.0.0 is how you end up as one of the exposed instances that show up in internet-wide scans. Use an SSH local forward instead:
ssh -N -L 18789:127.0.0.1:18789 user@agent-host
There is a second gotcha worth knowing before you spend an afternoon on it. NemoClaw's auto-pair helper only approves devices whose client ID is cli, openclaw-cli, or openclaw-control-ui. n8n is none of those, so it authenticates with the gateway token rather than pairing as a new device. Anything else gets rejected and logged. Separately, the operator.admin scope is never approved automatically, which means an agent action like creating a cron job stops and waits for you to run openclaw devices approve <requestId> by hand.
Direction two: OpenClaw calls an n8n webhook
This is the direction that breaks on the first run, and it breaks by design. NemoClaw applies a deny-by-default network policy, so the sandbox can only reach endpoints that are explicitly allowed. The baseline policy ships with five endpoint groups: NVIDIA's inference API, ClawHub, the OpenClaw API, the OpenClaw docs, and the npm registry.
Your n8n instance is not on that list. Neither is GitHub, which surprises people.
When the agent tries to POST to your webhook, OpenShell blocks the connection and logs the attempt. You see it in the TUI:
openshell term
From there you can approve the request for the running session. To make it stick, add the endpoint to the live policy:
openshell policy update <sandbox-name> \
--add-endpoint n8n.example.com:443:read-write:rest:enforce
The access mode field controls whether the sandbox gets GET only or GET plus the write methods. A webhook trigger needs the write methods. To review what you have actually granted, export the current policy and read it:
nemoclaw <sandbox-name> policy get > current-policy.yaml
For a permanent change that survives a rebuild, edit nemoclaw-blueprint/policies/openclaw-sandbox.yaml and re-run nemoclaw onboard. Live edits made with raw openshell policy set are not replayed when the sandbox is recreated, which is a good way to lose a working configuration and not understand why.
Use this direction for everything the agent should not be improvising: updating a CRM record, posting to Slack, creating a calendar event, writing a row to a spreadsheet. The agent decides that something should happen. n8n decides how. This is the same split I use in the n8n SEO pipeline, where the model proposes and the workflow executes, and it is the reason that pipeline has not needed a rollback.
The Personal tier undoes the entire point
NemoClaw's onboarding wizard offers four policy tiers, and one of them will quietly return you to where you started.
Restricted starts from the baseline and adds nothing. Balanced, the default, adds development tooling and a web search provider. Open adds messaging platforms and productivity APIs. Personal applies a preset called personal-open-internet, which lets every binary in the sandbox open TCP connections to any reachable host on ports 80 and 443.
Read NVIDIA's own description of that tier carefully. The rule does not inspect the hostname, method, path, or body. There is no operator approval prompt, because the connection was already permitted. The documentation states plainly that an agent on this tier can send workspace data or sandbox-visible credentials to an arbitrary reachable service on either port.
Loopback and link-local ranges stay blocked, the common cloud metadata range with them, and the filesystem controls remain active. That protection is real, and it stops well short of what a business system needs. If you are connecting an agent to live customer data, run Restricted or Balanced and add endpoints deliberately.
Personal is a tier for a laptop.
Getting that tier decision right is most of the work. It is usually where n8n automation consulting starts: with the list of things a workflow is permitted to touch, written down before anyone opens the canvas.
What the sandbox stops, and what it does not
Containment solves the host problem. The agent cannot rewrite your system binaries, cannot modify /etc to redirect DNS or swap the TLS trust store, cannot persist outside /sandbox and /tmp, and cannot reach a service you never allowed. NemoClaw also runs a memory secret scanner that intercepts writes of API keys and tokens into persistent memory files before they hit disk, and the CLI redacts credential patterns from output.
What it does not solve is the permission you granted on purpose.
If you add your store's REST endpoint to the policy with write access so the agent can update inventory, the agent can also delete products. The sandbox contained the blast radius around your operating system. It did nothing about the blast radius inside your allowlist. That distinction is the whole lesson from what happens when an AI agent has production credentials, and no runtime removes the need for a human approval gate in front of irreversible actions.
So how should you split the work?
Four rules that have held up:
- A judgment step inside an otherwise deterministic flow belongs in n8n, calling the gateway over loopback for that one node.
- Multi-step deterministic execution belongs in an n8n webhook that the agent triggers, never in the agent's own tool calls.
- Restricted or Balanced tier for anything touching business systems, with endpoints added one at a time.
- Every endpoint in the policy is a permission with your name on it. Review the exported YAML like you would review a pull request.
If you are still deciding whether this job needs an agent in the first place, the comparison between n8n, OpenClaw, and Claude agents has the full decision tree, including the cost per run.
So, when your agent does something expensive at three in the morning, who approved the endpoint it used?
If you are wiring an agent into systems that hold real customer data and want the permission model reviewed before the first webhook goes live, that is exactly the kind of work I do. Start with n8n automation consulting, or tell me what you are building.