Pipelock vs NemoClaw

The short version

Pipelock is a network proxy that scans HTTP, MCP, and WebSocket traffic for credential leaks, prompt injection, SSRF, and tool poisoning. Single binary, works with agents whose traffic is routed through it.

NemoClaw is NVIDIA’s container sandbox orchestrator. It provisions hardened Docker containers with network allowlists, filesystem restrictions, and process isolation for AI agents running on the OpenClaw framework.

They operate at different layers. NemoClaw controls the execution environment. Pipelock controls the network boundary. One manages where the agent can go. The other inspects what the agent sends.

Feature comparison

Where NemoClaw is better

Container isolation is deeper. NemoClaw’s sandbox (via OpenShell) provides full container isolation: filesystem hardening with read-only system paths, immutable configuration protection, capability drops, no-new-privileges, and process limits. Pipelock has Landlock + seccomp + netns but doesn’t manage the full container lifecycle.

Binary-scoped network rules. NemoClaw can restrict which binary processes can reach which endpoints, using per-binary verification described in NemoClaw’s public docs. If you want node to reach api.openai.com but curl to reach nothing, NemoClaw can enforce that. Pipelock doesn’t track which binary originated a request.

Inference routing flexibility. NemoClaw routes model API calls through configurable endpoints, including NVIDIA cloud, local Ollama, local NIM, local vLLM, and other compatible providers. The agent doesn’t need direct access to provider API keys. Pipelock doesn’t manage inference routing (different scope).

Policy presets. NemoClaw ships with pre-built network policy presets for common integrations (Discord, Slack, npm, PyPI, and others). Quick start for standard setups.

Where Pipelock is better

Content inspection. This is the core architectural difference. NemoClaw’s network policy controls which hosts the agent can reach. Pipelock scans the content of what flows through those connections. Pipelock’s 48 built-in DLP patterns detect credentials with base64, hex, and URL encoding awareness. It runs 25 injection detection patterns through 6 normalization passes. NemoClaw’s network policy operates at the connection and path level rather than the content level.

Transport coverage. Pipelock scans HTTP forward proxy traffic, HTTPS via CONNECT, WebSocket frames, and MCP tool calls across stdio and HTTP transports. NemoClaw’s network policy controls which connections are allowed and can filter by HTTP method and URL path.

MCP security. Pipelock scans MCP bidirectionally: tool descriptions for poisoning, tool arguments for credential leaks, responses for injection, tool changes for rug-pulls, and call sequences for suspicious chains. NemoClaw’s public documentation does not describe MCP-specific content scanning as of April 2026.

Agent compatibility. Pipelock works with agents whose HTTP traffic is routed through it. Set HTTPS_PROXY or wrap MCP servers with pipelock mcp proxy. NemoClaw is designed for OpenClaw agents and requires a supported container runtime for the container sandbox.

Deployment weight. Pipelock is a single 18MB static binary. NemoClaw requires a supported container runtime and a container image.

The enforcement gap

The core architectural difference: connection-level allowlists and content-level scanning solve different problems.

NemoClaw’s network policy says “this agent can talk to these hosts.” That’s a valid first layer. Based on current public docs, it does not describe request or response body inspection. Pipelock doesn’t manage the container boundary but inspects what crosses the network boundary.

NemoClaw:  Agent → [container sandbox + allowlist] → Allowed hosts only
Pipelock:  Agent → [content scanning proxy] → Scanned traffic
Both:      Agent → [sandbox] → [content proxy] → Scanned traffic to allowed hosts

The third option combines both layers. NemoClaw provides the execution boundary. Pipelock provides the content boundary. Different failure modes, defense in depth.

Enforcement transparency

NemoClaw itself is open source (Apache 2.0), but the actual security enforcement happens in OpenShell, a separate NVIDIA project. NemoClaw builds on OpenShell and adds onboarding, policy management, and inference routing.

Pipelock’s enforcement logic is self-contained. Every scanner pattern, every normalization pass, every DLP check is in the same repo and tested by the same CI pipeline.

When to use each

Start here if you need both containment and content scanning. It combines process containment and content scanning in one deployment. pipelock sandbox provides Landlock filesystem restrictions, seccomp syscall filtering, and network namespace isolation, with HTTP/WebSocket/MCP scanning, SSRF protection, and tool policy on top. No Docker, no framework coupling.

Use NemoClaw if: You’re specifically running OpenClaw and need Docker container-grade isolation, binary-scoped network rules, or centralized inference routing. NemoClaw is stronger at container governance, but you’ll still want a content-scanning layer alongside it.

Use both if: You want NemoClaw’s container boundary and Pipelock’s content inspection together. That’s the higher-assurance OpenClaw stack.

Third-party feature descriptions are based on public materials reviewed in April 2026. Features and capabilities may change. Check each project’s current documentation for the latest.

Further reading

• What is an agent firewall? : full definition and evaluation checklist
• Agent Firewall vs Guardrails : how firewalls differ from inference-layer tools
• MCP Security : MCP threats and content-level scanning
• NemoClaw on GitHub
• Pipelock on GitHub