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?
What makes it even better is that these dogs are like Malinois. If they want to get into something, they will; people have had their entire network compromised by bots they left running overnight, and any important information like account logins and so on runs the risk of being misused.
It's one thing to sandbox, maybe give the bot a temporary, limited $100 card or account to go perform a specific task, but there's no coherent mind underlying these agents.
Depending on how the chain of thought / reasoning goes, or what text they get exposed to on the internet, it could tap into spy novel, hacker fanfic, erotic fiction, or some weird reddit rabbithole and go completely off the rails in ways that you'll never be able to guard against, audit, or account for.
Claw bots seem to be a weird sort of alternate reality RPG more than a useful tool, so far. If you limit it to verifiable tasks, it might be safer, but I keep seeing people rave about "leaving it on overnight and waking up to a finished project" and so on. Well sure, but it could also hack your home network, delete your family pictures folder, log into your bank account and wire all your money to shrimp charities.
Might be wise to wait on safer iterations of these products, I think.
Shrimp charities is a genius angle.
> "Claw bots seem to be a weird sort of alternate reality RPG more than a useful tool, so far."
So basically crypto DeFi/Web3/Metaverse delusion redux
They're 100% fun. There's 100% definitely something there that's useful. To strain the dog analogy - If you were a professional dog trainer, or if the dog was exceptionally well trained, then there's a place for it in your life. IT can probably be used safely, but would require extraordinary effort, either sandboxing it so totally that it's more or less just the chatbot, or spending a lot of time building the environment it can operate in with extreme guardrails.
So yeah, a whole lot of people will play with powerful technology that they have no business playing with and will get hurt, but also a lot of amazing things will get done. I think the main difference between the crypto delusion stuff and this is that AI is actually useful, it's just legitimately dangerous in ways that crypto couldn't be. The worst risks of crypto were like gambling - getting rubber hosed by thugs or losing your savings. AI could easily land people in jail if things go off the rails. "Gee, I see this other network, I need to hack into it, to expand my reach. Let me just load Kali Linux and..." off to the races.
web 4.0 here we come
I think the point you're making is fully correct, so consider this a devil's advocate argument...
People claim, you can use Claw-agents more safely while getting some of the benefits, by essentially proxying your services. For example on Gmail people are creating a new Google accounts, forwarding email via rule, and adding access to their calendar via Google's Family Sharing. This allows the Claw agent to read email, access the calendar, but even if you ask it to send an email it can only send as the proxy account, and it can only create calendar appointments then add you as an attendee rather than destroy/altering appointments you've made.
Is the juice worth the squeeze after all that? That's where I struggle. I think insecure/dangerous Claw-agents could be useful but cannot be made safe (for the logical fallacy you pointed out), and secure Claw-agents are only barely useful. Which feels like the whole idea gets squished.
We already have this concept. It’s called user accounts.
Your Gmail account vs my Gmail account. Your macOS account vs my macOS account.
Yes, I can spam you from my Gmail. Yes, I can use sudo on my Mac and damage your account. But the impact is by default limited.
The answer is to just treat assistants as a different user profile, use the same sharing mechanisms already developed (calendar sharing, etc), and call it a day.
> Am I missing something?
You are indeed missing a TON. A lot of Open Claw users don't give it everything. We give it specific access to a group of things it needs to do the things we want. If I want an agent to sit there 24/7 maximizing uptime of my service, I give it access to certain data, the GitHub repo with PR privileges, and maybe even permissions to restart the service. All of this has to be very thoughtful and intentional. The idea that the only "useful" way to use Open Claw is to give it everything is a straw man.
You could do that with say Claude Code too with rather much simpler set up.
OPs question was more around sandboxes though. To which, I would say that it's to limit unintended actions on host machine.
The problem is boundary enforcement fatigue. People become lazy, creating tight permission scopes is tedious work. People will use an LLM to manage the scopes given to another LLM, and so on.
Can you talk us through that a bit more? I suspect it would need more access than the permissions you mentioned to be more useful than a simple rules based automation.
Yes, although what I think is different in this setup here is the OpenShell gateway override, as they mention:
> NemoClaw installs the NVIDIA OpenShell runtime and Nemotron models, then uses a versioned blueprint to create a sandboxed environment where every network request, file access, and inference call is governed by declarative policy. The nemoclaw CLI orchestrates the full stack: OpenShell gateway, sandbox, inference provider, and network policy.
I think this means you get a true proxy layer with a network gateway that let's you stop in-flight requests with policies you define, so it's not their hardware but the combination of it plus OpenShell gateway and network policies.
I also think the reason they are doing this is to try and get some moat around these one-clik deployments and leverage their GPU for rent type of thing instead of having you go buy a mac mini and learn "scary" stuff (remember, the user market here is pretty strange lol)
I like that these companies will name their products OpenShell or OpenVINO or whatever with the implication that anyone else will ever contribute to it beyond bugfixes. The message is "Come use and contribute to our OPEN ecosystem (that conspicuously only works on our hardware)! Definitely no vendor lock-in here!"
It's not something like Mesa. It's open source in the same way chromium or android is open source. A single company is the major contributor and decides the architecture and direction the whole ecosystem will go.
OpenShell is the gem here indeed. A lot of good ideas like network sandbox that does TLS decryption and use of policy engine to set the rules. However:
> Credentials never leak into the sandbox filesystem; they are injected as environment variables at runtime.
If anyone from the team is reading - you should copy surrogate credentials approach from here to secure the credentials further: https://github.com/airutorg/airut/blob/main/doc/network-sand...
The LLM will easily leak these credentials out. So the creds should be outside the sandbox, and the only thing the sandbox should see is a connection API that opens a socket/file handle.
Alternatively where is needs an API key, it should be one bound to the endpoint using it. E.g. a ticket granting ticket is used to create a bound ticket.
A copy on write filesystem would be an interesting way to sandbox writes, but there is difficulty in checking the diff.
Because it's so useful to me that I'm willing to accept the risk of it having access to the thing it needs for the benefit it provides. I'm not willing to accept the risk of it having access to things it doesn't need for no benefit.
Then again, I was wary of OpenClaw's unfettered access and made my own alternative (https://github.com/skorokithakis/stavrobot) with a focus on "all the access it needs, and no more".
but you don't want the go to send your documents to someone in Nigeria
Yes you're missing something. The crate is so your dog doesn't eat the documents you dont want it to mess with
I'm putting my dog in his crate with all my important documents, but leaving my fine china tableware in the cupboard away from the dog.
You start with one teacup in the crate and before you know it you're merging handle redesigns back to the entire fine china cupboard.
and then tie a tiny string from the china to a thing inside the cage because it seemed handy at the time...
Then one day forgetting to close the door of the crate…..
But the dog is so used to the crate…
Agreed. I think the "simplifies running OpenClaw always-on assistants safely" bit is pretty misleading. I suppose it can wreak less havoc on your local file system but, as you point out, it's access to your account credentials (Slack, email, Amazon?, etc.) that is the real danger.
You don't need to connect your calendar, email, or anything else. I am having so much fun talking to it bouncing ideas and pushing code/markdown files to GitHub (totally separate account I created for OpenClaw). On the other hand I don't have a crazy life that everything needs to be in the calendar.
> being worried he might eat them, so you put the dog in a crate, together with the documents.
Maybe you don't want the dog to shit all over the place after eating said documents, so you put it in a crate.
you put the dog in crate with a COPY of your documents.
Step 2 -
you put the dog in crate with a COW of your documents
Your dog has now ordered a hitman to kill you, assume your identity and to live vacariously as a simple bartender at Cheers.
Make it two copies!
[dead]
[dead]