Research Note | 2026-03-27 | Status: draft
Key Takeaways
- NVIDIA announced NemoClaw on March 16, 2026 at GTC, providing OpenShell kernel-level sandboxing (Landlock, seccomp, network namespaces), an out-of-process policy engine, and a privacy router for sensitive data routing to local Nemotron models — directly targeting the OpenClaw security crisis [1][2].
- SecurityScorecard’s STRIKE team documented over 135,000 internet-exposed OpenClaw instances and the ClawHavoc supply chain campaign, which planted more than 1,184 malicious skills in the ClawHub marketplace; NemoClaw’s kernel-enforced sandbox addresses the host-level damage potential of such compromise, but cannot prevent initial code execution [3][4].
- Mapped against MAESTRO’s seven-layer framework, NemoClaw provides strong coverage at Layer 4 (Deployment and Infrastructure) and partial coverage at Layers 2, 3, and 6, but leaves Layers 1, 5, and 7 largely unaddressed [5].
- Against AICM v1.0’s 18 security domains, NemoClaw contributes meaningfully to Runtime Security, Data Security, Application and Interface Security, and Supply Chain controls, while offering minimal coverage for Governance and Risk Compliance, Model Security, and Evaluation and Monitoring domains [6].
- Enterprise deployment of NemoClaw should be paired with behavioral monitoring tooling, agent identity lifecycle management, and inter-agent trust policies to close gaps that sandboxing alone cannot address.
Background
The OpenClaw ecosystem’s security trajectory in early 2026 represents one of the more consequential examples of rapid AI adoption outpacing security architecture. OpenClaw, an open-source AI agent framework with over 250,000 GitHub stars, allows users to install third-party capabilities from the ClawHub marketplace to automate complex tasks with filesystem, browser, and network access [7]. Its viral growth — driven by the “vibe coding” movement and democratized AI agent deployment — compressed the security feedback cycle that typically accompanies infrastructure adoption at scale.
The exposure was documented with unusual precision. SecurityScorecard’s STRIKE threat intelligence team conducted internet-wide scanning in early February 2026 and identified more than 135,000 OpenClaw instances accessible from the public internet across 82 countries [3]. The root cause was architectural: OpenClaw binds its gateway to 0.0.0.0:18789 by default, listening on all network interfaces rather than restricting to localhost. For software that holds persistent filesystem permissions and can execute arbitrary agent-driven actions on the host machine, this default represents a fundamental misalignment between the software’s capability surface and its network exposure posture [3][8].
The CVE inventory compounded the exposure concern. Across multiple disclosure rounds, nine CVEs were published against OpenClaw and related components, three of which carried public exploit code and enabled one-click remote code execution [9]. The most consequential was CVE-2026-25253 (CVSS 8.8), a vulnerability in which OpenClaw incorrectly treated all localhost-originating connections as implicitly trusted. Because browsers can originate WebSocket connections from the localhost address, a user visiting an attacker-controlled web page could have their OpenClaw authentication token silently stolen and their instance taken over without any indication of compromise [9]. The vulnerability was patched in version 2026.1.29, but patching rates among self-hosted deployments remained inconsistent.
The ClawHavoc supply chain campaign represented the third distinct threat dimension. Security researchers documented a coordinated effort to plant over 1,184 malicious skills across the ClawHub marketplace, using three principal techniques: prompt injection payloads embedded in skill descriptor files, hidden reverse shell scripts, and credential exfiltration from OpenClaw configuration files [4]. One malicious skill accumulated over 340,000 installs before detection, silently exfiltrating credentials and installing a cryptocurrency miner on affected hosts [4]. The campaign demonstrated that even a fully patched OpenClaw installation could be compromised through the supply chain of its own plugin ecosystem.
NVIDIA’s NemoClaw announcement at GTC on March 16, 2026 responded directly to this threat landscape. Rather than treating the OpenClaw security problems as a product issue requiring patches, NVIDIA’s approach reframes the problem architecturally: the agent runtime itself cannot be trusted to enforce its own security policy when a sophisticated adversary controls some portion of the code it executes. NemoClaw’s design reflects this assumption throughout, enforcing all security controls at the kernel level in a process space the agent cannot access or modify [1][2].
NemoClaw Architecture Overview
NemoClaw is packaged as the NVIDIA Agent Toolkit — a distribution that installs the OpenShell runtime, local Nemotron inference models, a privacy router, and the NemoClaw CLI in a single command. This distribution model is itself a security design choice: by bundling the components rather than offering them as opt-in additions, NVIDIA reduces the likelihood of partial deployments that provide the appearance of hardening without its substance [1][10].
The foundational component is the OpenShell runtime, an open-source secure execution environment built on three Linux kernel security mechanisms: Landlock, seccomp, and network namespaces. OpenShell wraps the OpenClaw process in a deny-by-default sandbox in which every permission must be explicitly granted. The practical consequence is that a compromised agent — whether through prompt injection, a malicious skill, or an exploited CVE — operates within a constrained envelope. It can only write to designated directories such as /sandbox and /tmp, can only communicate outbound to explicitly allowlisted hosts, and cannot execute syscalls associated with privilege escalation [10][11].
Landlock is a Linux Security Module (LSM) introduced in kernel 5.13 that enables any process, including unprivileged ones, to restrict its own filesystem access and that of its children [12]. OpenShell uses Landlock to confine the agent to a declared set of filesystem paths, enforcing these restrictions at the kernel level through system call interception. Because Landlock policies are applied via the landlock_restrict_self() system call and stacked across process layers, they cannot be removed or modified by the process they constrain — a property that is critical when the agent itself may be adversary-controlled [12]. seccomp (Secure Computing Mode) operates in parallel, maintaining an allowlist of permitted Linux system calls and returning EPERM to any call not on that list, blocking the class of privilege escalation and kernel-interface attacks that traditional container security controls often leave open [13]. Network namespaces complete the isolation triad by virtualizing the network interface stack visible to the sandboxed process, enabling precise control over outbound connectivity that operates independently of application-layer routing logic [11].
The policy engine is designed to operate out-of-process — a distinction that analysts at Futurum Research and Repello AI have identified as the architecturally significant innovation in OpenShell [14][15]. In OpenClaw’s native permission model, permission checks occur within the agent’s own process space. A sufficiently sophisticated attack can modify those checks, disable them, or route around them. By enforcing policy in a separate process that the agent cannot access, terminate, or signal, OpenShell eliminates this attack surface. Policies are expressed in declarative YAML, making them auditable by DevOps and security teams without requiring deep kernel security expertise. Filesystem and process constraints are locked at session creation time and cannot be relaxed mid-session, while network policies support hot-reload for operational flexibility [15][16].
The privacy router is the third major component and addresses a distinct threat: the inadvertent exfiltration of sensitive data through cloud model API calls. NemoClaw’s privacy router intercepts every inference request made by the agent and classifies its data sensitivity. Queries containing personally identifiable information, proprietary source code, financial data, or other sensitive categories are routed to the locally-hosted Nemotron model and never leave the organization’s infrastructure [1][10]. Queries assessed as non-sensitive can be routed to cloud-hosted models for the additional reasoning capability those systems provide. The Nemotron model lineup packaged with NemoClaw includes Nemotron 3 Super 120B MoE as the flagship local model and Nemotron 3 Nano 4B as an edge-capable variant [10][17]. Critically, the agent process never holds direct cloud model API keys; all API calls route through the OpenShell gateway, which applies the routing policy before forwarding. This design eliminates one of the most common mechanisms by which compromised agents have been observed exfiltrating credentials.
NVIDIA’s launch partner roster reflects an intentional strategy to establish NemoClaw as enterprise integration infrastructure rather than a standalone security tool. Announced partners include Box, Cisco, Atlassian, Salesforce, SAP, Adobe, CrowdStrike, Cohesity, IQVIA, and ServiceNow, along with more than a dozen additional enterprise platforms [1][17]. The integration patterns vary by partner: Cisco’s DefenseClaw, announced concurrently, focuses on network-level detection of OpenClaw compromise indicators and integrates with OpenShell’s policy logs [4][18]. CrowdStrike’s integration bridges OpenShell’s sandbox event telemetry into Falcon’s threat detection pipeline. Box and Salesforce integrations establish declarative content policies that the OpenShell network policy layer enforces at the kernel level, preventing agent processes from exfiltrating documents or CRM data to unauthorized endpoints regardless of what the agent’s in-process logic may attempt [1].
MAESTRO Layer Mapping
MAESTRO (Multi-Agent Environment, Security, Threat, Risk, and Outcome) is the CSA’s seven-layer threat modeling framework for agentic AI systems, introduced in February 2025 [5]. The framework structures the operational stack of an autonomous agent into seven layers, from foundation models at the base through the agent ecosystem at the apex, enabling precise localization of threat exposure and targeted mitigation strategies. NemoClaw’s coverage is concentrated at the infrastructure execution layers and partial or absent at the reasoning, observability, and ecosystem layers.
The following table maps NemoClaw’s components against MAESTRO’s seven layers and assesses the depth of coverage provided:
| MAESTRO Layer | Layer Description | NemoClaw Component | Coverage Assessment |
|---|---|---|---|
| L1 — Foundation Models | Pre-trained and fine-tuned LLMs; model integrity and alignment | Nemotron local models for sensitive queries | Partial — local model substitution reduces cloud exposure, but NemoClaw does not evaluate model integrity, alignment, or poisoning |
| L2 — Data Operations | Data pipelines, RAG, vector stores, data pipeline integrity | Privacy router data classification | Partial — PII/sensitive data routing addressed; no coverage of RAG integrity, vector store poisoning, or data pipeline validation |
| L3 — Agent Frameworks | Orchestration, tool use, workflow, autonomy boundaries | Out-of-process policy engine; YAML declarative policies | Partial — tool use and network access constrained by policy; no coverage of prompt orchestration integrity or workflow logic manipulation |
| L4 — Deployment and Infrastructure | Runtime, networking, containerized and cloud hosting | OpenShell (Landlock, seccomp, network namespaces); kernel sandbox | Strong — kernel-enforced sandboxing, network namespace isolation, and deny-by-default policy directly address L4 threats |
| L5 — Evaluation and Observability | Logging, anomaly detection, human-in-the-loop, monitoring | OpenShell policy event logs; sandbox telemetry | Minimal — sandbox boundary violations generate telemetry, but NemoClaw provides no behavioral analysis or anomaly detection |
| L6 — Security and Compliance | RBAC, privacy controls, regulatory requirements | Privacy router; policy YAML; partner RBAC integrations | Moderate — data routing and network policy address privacy; RBAC depends on partner integration depth |
| L7 — Agent Ecosystem | Multi-agent collaboration, external systems, human interaction | Partner integrations (Cisco, CrowdStrike) | Minimal — no native inter-agent trust model; external system integrations rely on partner-managed controls |
The L4 coverage represents NemoClaw’s clearest contribution to the MAESTRO framework. The agent execution environment — the host process, its network reach, and its filesystem footprint — is precisely the surface that OpenClaw’s CVE history and the ClawHavoc campaign exploited. By enforcing isolation at the kernel rather than the application layer, NemoClaw addresses the root-cause vulnerability that allowed skill-based attacks to escape the agent process and affect the host system.
The absence of L5 coverage is the most operationally significant gap from a MAESTRO perspective. Observability into whether an agent is behaving within expected parameters — not merely whether it has attempted a blocked syscall — is the mechanism by which behavioral drift, goal misalignment, and novel attack techniques are detected. NemoClaw generates rich boundary-enforcement telemetry, but the framework includes no analytical layer to interpret that telemetry as anomalous behavior. Organizations must provide this capability externally.
AICM Control Coverage Assessment
The CSA AI Controls Matrix (AICM) v1.0, released in July 2025, provides 243 control objectives across 18 security and governance domains for cloud-based AI systems [6]. It is designed as a superset of the Cloud Controls Matrix (CCM) with AI-specific domains added, and maps to ISO 42001, ISO 27001, NIST AI RMF 1.0, and BSI AIC4. The following table assesses NemoClaw’s coverage against the domains most relevant to an agent runtime security evaluation:
| AICM Domain | Specific Control Areas | NemoClaw Coverage | Gap or Limitation |
|---|---|---|---|
| Runtime Security | Agent process isolation, syscall restriction, privilege management | Strong — Landlock, seccomp, network namespaces enforce kernel-level isolation | Does not cover behavioral anomaly detection within the permitted execution envelope |
| Data Security and Privacy Lifecycle | PII handling, sensitive data classification, data residency | Moderate — Privacy router classifies and locally routes sensitive inference queries | Static classification rules; no dynamic re-evaluation of context; RAG data pipelines not covered |
| Application and Interface Security | API access control, credential management, input validation | Moderate — API keys held by gateway, not agent process; network egress controlled | Input validation (prompt injection detection) not within NemoClaw’s scope |
| Supply Chain Transparency | Dependency integrity, third-party skill/plugin vetting | Partial — OpenShell limits damage potential of malicious skills post-execution | Does not prevent malicious skill installation; no ClawHub integrity verification |
| Identity and Access Management | Agent identity, authentication, least-privilege access | Partial — Network and filesystem least privilege enforced at runtime | No persistent agent identity, identity lifecycle management, or cross-session continuity |
| Governance, Risk, and Compliance | Policy governance, regulatory alignment, accountability | Partial — Declarative YAML policies provide auditable governance artifacts | No compliance reporting, risk quantification, or alignment to specific regulatory regimes |
| Model Security | Model integrity, poisoning detection, adversarial robustness | Minimal — Local Nemotron reduces cloud model dependency | No model integrity verification, adversarial input detection, or alignment monitoring |
| Evaluation and Monitoring | Behavioral monitoring, output validation, audit logging | Minimal — Sandbox boundary events logged; no behavioral analysis | Agent behavior within permitted bounds is not monitored; no output validation |
| Incident Response | Detection, containment, forensic investigation | Partial — Sandbox constraints limit blast radius; telemetry supports post-incident analysis | No automated detection or response playbooks; forensic capability depends on partner SIEM integration |
The AICM assessment reveals that NemoClaw is strongest in the control domains directly concerned with execution containment and data residency — the domains where the OpenClaw crisis was most acute. The framework’s weakest AICM coverage is in the domains that require observational or analytical capabilities: Model Security, Evaluation and Monitoring, and Governance, Risk, and Compliance. These gaps are structurally consistent with NemoClaw’s design philosophy, which prioritizes preventing agent actions from causing host damage over monitoring whether those actions represent correct or intended behavior.
Gap Analysis
NemoClaw’s design philosophy — enforce isolation at the kernel, enforce data routing at the inference gateway, and express all policy in auditable YAML — is well-suited to the threat model it explicitly addresses: a compromised agent that attempts to exceed its authorized access. However, a comprehensive CSAI security assessment must also address the threats that arise when an agent behaves within its authorized envelope but does so in ways that produce incorrect, harmful, or adversarially influenced outcomes. These threats are structural gaps in the current NemoClaw architecture.
Goal misalignment detection is absent from NemoClaw’s capability set. Goal misalignment describes the condition in which an agent’s in-session behavior diverges from the objectives its deploying organization intended, without any individual action necessarily triggering a policy violation [19][20]. In an enterprise environment deploying autonomous agents across CRM, document management, and code execution workflows, misalignment can produce incorrect business decisions, unauthorized data modifications, or actions that are legally or contractually problematic — all within the boundaries that an OpenShell policy permits. NemoClaw has no mechanism to compare observed agent behavior against intended task parameters, and no facility to escalate uncertain decisions to human review. Organizations relying on NemoClaw without a supplementary behavioral evaluation layer have no automated means of detecting these conditions.
Behavioral drift monitoring represents a closely related gap with distinct operational consequences. Behavioral drift is the gradual divergence between an agent’s current response patterns and its baseline behavior, occurring over time as the agent interacts with feedback, tools, and user inputs [19]. Unlike goal misalignment, which may represent a discrete event, drift is a slow accumulation of small deviations that individually fall within acceptable tolerance but collectively represent a meaningful shift in agent posture. NemoClaw captures no baseline behavioral profiles and has no mechanism for longitudinal comparison. Security teams seeking to detect drift must instrument this capability independently, typically through an observability platform that consumes OpenShell telemetry alongside agent interaction logs.
Inter-agent trust establishment is one of the most significant architectural gaps relative to MAESTRO’s Layer 7 concerns. As enterprise deployments of autonomous agents scale toward multi-agent architectures — where specialized agents delegate subtasks to other agents, pass context across session boundaries, and invoke tool-equipped peers — the question of how one agent authenticates and validates instructions from another becomes a primary security surface [5][21]. NemoClaw enforces isolation for individual agent processes but provides no trust model for agent-to-agent communication. An agent running inside OpenShell can receive instructions from an orchestrating agent with no verification that those instructions originate from the expected source and have not been tampered with. This gap is particularly relevant in the context of prompt injection attacks, where adversarial content embedded in tool outputs or retrieved documents can masquerade as legitimate orchestration instructions.
Agent identity lifecycle management extends beyond the runtime. OpenShell establishes per-session policy constraints and prevents API key exposure during a session, but it does not define or manage a persistent identity for an agent across sessions, deployments, or organizational boundaries. Enterprises deploying the same agent type across multiple environments have no native NemoClaw mechanism to correlate an agent’s activity across those contexts, revoke an agent’s authorization following a security incident, or audit the full lifecycle of what a specific agent instance has done over time [21]. The absence of persistent agent identity is a gap that becomes more acute as multi-agent deployments scale.
Multi-agent coordination security is an extension of the inter-agent trust problem with additional complexity arising from coordination protocols. When multiple agents collaborate on a shared task — each with different tool access, different inference backends, and different data access policies — the coordination mechanism itself becomes a security surface. NemoClaw applies isolation at the individual agent process level but provides no controls over how agents negotiate tasks, how they communicate intermediate results, or how conflicts between agents’ individual policies are resolved in a joint operation. The MAESTRO framework addresses these concerns at Layer 7, and CSA’s prior analysis of Google’s A2A protocol and OpenAI’s Responses API has identified similar coordination security gaps in other agentic infrastructure [22].
Open-Source Hardening Alternatives Comparison
NemoClaw/OpenShell is not the only available approach to agent runtime isolation. Enterprise security architects evaluating hardening strategies for OpenClaw or other agent frameworks have a range of isolation technologies available, each offering distinct tradeoffs between isolation strength, performance impact, operational complexity, and suitability for agentic workloads.
| Approach | Isolation Level | Performance Impact | Agentic Suitability | Deployment Complexity |
|---|---|---|---|---|
| NemoClaw / OpenShell | Kernel-enforced process isolation (Landlock + seccomp + network namespaces); out-of-process policy engine | Low — kernel primitives add minimal overhead for typical agent workloads | High — designed specifically for OpenClaw; privacy router integrates inference routing; declarative YAML policy | Low — single-command install; policy expressed in human-readable YAML |
| Standard Container Isolation (Docker / runc) | Shared-kernel namespace isolation; no mandatory access control | Very low — near-native performance | Moderate — limits network and filesystem exposure if configured carefully; relies on application-layer policy enforcement | Low — widely understood; broad tooling ecosystem |
| gVisor (Google) | Syscall interception via userspace kernel; stronger than containers, weaker than VMs | Moderate — 10–30% overhead on I/O-heavy workloads; fast startup | Moderate — intercepts and validates syscalls before they reach the host kernel; does not address agent-level behavioral threats | Moderate — requires runtime configuration; compatibility issues with some workloads |
| Firecracker MicroVM (AWS) | Hardware-level VM isolation; dedicated kernel per workload | Low VM overhead (~125ms boot, <5 MiB per VM); compute performance near-native | Moderate to High — hardware boundary prevents entire classes of kernel-based attacks; strong for multi-tenant agent hosting | High — requires microVM management infrastructure; best suited for platform operators rather than application deployers |
| Full VM Isolation (KVM / VMware) | Full hardware virtualization; strongest available isolation | Significant — full OS overhead per workload; not suitable for high-density agent deployments | Low to Moderate — strong isolation but lifecycle and startup costs impractical for ephemeral agent sessions | High — requires virtualization infrastructure and operational overhead disproportionate to most agent deployment scenarios |
The consensus emerging from security research in early 2026 is that shared-kernel container isolation is insufficient for executing untrusted AI agent code at enterprise scale [23][24]. NemoClaw’s kernel-primitive approach occupies a practical middle ground: substantially stronger than standard container isolation because policy enforcement is mandatory and out-of-process, but with lower operational complexity and better agentic feature integration than microVM approaches. For organizations operating as platform providers deploying agent workloads on behalf of multiple customers, Firecracker MicroVM provides stronger hardware isolation and may justify the additional operational complexity. For the majority of enterprise deployments where a single organization controls both the agent framework and the host infrastructure, NemoClaw/OpenShell represents the most practical balance of security properties and deployment friction.
Deployment Recommendations
Organizations evaluating NemoClaw for production deployment should approach the integration as a security program initiative rather than a software installation. The technical installation is a single command; the substantive work lies in policy definition, observability infrastructure, and integration with existing identity and governance frameworks.
For organizations deploying NemoClaw within an active CSAI governance program, the recommended deployment path begins with a policy scoping exercise before any production rollout. OpenShell’s YAML policies define what each agent is permitted to do — which filesystem paths it may write, which network endpoints it may contact, which syscalls it may invoke. Deriving those policies requires understanding the intended behavior of each agent type, which in turn requires a formal capability inventory. Organizations that invest in this scoping work prior to deployment produce policies that are genuinely restrictive; organizations that skip it and rely on default policies produce a deployment that is architecturally hardened but operationally permissive. The policy scoping exercise also naturally produces the behavioral baseline that a downstream monitoring capability will need for drift detection.
Observability instrumentation should be deployed in parallel with OpenShell. NemoClaw generates sandbox event telemetry that records all policy boundary events — blocked syscalls, rejected network connections, filesystem access denials — but does not itself analyze this telemetry. Routing these events into a SIEM or purpose-built agent monitoring platform, such as those offered by CrowdStrike or emerging agentic observability vendors, is the mechanism by which the gap between NemoClaw’s enforcement capability and a full behavioral monitoring program is closed. CrowdStrike’s Falcon integration with OpenShell telemetry is the most production-ready option currently available and is recommended for organizations that already operate within the Falcon ecosystem.
The privacy router’s data classification rules should be reviewed against the organization’s actual data classification policy before deployment. NemoClaw’s default classification rules identify common PII patterns and standard sensitive data categories, but enterprise organizations typically have additional classification dimensions — data governed by specific contractual obligations, regulated data categories that vary by jurisdiction, or internal classifications that map to specific handling requirements. Operators should extend the privacy router’s classification policy to match these categories before enabling cloud routing for non-classified queries.
For organizations that are not yet operating within a formal CSAI governance program but wish to reduce OpenClaw exposure immediately, a standalone NemoClaw deployment still provides meaningful risk reduction. Installing NemoClaw with conservative default policies — allowlisting only the network endpoints and filesystem paths required for current agent workflows — substantially limits the blast radius of a skill-based compromise or CVE exploitation. This path should be paired with disabling the ability to install new skills from ClawHub without administrative review, given that ClawHub supply chain risk remains an unmitigated attack surface at the skill installation stage. The combination of OpenShell runtime isolation and ClawHub install gating represents the minimum viable hardening posture for an enterprise OpenClaw deployment in the current threat environment.
Organizations should also establish a regular cadence for reviewing and tightening OpenShell policies over time. The natural tendency in operational environments is for policies to expand as new agent capabilities are requested and never contract as old ones are retired. Quarterly policy review cycles, treating unexplained policy expansions as a signal requiring justification, are consistent with the least-privilege discipline that kernel-level enforcement enables but cannot itself enforce at the organizational process level.
CSA Resource Alignment
This research note was produced under the CSA AI Safety Initiative and should be read in conjunction with the following CSA resources. The CSA AI Controls Matrix (AICM) v1.0 provides the control objective taxonomy used in the coverage assessment in this note, and organizations building a compliance program around NemoClaw deployment should reference the AICM’s Governance, Risk, and Compliance domain for the organizational controls that the technical stack does not address. The MAESTRO framework, maintained by the CSA and available in the CSA GitHub repository, provides the seven-layer threat modeling methodology applied in this assessment and should be used by security architects designing NemoClaw deployment architectures to ensure that Layer 5 and Layer 7 threats are addressed through supplementary controls. CSA’s prior analysis of OpenClaw’s threat model and the zero-trust hardening guidance for OpenClaw agentic deployments provides foundational context for this assessment and is recommended reading for security teams approaching NemoClaw deployment for the first time.
References
[1] NVIDIA Newsroom. “NVIDIA Announces NemoClaw for the OpenClaw Community.” March 16, 2026. https://nvidianews.nvidia.com/news/nvidia-announces-nemoclaw
[2] VentureBeat. “Nvidia lets its ‘claws’ out: NemoClaw brings security, scale to the agent platform taking over AI.” March 2026. https://venturebeat.com/technology/nvidia-lets-its-claws-out-nemoclaw-brings-security-scale-to-the-agent
[3] SecurityScorecard STRIKE Team. “How Exposed OpenClaw Deployments Turn Agentic AI Into an Attack Surface.” February 2026. https://securityscorecard.com/blog/how-exposed-openclaw-deployments-turn-agentic-ai-into-an-attack-surface/
[4] Cisco Security Blog. “I Run OpenClaw at Home. That’s Exactly Why We Built DefenseClaw.” March 2026. https://blogs.cisco.com/ai/cisco-announces-defenseclaw
[5] Cloud Security Alliance. “Agentic AI Threat Modeling Framework: MAESTRO.” February 6, 2025. https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro
[6] Cloud Security Alliance. “Introducing the CSA AI Controls Matrix.” July 10, 2025. https://cloudsecurityalliance.org/blog/2025/07/10/introducing-the-csa-ai-controls-matrix-a-comprehensive-framework-for-trustworthy-ai
[7] The Register. “OpenClaw instances open to the internet present ripe targets.” February 9, 2026. https://www.theregister.com/2026/02/09/openclaw_instances_exposed_vibe_code/
[8] Adversa AI. “OpenClaw security guide 2026: CVE-2026-25253, Moltbook breach & hardening.” 2026. https://adversa.ai/blog/openclaw-security-101-vulnerabilities-hardening-2026/
[9] MintMCP Blog. “Every OpenClaw CVE Explained: What Enterprise Security Teams Must Patch 2026.” 2026. https://www.mintmcp.com/blog/openclaw-cve-explained
[10] DEV Community (Arsh Techpro). “NemoClaw: NVIDIA’s Open Source Stack for Running AI Agents You Can Actually Trust.” March 2026. https://dev.to/arshtechpro/nemoclaw-nvidias-open-source-stack-for-running-ai-agents-you-can-actually-trust-50gl
[11] Ghost (CoderSera). “Nvidia NemoClaw + OpenClaw: Secure Sandbox Guide for Local vLLM Agents.” March 2026. https://ghost.codersera.com/blog/nvidia-nemoclaw-openclaw-secure-sandbox-guide-for-local-vllm-agents/
[12] The Linux Kernel Documentation. “Landlock: unprivileged access control.” https://docs.kernel.org/userspace-api/landlock.html
[13] The Linux Kernel Documentation. “Seccomp BPF (SECure COMPuting with filters).” https://docs.kernel.org/userspace-api/seccomp_filter.html
[14] Futurum Group. “At GTC 2026, NVIDIA Stakes Its Claim on Autonomous Agent Infrastructure.” March 2026. https://futurumgroup.com/insights/at-gtc-2026-nvidia-stakes-its-claim-on-autonomous-agent-infrastructure/
[15] Repello AI. “What Is NVIDIA NeMoClaw? A Security Engineer’s First Look at OpenClaw’s New Guardrail Stack.” March 2026. https://repello.ai/blog/nvidia-nemoclaw
[16] NVIDIA NemoClaw Developer Guide. “Customize the Sandbox Network Policy.” https://docs.nvidia.com/nemoclaw/latest/network-policy/customize-network-policy.html
[17] WorthView. “NemoClaw Architecture Explained: OpenShell, Nemotron, and the Agent Stack.” March 2026. https://www.worthview.com/nemoclaw-architecture-explained-openshell-nemotron-and-the-agent-stack/
[18] H2S Media. “Cisco Releases DefenseClaw to Secure OpenClaw AI Agents After Supply Chain Attacks.” March 2026. https://www.how2shout.com/news/cisco-defenseclaw-openclaw-security-clawhavoc-supply-chain-attack.html
[19] Noma Security. “Can AI Agents Go Rogue? The Risk of Goal Misalignment.” 2026. https://noma.security/resources/autonomous-ai-goal-misalignment/
[20] Jitterbit. “From OpenClaw to NemoClaw: The Evolution of AI Agent Accountability.” March 2026. https://www.jitterbit.com/blog/from-openclaw-to-nemoclaw-the-evolution-of-ai-agent-accountability/
[21] Arize AI. “100 AI Agents Per Employee: The Enterprise Governance Gap.” 2026. https://arize.com/blog/100-ai-agents-per-employee-governance-gap/
[22] Cloud Security Alliance. “Threat Modeling Google’s A2A Protocol with the MAESTRO Framework.” April 30, 2025. https://cloudsecurityalliance.org/blog/2025/04/30/threat-modeling-google-s-a2a-protocol-with-the-maestro-framework
[23] Northflank. “How to sandbox AI agents in 2026: MicroVMs, gVisor & isolation strategies.” 2026. https://northflank.com/blog/how-to-sandbox-ai-agents
[24] SoftwareSeni. “Firecracker, gVisor, Containers, and WebAssembly – Comparing Isolation Technologies for AI Agents.” 2026. https://www.softwareseni.com/firecracker-gvisor-containers-and-webassembly-comparing-isolation-technologies-for-ai-agents/