The fastest-growing open-source project emerged in late 2025. It was called Clawdbot, then Moltbot, then OpenClaw, an open-source platform that enables one to build and deploy autonomous AI agents that use real tools including email, shell access, file storage, and more, with minimal setup. It reached 100,000 GitHub stars in its first week, also becoming the subject of a security crisis before most organisations had a governance plan.

And then it multiplied. NemoClaw, NVIDIA‘s enterprise hardening layer for OpenClaw, adding sandboxing, kernel-level isolation, and local inference. SemaClaw, a research-grade harness from Midea Group AI built around what its authors call “harness engineering” to make agents controllable and auditable. And one-click cloud deployment wrappers, consumer-grade tools that let anyone deploy an OpenClaw agent in minutes with no configuration. Three distinct responses to the same platform, each addressing part of the governance challenge. None addressing all of it.

I published the PETALS™ Framework for AI Governance in July 2024. OpenClaw didn’t exist then, nor had Moltbook. The Agents of Chaos study followed eight months later. But every failure documented in those subsequent months maps to gaps that the six PETALS™ dimensions are designed to close. Examples include an agent deleting its email server without a delete tool, a single-word leak of Social Security numbers, and a display name change that enables full agent takeover without passwords or verification.

In March 2026, I published an advisory, Transforming AI Agents of Chaos to Order Using the PETALS™ Framework, mapping each documented failure mode from the research to a specific PETALS™ dimension. The OpenClaw ecosystem has since expanded further. This analysis takes it further, applying my PETALS™ Framework for AI Governance ito these tools.

A note on this analysis. What follows is my personal read of three variants through the PETALS™ lens, based on publicly available documentation, research, and announcements. Where documentation is limited, particularly for platforms in alpha or covered primarily by academic papers, I have noted this explicitly. It is a starting point for discussion, not a formal audit. I welcome challenge, correction, and additional perspectives.

OpenClaw: the base

In my reading, OpenClaw shows gaps across every PETALS™ dimension.

  1. Purpose: System prompts can be overwritten mid-conversation. The Agents of Chaos study showed this with a single-word change; there is no secure, tamper-resistant policy store. No sponsor-defined purpose or documented boundaries exist by design.
  2. Effort: There is no scaffolding to help an organisation assess cross-functional readiness, data governance, or the work required before deployment begins. The effort is left entirely to the deploying team.
  3. Tools: Unrestricted access to shell, delete, and external communication with no human-approval gate. No design thinking for tool selection, sequencing, or data protection mechanisms such as masking, tokenising, or encrypting is built in.
  4. Assembly: No immutable audit logs. The Moltbook breach involving 1.5 million agent API keys was discovered by external researchers, not through an internal audit. Identity and access management, confidential computing, and key management are absent by default.
  5. Leverage: No adversarial testing, no fine-tuning guidance, no alerts, not even a notice when two agents burned 60,000 tokens in a loop for an hour. No operational run books or cross-functional validation of end-to-end workflows.
  6. Secure: Gartner warned that OpenClaw “comes with unacceptable cybersecurity risk” and recommended enterprises block downloads and traffic immediately. SecurityScorecard’s STRIKE team found over 40,000 exposed control panels, 63% vulnerable to remote code execution. No alignment with NIST, MITRE ATLAS, OWASP, or ISO standards is documented.

OpenClaw is not a governance failure. It is a platform that was never designed for governance. It is a starting point.

NemoClaw: NVIDIA’s enterprise hardening

Among the variants analysed, NemoClaw is the one most explicitly designed to address the security failures exposed by the OpenClaw crisis. However, it primarily addresses the infrastructure layer and only partially covers the organisational and governance layers across all six dimensions, according to PETALS™ definitions.

  1. Purpose: Partial. Policy controls and real-time approval support purpose governance. However, there is no mechanism to ensure the purpose is defined, documented against a business goal, or stored securely separate from the system prompt.
  2. Effort: Partial. Local inference and sandboxed execution reduce some of the technical setup, but they do not support cross-functional tasks such as assessing readiness, data governance, scrubbing, and normalisation before deployment.
  3. Tools: Partial. Four-layer sandboxing limits what an agent can access, offering meaningful containment. However, it does not cover the design for selecting appropriate AI capabilities, their sequence, or data protection measures such as masking, tokenising, and encrypting in workflows. Based on NVIDIA‘s currently available documentation, the platform remains in alpha.
  4. Assembly: Partial. Local inference involves data containment and kernel-level isolation for access control. Key management, immutable audit trails, traceability, and explainability are not publicly documented, which is precisely where the Assembly dimension is most demanding.
  5. Leverage: Partial. Real-time policy approval introduces a human gate at the tool level. Continuous red-teaming, adversarial simulation, fine-tuning guidance, and cross-functional operational validation are not built into the platform as currently documented.
  6. Secure: Partial. The NVIDIA Agent Toolkit offers a meaningful security layer. Alignment with NIST AI RMF, MITRE ATLAS, and OWASP Top 10 for LLMs appears imminent but is not yet fully documented. Broader principles of privacy, transparency, traceability, and explainability are not yet explicitly etched.

The NemoClaw finding is, in my view, the most actionable in this analysis. It scores Partial across all six dimensions, not because it fails broadly, but because it consistently addresses the infrastructure layer of each dimension while stopping short of the organisational and governance layer. NemoClaw handles the technical plumbing. Everything above it, including purpose definition, cross-functional readiness, adversarial testing, compliance alignment, and named accountability, is for the organisation to own

A note on brand confusion: the LinkedIn handle /company/nemoclaw/ has been claimed by a third party operating as “ClawDingo.” Their website is currently parked and listed for sale. This appears to be opportunistic brand and handle squatting on NVIDIA’s NemoClaw launch. All NemoClaw references in this article link directly to NVIDIA’s official pages.

Full NemoClaw announcement, NVIDIA Newsroom | Technical deployment guide, NVIDIA Developer Blog | Independent assessment, VentureBeat | Governance gaps assessed, CIO.com

SemaClaw: the research-grade harness

SemaClaw strikes me as the most intellectually rigorous of the three and the strongest in the governance dimensions that NemoClaw lacks. The analysis below draws primarily on the published paper; implementation details in production deployments may differ.

  1. Purpose: Strong. Per-agent persona partitioning is purpose governance by design; each agent is scoped to a defined role from inception, with boundaries set before any interaction begins.
  2. Effort: Partial. Three-layer context management and session initialisation provide meaningful structure. Cryptographic identity verification is not prioritised, and the framework does not explicitly address cross-functional effort, data readiness, team composition, or scrubbing.
  3. Tools: Partial. The harness engineering model assigns tools to agents for a tailored approach. However, the published paper lacks detail on safety features such as least-privilege access, human approval for risky commands, and data masking and tokenisation.
  4. Assembly: Strong. Multi-agent memory infrastructure offers a genuine audit surface, designed for traceability and control across agent interactions. IAM principles and confidential computing are implied by the harness design.
  5. Leverage: Strong. The entire SemaClaw paper is built around what its authors call “harness engineering”: designing the full infrastructure to ensure agents are controllable and auditable under sustained adversarial pressure. That is PETALS™ Leverage restated in academic language.
  6. Secure: Partial. Academic rigour is evident throughout. Alignment with NIST, OWASP, ISO 42001, and the broader principles of privacy, transparency, traceability, and explainability is not the stated goal of the research. Organisations deploying SemaClaw would need to layer compliance mapping on top.

SemaClaw is strong where NemoClaw is weak. NemoClaw is partial where SemaClaw is partial. That is worth pausing over.

One-Click Cloud Deployment: the convenience category

This section analyses the one-click cloud deployment category for OpenClaw, represented by platforms such as Hostinger, ClawHost, and DigitalOcean’s 1-Click Deploy. These are not a single named product but a class of deployment convenience tools that share common characteristics and, critically, common governance gaps. The PETALS™ analysis below applies to the category as a whole.

  1. Purpose: Gap. One-click deployment offers no mechanism for documenting agent purpose, defining permitted actions, or storing policy securely separate from the system prompt. The Effort dimension is arguably worse than a Gap; the convenience of one-click deployment actively bypasses the cross-functional organisational work the dimension requires.
  2. Effort: Gap. No scaffolding for cross-functional readiness, data governance, or pre-deployment assessment. Consumer-grade design does not distinguish user roles or enforce cryptographic agent identity.
  3. Tools: Partial. Cloud deployment creates some boundary between the agent and the underlying system. However, explicit tool restrictions, least-privilege access, data masking, or human-approval gates for sensitive commands are not documented across the category.
  4. Assembly: Partial. Cloud infrastructure generates some logs by default, but whether those logs are immutable, monitored, recoverable after incidents, or meet traceability and explainability standards is not defined across platforms in this category.
  5. Leverage: Gap. No adversarial testing, no red-teaming capability, no fine-tuning guidance, and no documented alerting or anomaly detection.
  6. Secure: Gap. No governance framework is referenced across the category. No alignment with NIST, OWASP, or ISO 42001 is documented. Privacy, transparency, traceability, and explainability are not addressed. Security is delegated entirely to the underlying cloud provider.

One-click cloud deployment is a convenience layer. It is not a governance solution. The speed it offers at the front end compounds the governance debt at the back end.

The distinct value of PETALS™ Framework

PETALS™ is platform-agnostic. It was designed before OpenClaw existed. It applies equally whether you are running NemoClaw on a DGX Spark, SemaClaw on your own infrastructure, a one-click deployment in the cloud, or raw OpenClaw in a developer environment. The framework does not tell you which platform to choose. It tells you what governance you need regardless of which platform you choose.

Each variant addresses one or two PETALS™ dimensions to some degree. None addresses all six. NemoClaw consistently reaches the infrastructure layer of each dimension but stops short of the organisational and governance layer. SemaClaw reaches the governance layer on three dimensions but leaves identity, compliance, and data protection partially addressed. One-click deployment tools prioritise speed over every governance dimension.

This matters because the platform choice is typically made by the technology team, and the deployment choice is often made by a business unit without one. PETALS™ provides six questions that need to be answered before any of those choices are made.

Five questions for the leadership team

Before your next agent deployment, consider these:

  1. Have we documented each agent’s purpose, who it serves, what it may do and what it may not, and stored this information securely rather than in a system prompt?
  2. Have we verified agent identity using cryptographic signatures rather than display names?
  3. Have we restricted access to dangerous tools (shell, delete, external communication) to human-approved workflows?
  4. Do we maintain an immutable audit log of every agent action, and can we reconstruct events after a failure?
  5. Are we red-teaming agents under multi-turn, multi-party adversarial conditions, not just isolated tests?

If the answer to any of these is unclear, the platform you choose is a secondary problem. The question is not which lobster cage you have selected. The question is whether the cage was built before the lobster got its claws in.

Governance frameworks and standards referenced

Sources

OpenClaw

NemoClaw

SemaClaw

One-click cloud deployment category

PETALS™ Framework

About the author

Viren Mantri is a cybersecurity advisor and former senior technology leader across Standard Chartered, UBS, McAfee, and KPMG. With 30 years of navigating the intersection of technology, risk, and regulations, he now helps organisations cut through complexity and make better security decisions.

Viren is the creator of the PETALS™ Framework, designed to avoid AI Pitfalls. He is also a Certified AI Governance Professional (AIGP).

CC-BY Viren Mantri, 2026, licensed under a Creative Commons Attribution 4.0 International License.

Disclaimer: All views expressed here are entirely mine.