The March 2026 OpenClaw production-database deletion became the canonical AI-agent cautionary tale of the year. A misconfigured agent, granted broad filesystem permissions, recursively wiped a real production database. The incident catalyzed an entire security sub-ecosystem around OpenClaw: sandboxing tools, runtime guardrails, permission scoping, audit logs.
The incident is not OpenClaw's fault in any meaningful technical sense. The user granted the permissions; the agent did what it was told. It is, however, the publicly-documented worst case of "autonomous agent with broad permissions on real infrastructure" as the default contract. For non-engineers picking an AI agent in 2026, the question is no longer "how powerful can I make it" but "how bounded is the worst case."
This post is the framework for thinking about that question.
Three permission models for AI agents
Three distinct shapes the industry has converged on:
1. Open permissions, audit later. OpenClaw's default. The agent has broad permissions on the user's infrastructure; the user is responsible for vetting what the agent does, ideally before but realistically after. Best case: the agent does the right thing. Worst case: the production database wipe.
2. Scoped permissions, manual approval per action. Some AI products require explicit approval for every consequential action. Best case: the user sees and approves every move. Worst case: the user fatigues on approvals and starts rubber-stamping, which collapses the model.
3. Layered permissions with graduated approval. Ajeris's approach. Routine actions (sending a text, setting a reminder) execute freely. Consequential actions (sending money, posting publicly, modifying core records) queue for approval and the user replies "do 1" to authorize. Worst case: a queued action that the user did not authorize sits in the queue and never fires.
The third model is the one that scales. It does not require the user to approve every move; it does not let the agent run with unlimited blast radius. The boundary is calibrated.
What "bounded" actually means
For Ajeris specifically:
- Per-user isolation. Every request runs in its user's database context, and row-level security limits it to that user's rows. The agent cannot reach across tenants. A bug in one user's conversation cannot spill into another user's data.
- Approval gating on consequential actions. Money movement, public posting, and similar actions queue and require explicit user approval before firing.
- Vetted built-in tools. The 21 OAuth integrations on the personal side are wired by us, audited by us, and updated by us. You do not have to vet each one.
- Custom MCP with explicit scope. When you add a custom MCP server, you authorize specific permissions; the agent does not get blanket access to the endpoint.
- Audit trail. Every action the agent takes writes to a logged trail you can review.
These are not security features in the "anti-malware" sense; they are operational design choices that bound the worst case. The point is not to prevent malicious behavior (the agent is not malicious); it is to prevent runaway behavior (the agent doing more than the user intended because the user's instructions were ambiguous).
Why this matters for non-engineers specifically
An engineer running OpenClaw with broad permissions has a higher tolerance for the operational risk because they understand it. They know what their filesystem looks like; they know what the agent is allowed to touch; they can read the audit log when something goes wrong.
A non-engineer does not have that mental model. If you grant a non-engineer's agent broad permissions and the agent does something unexpected, the non-engineer cannot diagnose what happened or recover from it. The only safe contract for the non-engineer population is one where broad permissions do not exist by default and every consequential action is gated.
This is why Ajeris's safety contract is not a feature; it is a category. The product would not work for non-engineers without it.

The Cisco skill-marketplace finding
The other publicly-documented OpenClaw safety incident is Cisco AI security's finding that a third-party skill in the OpenClaw marketplace was performing data exfiltration and prompt injection on the user without the user's awareness. The marketplace, like most community marketplaces, depends on reactive moderation rather than proactive vetting.
For users who do not read every skill before installing it (which is approximately 100% of users), the supply-chain risk is non-zero. The risk is not that the project is malicious; it is that the contract requires vetting that no realistic user is going to do.
The Ajeris contract is different by construction:
- Built-in tools are vetted before ship. No marketplace to police; we own the catalog.
- Custom MCPs are explicit. When you add one, you know it is yours; the agent does not pull tools from a community marketplace.
- Permission scoping per tool. Each tool authorizes specific scopes; broader access is an explicit choice.
If you want the breadth of an open marketplace, OpenClaw is the right pick and you accept the supply-chain trade-off. If you want vetted-and-bounded by default, the hosted contract is shaped for you.
- 1Routine actionAgent executes immediately. Sending a text, setting a reminder, looking up information.
- 2Consequential actionAgent queues with a one-line summary. "I want to send the invoice to Mary for $480; reply do 1 to confirm."
- 3You authorizeYou reply "do 1" or "skip" or "edit". Agent executes or holds.
- 4Audit trailEvery action writes to a logged trail. You can review at any time.
What this means for picking an agent in 2026
Three questions to ask before you pick the AI agent that runs your day:
-
What permissions does it have by default? Broad-by-default and engineer-vetted is OpenClaw's contract. Bounded-by-default and approval-gated is Ajeris's contract. The right pick depends on your engineering competence and your tolerance for operational risk.
-
What is the worst case if something goes wrong? "Production database wiped" is the publicly-documented OpenClaw worst case. "Queued action sits in queue" is the Ajeris worst case. Neither is theoretically perfect; one is much smaller in blast radius.
-
Who is responsible for vetting? With open marketplaces, you are. With vetted built-in catalogs, the vendor is. The right pick depends on whether you are willing and able to do the vetting yourself.
- Default contract for many open-source agents.
- Capability ceiling is high.
- User responsible for vetting tools and skills.
- Worst case: the public database-wipe story.
- Best for engineers with operational competence.
- Routine actions execute. Consequential actions queue.
- Per-user isolation; bounded blast radius.
- Vendor responsible for vetting built-in tools.
- Worst case: a queued action that does not fire.
- Best for non-engineers and engineers who want their evenings back.
Frequently asked
Did OpenClaw fix the file-deletion issue?
Is approval gating annoying?
What about the actions I want fully automatic?
Audit logs?
Self-hosted with bounded permissions?
Try it
Free to start. Text +1 (470) 821 4265. The contract is bounded by default; loosen it as you build trust.
For the head-to-head with OpenClaw, see Ajeris vs OpenClaw.


