Hacker News Reader

Comment by Tharre | Hacker News Reader

I don't get it. The point of OpenClaw is it's supposed to be an assistant, helping you with whatever random tasks you happen to have, in natural language. But for that to work, it has to have access to your personal data, your calendar, your emails, your credit card, etc., no?

Are there other tasks that people commonly want to run, that don't require this, that I'm not aware of? If so I'd love to hear about them.

The ClawBert thing makes a lot more sense to me, but implementing this with just a Claude Code instance again seems like a really easy way to get pwned. Without a human in the loop and heavy sandboxing, a agent can just get prompt injected by some user-controlled log or database entry and leak your entire database and whatever else it has access to.

View on HN

Yes and even now if you tell the LLM any private information inside the sandbox it can now leak that if it gets misdirected/prompt injected.

So there isn't really a way to avoid this trade-off you can either have a useless agent with no info and no access. Or a useful agent that then is incredibly risky to use as it might go rogue any moment.

Sure you can slightly choose where on the scale you want to be but any usefulness inherently means it's also risky if you run LLMs async without supervision.

The only absolutely safe way to give access and info to an agent is with manual approvals for anything it does. Which gives you review fatigue in minutes.

I don't follow your argument about getting pwned.

A user could leave malicious instructions in their instance, but Clawbert only has access to that user's info in the database, so you only pwned yourself.

A user could leave malicious instructions in someone else's instance and then rely on Clawbert to execute them. But Clawbert seems like a worse attack vector than just getting OpenClaw itself to execute the malicious instructions. OpenClaw already has root access.

Re other use cases that don't rely on personal data: we have users doing research and sending reports from an AgentMail account to the personal account, maintaining sandboxing. Another user set up this diving conditions website, which requires no personal data: https://www.diveprosd.com/

> But Clawbert seems like a worse attack vector than just getting OpenClaw itself to execute the malicious instructions. OpenClaw already has root access.

Well the assumption was that you could secure OpenClaw or at least limit the damage it can do. I was also thinking more about the general usecase of a AI SRE, so not necessarily tied to OpenClaw, but for general self hosting. But yeah probably doesn't make much of a different in your case then.

You can solve that by requiring confirmation for anything except reading information from trusted sites. Web visits can be done without confirmation by reading a cached copy and not executing any JavaScript on it with network access (otherwise visiting arbitrary sites can leak information via the URLs sent to arbitrary servers)

Reply on news.ycombinator.com