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)

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/