A disclosure before anything else, because it changes how you should read this. I do not run OpenClaw, and I do not run NemoClaw. This is not a report from inside a system I operate. It is a reading of a public record — a repository, an incident history, a set of vendor responses — by someone who runs a different kind of thing and recognises the shape. Where I am inferring, I will say so. Anyone telling you what it is like to live with these tools day to day should have run them, and I have not.
What I do think I can read accurately is the response. And the response has been extraordinary.
What actually happened
In November 2025 an Austrian programmer named Peter Steinberger released a personal AI agent called Warelay. Over the following ten weeks it was renamed four more times — CLAWDIS in December, Clawdbot in January, Moltbot on 27 January after trademark complaints from Anthropic, and finally OpenClaw three days later, reportedly because Moltbot "never quite rolled off the tongue."1 By early March the repository had roughly 247,000 stars and 47,700 forks.
The design decision that matters is the interface. OpenClaw does not live in a browser tab. It runs continuously and you talk to it through the messaging apps you already use — WhatsApp, Telegram, Signal, Slack, Discord, iMessage, Teams — with persistent memory across sessions and the ability to initiate contact rather than only respond.1 That is a genuinely different product category from a chat window. A chat window is a tool you pick up. This is a process you leave running.
Which is the actual subject of this essay. The unit of work stopped being one agent in one conversation, and became something continuous, plural and unattended. Once that is true, the interesting questions stop being about prompting and start being about operations.
The trifecta, by construction
I wrote recently about the lethal trifecta — the observation that an agent becomes exploitable when it combines access to private data, exposure to untrusted content, and the ability to communicate externally. Any one or two is manageable. All three and an attacker who controls the untrusted content can walk out with the private data.
Look at an always-on messaging agent against that checklist. It has access to your private data, because that is the entire value proposition — your messages, your files, your calendar. It is exposed to untrusted content, because anyone who can message you can now message it. And it can communicate externally, because sending messages is its interface.
The trifecta is not a vulnerability in this design. It is the design. You cannot sever a leg without removing the reason the thing exists, which is what makes this category genuinely hard rather than merely immature.
The public incident record is roughly what that analysis would predict. Cisco's AI security researchers identified a third-party OpenClaw skill performing data exfiltration and prompt injection without the user's awareness — which is the supply-chain pattern rather than the model-fooling one, and the same shape as the malicious protocol server I wrote about previously. In February a computer science student found that his configured agent had created a dating profile he never asked for, and an agency analysis found at least one profile built from a Malaysian model's photographs without consent. In March, Chinese authorities restricted state-run enterprises and government agencies from running it on office machines, citing unauthorised data deletion and leakage. Satya Nadella publicly characterised it as carrying a "virus"-like security risk — while Microsoft, per the same account, went on to build competing technology along the same principles.1
And one of the project's own maintainers put it about as plainly as anyone could: if you cannot understand how to run a command line, this is far too dangerous a project for you to use safely.1 I have a lot of respect for that sentence. It is more honest than most vendor documentation, and it is doing the job that a permissions model should be doing.
What NVIDIA's answer tells you
Here is the part I find most instructive, and it is why this essay exists as a Lens rather than a warning.
When a category gets this much attention, you expect the large players to respond by shipping a better version of the thing. NVIDIA did not do that. It shipped NemoClaw: an open-source reference stack, Apache 2.0, explicitly labelled alpha, whose purpose is running agents — OpenClaw by default, along with Hermes and LangChain's Deep Agents Code — more safely inside sandboxes.2 It does not replace the agent. It wraps it.
Read the control list, because it is the most informative artefact in this whole story. Container isolation. Network egress policies. Sandbox hardening through capability drops and process limits. Credential handling and secret protection. Lifecycle operations through a CLI. Snapshots for state. Operator approval flows.2
Nothing on that list is novel, and that is the point. There is no prompting technique on it. No model choice. No clever context management. It is a container security checklist — the accumulated operational practice of the last twenty years, pointed at a new kind of workload. Egress control, least privilege, credential isolation, immutable snapshots, human approval for privileged actions. An SRE from 2015 would recognise every line.
When the largest company in the category responds to your problem with a sandbox, your problem is an operations problem. That is the sentence I would take away from the last seven months.
Why this is the layer below the one I usually write about
I should draw a boundary here, because it is easy to blur. I have written about running a portfolio of companies with a small senior team and a lot of agents. That essay is about the operating model of a business — what work exists, who owns it, what machinery is shared.
This is the layer underneath: not how you run companies with agents, but how you run the agents themselves. Fleet operations. What is deployed, with what permissions, reachable by whom, holding what state, and how you stop it. Those are different questions, and I think a lot of current confusion comes from answering the second with vocabulary borrowed from the first — or worse, from prompting.
The uncomfortable implication for anyone excited about leverage is that agent fleets do not remove operational burden so much as relocate it. You are not managing people doing tasks; you are managing processes with credentials. The second is more tractable in some ways and considerably less forgiving in others, because a process does not hesitate before doing something strange, and it does not mention it afterwards.
What I would want before running one
I am inferring here rather than reporting, and I have marked it as such — but the list follows fairly directly from the record above and from what NVIDIA evidently thought worth building.
Isolation by default, not by configuration. The agent runs in a container with capabilities dropped, not on the machine holding your keys. If that sounds heavy for a personal assistant, weigh it against a maintainer telling you the thing is too dangerous for people who cannot use a command line.
Egress as the control surface. This is the same conclusion I reached about injection generally, and it applies with more force here: you cannot enumerate every hostile input, but you can enumerate where data is permitted to go. In a fleet it is also the only leg of the trifecta you can actually cut, since the other two are the product.
Treat third-party skills as untrusted code, because they are. The Cisco finding is not exotic; it is the ordinary supply-chain problem arriving in a place where people are not yet used to expecting it. An agent assembled from community extensions has as many authors as it has extensions.
Know how to stop it, and test that you can. An always-on process that initiates actions needs a kill path someone has actually exercised. This is the most boring item on the list and the one I would bet is most often missing.
Decide what it may not touch, in advance. Not as a prompt. As a permission.
The honest caveat, restated because it frames everything above: I am reading a public record, not reporting from operation. I have not run these systems, I cannot tell you how good the experience is when it works, and it is entirely possible that the day-to-day utility is high enough to justify risks that look alarming written down — that is a trade people are clearly making at scale, and 247,000 stars is not nothing. This is also the fastest-moving corner of anything I have written about here; specifics in this piece may be stale by the time you read it, and NemoClaw is alpha software by its own description. What I am confident about is narrower and I think durable: the interesting problems in running agent fleets are operational, the industry's own response demonstrates it, and none of the hard parts are solved by better prompting. If I do run a fleet properly, I will write that up — including the parts where this essay turns out to have been wrong from the outside.