This person had her inbox almost entirely deleted because she trusted an AI agent running via OpenClaw.
What could one do differently to prevent that?
👉 Separate read and write permissions - Grant the agent read-only access by default. Require explicit, scoped write permissions per action, no blanket access.
👉 Make "confirm" instructions stateless and redundant - Encode confirmation requirements at the tool/API level, not just in the prompt that could be lost when context is truncated.
👉 Limit blast radius by default using, say, "--max X" flags and imposing rate limits or delayed actions. Set hard caps at the infrastructure layer, instead of via prompting.
👉 Any destructive action should have a mandatory dry-run output reviewed by the user before execution is unlocked.
👉 Interrupt mechanisms - "Stop" messages sent via chat are not reliable. A proper kill switch needs to be at API-level instead of another message the agent may or may not process in time.
👉 Ask AI to generate a script that accesses Google Inbox via API - the script becomes a controlled interface - the agent can only do what the script exposes, instead of everything the API permits.
👉 Adversarial reviewer: ask a different AI to validate or add safeguards on that same script to prevent mass deletes.
👉 Instruct the agent to use the script instead of granting it direct access.
So all of that is kind of establishing a "capability firewall". It would be an auditable API between the agent and the system.
This should come conceptually close to how OS kernels work: user-space programs don't get direct hardware access, they call controlled "syscalls".
