zlacker

[return to "OpenClaw – Moltbot Renamed Again"]
1. woodyl+7o[view] [source] 2026-01-30 09:25:20
>>ed+(OP)
My biggest issue with this whole thing is: how do you protect yourself from prompt injection?

Anyone installing this on their local machine is a little crazy :). I have it running in Docker on a small VPS, all locked down.

However, it does not address prompt injection.

I can see how tools like Dropbox, restricted GitHub access, etc., could all be used to back up data in case something goes wrong.

It's Gmail and Calendar that get me - the ONLY thing I can think of is creating a second @gmail.com that all your primary email goes to, and then sharing that Gmail with your OpenClaw. If all your email is that account and not your main one, then when it responds, it will come from a random @gmail. It's also a pain to find a way to move ALL old emails over to that Gmail for all the old stuff.

I think we need an OpenClaw security tips-and-tricks site where all this advice is collected in one place to help people protect themselves. Also would be good to get examples of real use cases that people are using it for.

◧◩
2. rizzo9+wT3[view] [source] 2026-01-31 11:49:36
>>woodyl+7o
I ran into the same concerns while experimenting with OpenClaw/Moltbot. Locking it down in Docker or on a VPS definitely helps with blast radius, but it doesn’t really solve prompt injection—especially once the agent is allowed to read and act on untrusted inputs like email or calendar content.

Gmail and Calendar were the hardest for me too. I considered the same workaround (a separate inbox with limited scope), but at some point the operational overhead starts to outweigh the benefit. You end up spending more time designing guardrails than actually getting value from the agent.

That experience is what pushed me to look at alternatives like PAIO, where the BYOK model and tighter permission boundaries reduced the need for so many ad-hoc defenses. I still think a community-maintained OpenClaw security playbook would be hugely valuable—especially with concrete examples of “this is safe enough” setups and real, production-like use cases.

[go to top]