The short version
Pipelock is an open-source agent firewall. It scans HTTP, MCP, and WebSocket traffic routed through it for credential leaks, prompt injection, SSRF, and tool poisoning. With a signing key configured, it can emit signed action receipts for mediated decisions. Single binary, works with any agent routed through it.
NemoClaw is NVIDIA’s open-source reference stack for running supported AI agents more safely inside OpenShell sandboxes. It provides guided onboarding, managed inference, network policy, managed integrations, snapshots, and lifecycle operations through a CLI. The README lists OpenClaw as the default agent and Hermes and LangChain Deep Agents Code as supported, and calls the project alpha with best-effort maintenance.
They operate at different layers. NemoClaw controls the execution environment and which destinations the agent may reach. Pipelock inspects traffic routed through it on the way to those destinations.
Feature comparison
| Feature | Pipelock | NemoClaw |
|---|---|---|
| Architecture | Network proxy, single binary | Sandbox orchestrator on top of OpenShell |
| Agent support | Any agent routed through the proxy | OpenClaw, Hermes, LangChain Deep Agents Code |
| Credential scanning (DLP) | 65 patterns, encoding-aware, on mediated traffic | Not described in public materials |
| Prompt injection detection | Deterministic patterns with multi-pass normalization on mediated traffic | Not described in public materials |
| SSRF protection | Mediated private-IP, metadata, and DNS rebinding checks | Not described in public materials |
| MCP scanning | Mediated traffic, both directions: tool descriptions, arguments, responses | Not described in public materials |
| WebSocket scanning | Mediated frames, both directions | Not described in public materials |
| Network policy | Domain blocklist and allowlist plus content scanning on routed traffic | Deny by default; baseline endpoint rules scoped to a binary with method and path rules; Restricted, Balanced, Open, and Personal tiers of presets; operator approval flow for unlisted hosts |
| Broad-egress mode | No broad egress policy; routed traffic still passes Pipelock’s scanners | Personal tier: any host on ports 80 and 443, which the docs say is not inspected for protocol or payload and does not prompt |
| Process sandbox | Landlock, seccomp, and network namespaces (process-level) | OpenShell sandbox (container-grade) |
| Managed inference | Not in scope | Yes |
| Snapshots and lifecycle | Not in scope | Yes |
| Signed receipts | Available with a signing key; Ed25519, verifiable offline | Not described in public materials |
| License | Apache-2.0 core; Enterprise under ELv2 | Apache-2.0 |
Where NemoClaw is stronger
Container-grade isolation. The agent runs inside an OpenShell sandbox. Pipelock’s own sandbox is process-level, and Pipelock doesn’t manage a container lifecycle.
Operator approval for egress. The network-policy reference describes a deny-by-default baseline, rules that name the endpoint, the requesting binary, and the allowed methods and paths, and a TUI approval flow: an unlisted host is blocked and logged, shown with host, port, and binary, and added to the running policy if approved. That’s a useful gate for interactive agents, and it is finer than a hostname allowlist.
Managed inference and onboarding. Model routing, snapshots, and a guided setup for the supported agents. Pipelock doesn’t route model calls or manage agents.
Where Pipelock is stronger
Content inspection. An allowlist decides which hosts the agent may reach. It doesn’t read what the agent sends to an allowed host. NVIDIA’s own reference says so for the Personal tier: the rule “does not inspect the application protocol or payload,” and “an agent can send workspace data or sandbox-visible credentials to an arbitrary reachable service on either port without an operator approval prompt.” When the sandbox routes traffic through Pipelock, Pipelock scans the request body for encoded credentials, the response for injection, and the tool description for poisoning.
Transport coverage. Pipelock mediates HTTP forward proxy traffic, HTTPS via CONNECT, WebSocket frames, and MCP over stdio and HTTP, with the same scanning engine on each.
Framework independence. Pipelock works with any agent whose traffic goes through it, including agents NemoClaw doesn’t support.
Evidence. With a signing key configured, Pipelock can emit signed receipts for mediated decisions. The shipped verifier checks them offline.
The enforcement gap
NemoClaw: Agent -> [sandbox + egress allowlist] -> allowed hosts only
Pipelock: Agent -> [content-scanning proxy] -> scanned routed traffic
Both: Agent -> [sandbox] -> [Pipelock] -> scanned routed traffic to allowed hosts
The third line puts the controls in series. NemoClaw provides the execution boundary. Pipelock provides the content boundary for routed traffic. Different failure modes, one stack.
A note on what this page could verify
The NemoClaw column is drawn from the README, the docs index, and the Network Policies reference page, each dated above. The security best-practice pages were not read for this revision, so nothing here rests on them.
Further reading
- What is an agent firewall?: definition and evaluation checklist
- Pipelock vs DefenseClaw: the framework-hook side of the same question
- Pipelock vs Docker MCP Gateway: container isolation for MCP servers
- MCP security: MCP threats and content-level scanning
- Pipelock on GitHub
Sources checked
Third-party descriptions on this page come from the public materials below, read on the dates shown. Features and pricing change; check the current documentation before you decide.
Third-party product names and marks belong to their owners. PipeLab is not affiliated with, sponsored by, or endorsed by the makers of any product compared on this page. Descriptions of other products come from their own public materials on the dates listed above and reflect PipeLab's reading of them. If something here is wrong or out of date, tell us and it will be corrected.