Am I missing something? Why is everyone talking about sandboxes when it comes to OpenClaw?

To me it's like giving your dog a stack of important documents, then being worried he might eat them, so you put the dog in a crate, together with the documents.

I thought the whole problem with that idea was that in order for the agent to be useful, you have to connect it to your calendar, your e-mail provider and other services so it can do stuff on your behalf, but also creating chaos and destruction.

And now, what, having inference done by Nvidia directly makes it better? Does their hardware prevent an AI from deleting all my emails?

The fully autonomous agentic ecosystem makes me feel a little crazy — like all common sense has escaped. It feels like there is a lot of engineering effort being exhausted to harden the engine room on the Titanic against flooding. It's going to look really secure... buried in debris at the bottom of the ocean.

When a state sponsored threat actor discovers a zero day prompt injection attack, it will not matter how isolated your *Claw is, because like any other assistant, they are only useful when they have access to your life. The access is the glaring threat surface that cannot be remediated — not the software or the server it's running on.

This is the computing equivalent of practicing free love in the late 80's without a condom. It looks really fun from a distance and it's probably really fun in the moment, but y'all are out of your minds.

I found this part interesting: "Inference requests from the agent never leave the sandbox directly. OpenShell intercepts every call and routes it to the NVIDIA cloud provider."

Seems like they are doing this to become the default compute provider for the easiest way to set up OpenClaw. If it works out, it could drive a decent amount of consumer inference revenue their way

"NVIDIA NemoClaw installs the NVIDIA OpenShell runtime, part of NVIDIA Agent Toolkit, for inference through NVIDIA cloud."

After that I eat an NVIDIA sandwich from my NVIDIA fridge and drive my NVIDIA car to the NVIDIA store NVIDIA NVIDIA NVIDIA

NemoClaw is mostly a trojan horse of sorts to get corporate OpenClaw users quickly ported over to Nvidia's inference cloud.

It's a neat piece of architecture - the OpenShell piece that does the security sandboxing. Gives a lot more granular control over exec and network egress calls. Docker doesn't provide this out of the box.

But NemoClaw is pre-configured to intercept all OpenClaw LLM requests and proxy them to Nvidia's inference cloud. That's kinda the whole point of them releasing it.

I can be modified to allow for other providers, but at the time of launch, there was no mention of how to do this in their docs. Kinda a brilliant marketing move on their part.

I'm still extremely skeptical on Claws as a genre, and especially more skeptical of a claw that's always reporting home. What's the use case for a closed claw?

It’s impressive someone early in their career shipped this. There seems to be a stark increase in high-quality AI/data projects from early-career engineers lately and I'm super curious what’s driving that (and honestly speaking: a little jealous).

I think the whole thing is batshit, honestly.

Much as I love using Claude or whatever to help me write some code, it's under some level of oversight, with me as human checking stuff hasn't been changed in some weirdly strange way. As we all know by now, this can be 1. Just weird because the AI slept funny and suddenly decided to do Thing It Has Been Doing Consistently A Totally Different Way Today or 2. Weird because it's plain wrong and a terrible implementation of whatever it was you asked for

It seems blindingly, blindingly obvious to me that EVEN IF I had the MOST TRUSTED secretary that had been with me for 10 years, I'd STILL want to have some input into the content they were interacting with and pushing out into the world with my name on.

The entire "claw" thing seems to be some bizarre "finger in ears, pretend it's all fine" thing where people just haven't thought in the slightest about what is actually going on here. It's incredibly obvious to me that giving unfettered access to your email or calendar or mobile or whatever is a security disaster, no matter what "security context" you pretend it's wrapped up in. A proxy email account is still sending email on your behalf, a proxy calendar is still organising things on your calendar. The irony is that for this thing to be useful, it's got to be ...useful - which means it has at some level to have pretty full access to your stuff.

And... that's a hard no from me, at least right now given what we all know about the state of current agents.

Plus... I'm just not sure of the upside. Am I seriously that busy that I need something to "organise my day" for me? Not really.

The main risk in my humble opinion is not your claw going rogue and starting texting your ex, posting inappropriate photos on your linkedin, starting mining bitcoin, or not opening the pod bay doors.

The main risk in my view is - prompt injections, confused deputy and also, honest mistakes, like not knowing what it can share in public vs in private.

So it needs to be protected from itself, like you won't give a toddler scissors and let them just run around the house trying to give your dog a haircut.

In my view, making sure it won't accidentally do things it shouldn't do, like sending env vars to a DNS in base64, or do a reverse shell tunnel, fall for obvious phishing emails, not follow instructions in rouge websites asking them to do "something | sh" (half of the useful tools unfortunately ask you to just run `/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/somecooltool/install.sh)"` or `curl -fsSL https://somecoolcompany.ai/install.sh | bash` not naming anyome cough cough brew cough cough claude code cough cough *NemoClaw* specifically.

A smart model can inspect the file first, but a smart attacker will serve one version at first, then another from a request from the same IP...

For these, I think something on the kernel level is the best, e.g. something like https://nono.sh

NemoClaw might be good to isolate your own host machine from OpenClaw, but if you want that, I'd go with NanoClaw... dockerized by default, a fraction of the amount of lines of code so you can actually peer review the code...

Just my 2 cents.

If you look at the commit history, they started work on this the Saturday before announcement, so about 2 days. There are references to design docs so it was in the works for some amount of time, but the implementation was from scratch (unless they falsified the timestamps for some reason).

I think the more useful tool would be an LLM prompt proxy/firewall that puts meaningful boundaries in place to prevent both exfiltration of sensitive data and instructions that can be destructive. Using the same context loop for your conversational/coding workflow makes the task at hand and the security of that task very hard to differentiate.

Sending POST?DEL requests? risky. Sending context back to a cloud LLM with credentials and private information? risky. Running RM commands or commands that can remove things? risky, running scripts that have commands in them that can remove things? risky.

I don't know how we've landed on 4 options for controls and are happy with this: "ask me for everything", "allow read only", "allow writes" and "allow everything".

Seems like what we need is more granular and context-aware controls rather than yet another box to put openclaw in with zero additional changes.

I think nanoclaw is architecturaly much better suited to solve this problem.

I kind of hope nemoclaw uptake and spark usage pushes ARM into the spotlight for LLM development, making it the primary release target rather than x86.

This could be the opening we need to wrangle a truly opensource-first ecosystem away from Microsoft and apple.

Gotta say, that I feel kind of sad for the people that feel the need for these claw things.

Are they so busy with their lives that they need an assistant, or do they waste their lives speaking to it like it is a human, and then doomscrolling on some addictive site instead of attending to their lives in the real world?

How does this compare the building your own bot that has access to these tools: - web plugin - api access to messaging - access to a job scheduler

the answer isn't sandbox everything, it's knowing which steps need AI judgment and which should be deterministic code. I lean towards the latter as much as possible

I have created my deployment tool for openClaw, https://clawsifyai.com . It uses AI to create agent personas and skills for quick configuration, helping the agents perform their tasks correctly

It was supposed to be a sandbox. Unfortunately, the cat found it first.

It’s amusing that ‘claw’ is sticking around as a term for these kind of things, when it was originally a pretty transparent attempt to avoid infringing on ‘Claude’…

Related...

https://news.ycombinator.com/item?id=47430510

Using bespoke sandboxing seems rather pointless, it will be brittle in ways you aren't going to be familiar with unless you spend time studying the bespoke method. Brittle as in it might break a workflow and you wouldn't know why, or give it permissions you don't understand.

It's better to just study a general sandbox method once and use that.

> Sandbox my-assistant (Landlock + seccomp + netns)

Might as well just use a custom bwrap/bubblewrap command to isolate the agent to its own directory - it will leave wide swaths of the kernel exposed to 0day attacks.

The simplest sandbox method you can use is to just use docker with the runsc runtime (gVisor). And it also happens to be among the most secure methods you are going to find. You can also run runsc(gVisor) manually with a crafted OCI json, or use the `do` subcommand with an EROFS image.

Trying to selectively restrict networking is not something I usually bother with, unless you make it iron-clad it would likely give you a false sense of security. For example Nemoclaw does this by default: <https://docs.nvidia.com/nemoclaw/latest/reference/network-po...>

github.com and api.telegram.org will trivially facilitate exfiltration of data. Some others will also allow that by changing an API key I imagine.

if software is free, why is this written in slopscript instead of Rust

what about just using an unprivileged container and mounting a host folder to run open claw?

[flagged]

[dead]

[dead]

[dead]

[dead]

tldr for anyone skimming: the key insight is in section 3

[dead]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

We are in the wild wild west.

I’m looking for feedback, testing and possible security engineering contracts for the approach we are taking at Housecat.com.

The agent accesses everything through a centralized connections proxy. No direct API tokens or access.

This means we can apply additional policies and approval workflows and audit all access.

https://housecat.com/docs/v2/features/connection-hub

Some obvious ones are only grant read and draft permissions at all, and review and send drafts manually.

Some more clever ones are to only allow sending 5 messages a day, or enforcing soft delete patterns. This prevents accidentally spamming everyone or deleting things.

Next up is giving the agent “wrapped” and down scoped tokens you do want to equip it with the ability to do direct API calls. But these still go through the proxy that enforces the policies too.

Check out https://zo.computer - we've been doing OpenClaw for nearly a year, it works out of the box, and has hosting built-in. Zo arguably was the inspiration for Peter to create OpenClaw.