Disclaimer: generated with the assistance of artificial intelligence
You're absolutely right. Let's divorce
--
Sent from my OpenClaw
I was in the repebble comments a few days ago and this person rolled their own for very obvious reasons: https://news.ycombinator.com/item?id=47078454
Maybe a middle ground would be isolating it like the article suggests, and poking it with a stick (giving it limited, or newly created accounts) to see what it can do?
I personally don't see how the daily briefings or whatever are worth the risk.
I essentially have a separate process that syncs my gmail, with gmail body contents encrypted using a key my openclaw doesn't have trivial access to. I then have another process that reads each email from sqlite db, and runs gemini 2 flash lite against it, with some anti-prompt injection prompt + structured data extraction (JSON in a specific format).
My claw can only read the sanitized structured data extraction (which is pretty verbose and can contain passages from the original email).
The primary attack vector is an attacker crafting an "inception" prompt injection. Where they're able to get a prompt injection through the flash lite sanitization and JSON output in such a way that it also prompt injects my claw.
Still a non-zero risk, but mostly mitigates naive prompt injection attacks.
Process isolation is not the danger with OpenClaw. Giving an LLM access to all your shit is the problem. My solution is to treat it like a human, give it it's own accounts, scoped to what you want it to do and accept the risks associated with that. If I had a human assistant I wanted to read my email, I'd set up an inbox for them specifically and forward what I want them to screen. I don't use OpenClaw, but have a similar harness I built that runs as an unprivileged Linux user with access to just what I want it to access.
I know it's not in vogue to actually know how technology works anymore, but we have literally decades worth of technology solutions for authentication/authorization, just fucking use it.
I’m assuming the claw might eventually be compromised. If that happens, the damage is limited: they could steal the GLM coding API key (which has a fixed monthly cost, so no risk of huge bills), spam the endpoints (which are rate-limited), or access a Telegram bot I use specifically for this project
hopechong•2h ago
Docker – lowest friction, but shares your kernel and has limits depending on what OpenClaw needs to do Dedicated hardware – best isolation, but you're paying 24/7 and it takes time to set up Cloud VM – the sweet spot for most people: true isolation, pay-per-use, tear it down when you're done
For the cloud VM path, we show how to launch a hardened OpenClaw environment on AWS, GCP, Azure, or any other cloud with a single command, handling provisioning, SSH, and auto-teardown for you.
croes•1h ago
People give OpenClaw access to their online services like mails where it can also do damage.
A hardened environment doesn’t prevent those kind of damage
ziml77•1h ago
avoutic•1h ago
Wardgate acts like a drop in replacement for curl with full access control at the url / method / content level, so you can allow specific curl access to specific APIs but prevent all other outbound connections. That's what I use for my PA agent. She's very limited and can't access the open internet. Doesn't need it either
leptons•58m ago
alt187•1h ago
avoutic•1h ago
1 https://github.com/wardgate/wardgate
markb139•1h ago