Two weeks ago, NVIDIA announced NemoClaw at GTC. This week, Cisco launched DefenseClaw at RSAC. Between them, they've created the first serious enterprise security stack for OpenClaw.
But after reading through the technical details of both, I have a question that neither product answers: who's responsible for the stuff underneath?
The New Security Stack
Let me lay out what exists now, because the "Claw" ecosystem is getting confusing fast.
OpenClaw is the open-source AI agent itself. It runs on your machine (or server), connects to messaging platforms, executes skills, and takes autonomous actions. It's the thing everyone's been deploying.
OpenShell is NVIDIA's secure runtime environment. Think of it as a hardened container specifically designed for running AI agents. It provides the isolation layer that sits between the agent and the host operating system.
NemoClaw sits on top of OpenShell and adds three things: input guardrails that filter dangerous prompts, sandboxed execution for skills, and monitoring that tracks agent behavior. We covered it in detail last week.
DefenseClaw is Cisco's layer on top of all that. It provides zero-trust governance — an AI Bill of Materials for tracking what models and skills your agents use, sandbox scanners that test skills before deployment, and code-guard tools that monitor agent-generated code at runtime.
Stack them up and you get: OpenClaw → OpenShell → NemoClaw → DefenseClaw. Four layers, two vendors (plus the open-source project), each solving a different piece of the puzzle.
What Each Layer Actually Does
I'll skip the marketing language and describe what each layer solves in terms of concrete attacks.
NemoClaw's guardrails catch prompt injection. If someone embeds malicious instructions in a Slack message, email, or web page that your agent reads, the guardrails try to detect and filter it before the instruction reaches the agent's reasoning layer. It's imperfect — researchers consistently find bypasses — but it raises the bar significantly.
NemoClaw's sandbox limits skill damage. If you install a malicious ClawHub skill (or a legitimate skill gets compromised), the sandbox prevents it from accessing your host filesystem, stealing credentials, or pivoting to other services. The skill can only access what the sandbox explicitly grants.
DefenseClaw's ABOM gives you inventory. Most organizations running OpenClaw have no idea which skills are installed, which models are being used, or which data sources the agent accesses. The AI Bill of Materials creates that visibility — think of it as an asset inventory for agent components.
DefenseClaw's scanner catches bad skills before deployment. Instead of installing a ClawHub skill and hoping it's not malicious, the scanner analyzes it in an isolated environment first. It's pre-deployment testing applied to agent extensions.
DefenseClaw's code-guard monitors runtime behavior. If the agent generates code and executes it (which OpenClaw can do), the code-guard inspects it before execution. This catches scenarios where prompt injection convinces the agent to write and run something harmful.
The Gap in the Middle
Both products are genuinely impressive engineering. And both leave the same thing unaddressed.
Neither NemoClaw nor DefenseClaw handles infrastructure. Specifically:
-
Network security. Neither product configures a firewall, restricts inbound access, or prevents your OpenClaw instance from being exposed to the internet. The 220,000+ exposed instances we wrote about earlier this month would still be exposed with NemoClaw and DefenseClaw installed.
-
Authentication. Neither product puts an authentication layer in front of the OpenClaw web interface. If someone can reach your instance, they can interact with it. NemoClaw's guardrails filter what the agent processes, but they don't prevent unauthorized access to the agent in the first place.
-
SSL/TLS. Neither product sets up encrypted connections. Traffic between you and your agent would still travel unencrypted unless you configure SSL separately.
-
Server management. Neither product patches your operating system, manages your SSH keys, rotates your server credentials, or handles instance monitoring. If the underlying server is compromised through an OS vulnerability, everything running on top — OpenShell, NemoClaw, DefenseClaw — is compromised too.
-
API key isolation. Neither product separates your AI provider credentials from the agent runtime. If the agent is compromised despite all the guardrails and sandboxes, the attacker gets your API keys.
This isn't a criticism of what these products do — it's an observation about what they don't. They secure the agent. They don't secure the server. And for the vast majority of OpenClaw deployments right now, the server is the problem.
Who Builds What
The emerging answer, based on RSAC conversations and vendor positioning, seems to be:
| Problem | Who Solves It |
|---|---|
| Agent behavior (prompt injection, skill execution) | NemoClaw |
| Agent governance (inventory, policy, compliance) | DefenseClaw |
| Agent infrastructure (deployment, network, auth, SSL) | ??? |
| Agent monitoring (anomaly detection, incident response) | Both + SIEM |
The infrastructure layer is the gap. In enterprise environments, that's typically handled by the platform team or devops. For individual users and small teams — which is most of the OpenClaw user base — nobody's handling it.
That's the space Clawdy occupies. We don't compete with NemoClaw or DefenseClaw. We complement them by handling the part they don't touch: isolated cloud instances, authentication proxy, SSL termination, firewall configuration, API key proxying, and managed updates. The boring stuff that nobody announces at conferences but that prevents the most common real-world attacks.
The Practical Question
If you're evaluating the OpenClaw security stack today, the question isn't "NemoClaw or DefenseClaw?" — it's "how many layers do I need, and in what order?"
For enterprises with security teams and compliance requirements: you probably want all of it. Clawdy (or equivalent) for infrastructure. NemoClaw for runtime security. DefenseClaw for governance. A SIEM integration for monitoring. That's the full stack.
For small teams and individuals: start with infrastructure. A properly isolated, authenticated, encrypted deployment prevents the attacks that are actually happening at scale right now. NemoClaw and DefenseClaw are good additions when you're ready, but they solve problems that are downstream of the infrastructure problem.
The security stack matures from the bottom up: infrastructure first, then runtime, then governance. Skipping the foundation to install the guardrails is like installing a home security system in a tent.
Start with the foundation. Clawdy deploys OpenClaw on isolated infrastructure with auth, SSL, and network isolation — the layer NemoClaw and DefenseClaw are built on top of. Get started at clawdy.app.