Add guardrails and human approvals to OpenClaw

Key takeaways

• OpenClaw is a personal AI assistant that acts autonomously in the background; its guardrails already decide whether a command stops.
• The enforcement is out-of-process on the execution host, so a guardrail here is not a prompt the assistant can reason around.
• What OpenClaw does not give you: role routing, quorum, SLA escalation, or a signed evidence packet - and its audit ledger keeps 30 days and no command bodies.
• Deny the assistant authority to loosen its own rules: privileged config, host-owned policy files, and human-reviewed skill changes keep it from teaching itself past the gate.
• Route approvals from many assistants into one Contro1 queue, and keep askFallback set to deny so a missing reviewer means denied, not run.

What OpenClaw already gives you

OpenClaw is an open-source personal AI assistant that runs on your own machine, answers on the channels you already use, keeps persistent memory, browses, runs shell commands, and works autonomously in the background. It is not ungoverned. Its exec tool has five permission modes: deny (block host exec entirely), allowlist (run only allowlisted commands, silently deny misses), ask (run allowlist matches, ask a human on misses), auto (run allowlist matches, send misses through an auto-reviewer before falling back to a human), and full (run without prompts).

When a command needs approval, OpenClaw holds it pending and broadcasts it to operator surfaces: the Control UI, the macOS app, native chat approvals, and a same-chat /approve command. Crucially, that gate is enforced on the execution host, not in the model - the assistant can only request a command, it cannot run it around the gate. OpenClaw also binds each approval to a canonical systemRunPlan, so a caller that changes the command, cwd, or session after approval is rejected as a mismatch, and it keeps a metadata-only audit ledger of runs and tool actions.

That is a solid runtime foundation. The gap is organizational, not mechanical.

• Permission modes decide whether a command stops.
• Enforcement is on the host, so it is not a prompt the assistant can talk its way past.
• Exec approvals hold a command pending for up to 30 minutes.
• systemRunPlan binds an approval to one exact command.
• askFallback decides what happens when no approver is reachable.

Where OpenClaw guardrails stop

OpenClaw answers "should this command stop, and did someone press approve?" It does not answer the questions an enterprise asks next.

Who is the right approver for this action, and what if they are offline? Does a high-value action need two approvers? What happens when a decision is missed for an hour? And months later, can you produce a signed, tamper-evident record of who approved what, bound to the exact command and the agent that proposed it?

• No role-based routing or on-shift coverage: whoever is watching the chat approves.
• No quorum or separation of duties for high-risk actions.
• No SLA deadlines or escalation when a decision is missed.
• The audit ledger is metadata-only, retains 30 days, is capped, and stores no command bodies, tool args, or results.
• No signed evidence packet you can hand to an auditor.

The division of labor with Contro1

Keep OpenClaw doing what it is good at: deciding an action needs approval and holding it pending. Let Contro1 own the decision: route it to the right human, enforce role, quorum, and SLA, and keep signed evidence.

The connection point is an external bridge that runs as an OpenClaw operator client, outside the gateway process. It watches for pending approvals, creates a Contro1 request, waits for a signed decision, verifies it, and only then resolves the approval in OpenClaw.

Make the guardrail one the assistant cannot bypass

A self-improving assistant can reason around an instruction, so a guardrail written into the prompt is only a suggestion. The durable version is enforced outside the model and denies the assistant any way to loosen it.

OpenClaw already enforces exec approvals on the execution host. To close the rest of the loop, take away its authority to change the rules.

• Effective exec policy is the stricter of config and the host approvals file, and an approval can only tighten it - keep that file owned by the host, not writable from the assistant workspace.
• Config mutation and reserved namespaces require operator.admin; the assistant session should not hold it, and policy changes should themselves route through approval.
• Set skills.workshop.approvalPolicy to pending so the assistant drafts skill proposals for human review instead of rewriting its own instructions to grant new powers.
• Let the approval bridge hold the approvals credential, not the assistant, and keep askFallback at deny so removing the reviewer closes the gate.

Why a separate review surface, not just chat

If you talk to the assistant in WhatsApp, it is tempting to approve there too. But the assistant runs in the background and takes many small actions on its own; a ping per action trains you to rubber-stamp, and babysitting the thread defeats the point of delegation.

You want two things at once: to be interrupted only for the few actions that need an accountable, signed decision, and to have a complete record of everything else. A chat reply is a casual ok. A Contro1 approval is signed, time-stamped, role-attributed, and evidence-bearing - the right instrument when the action moves money, changes access, or cannot be undone. A native chat approval surface can come later; the value of a signed decision and an audit trail is the same regardless of where the button lives.

One reviewer, many assistants

OpenClaw is self-hosted, so people end up running several: one per person, project, or device. Each is autonomous and each occasionally needs a human. Separate chat threads do not scale to that.

Point every instance at the same Contro1 organization and their approvals land in one queue. One reviewer or a rota clears them all, role routing sends each decision to its real owner no matter which assistant raised it, and evidence for every instance is searchable in one place.

• Every assistant's approvals arrive in one queue.
• Role routing and quorum apply across instances, not per chat.
• On-shift coverage and SLA escalation mean no approval waits on one person.
• A single, unified audit trail spans all of your assistants.

Choose the approval boundary

Do not send every command to a human; that trains reviewers to rubber-stamp. Reserve approval for actions that move money, change access, write to production, deploy, delete data, exfiltrate secrets, or run code fetched from the internet.

In OpenClaw terms: set exec mode to ask (or auto with a conservative allowlist) so those actions actually pause, and let low-risk reads run. The bridge then classifies each pending approval into block, auto-allow, or require-approval before a human is ever paged.

• Block the unambiguously destructive shapes (rm -rf /, fork bombs, mkfs) before a reviewer sees them.
• Require approval for sudo, ssh, cloud CLIs, kubectl, terraform apply/destroy, git push, npm publish, and secret access.
• Auto-allow only patterns you explicitly trust, and never in a production session.

Reviewer context you can trust

A reviewer can only make a good decision from facts they can trust. Separate what OpenClaw observed from what the agent said about itself.

Machine-observed facts - the captured command, argv, cwd, agent id, and session - are what drive risk and routing, and what the approval is cryptographically bound to. The agent's own justification is useful color for the human, but it never changes the risk level or the routing, and it is never part of the binding. An agent cannot argue its way into a lower risk tier.

Organization-in-the-loop, not a chat button

Contro1 is human-in-the-loop done right, and then it goes further: it puts the whole organization in the loop. The same risky OpenClaw command now lands with whoever would have owned that decision anyway, routed by role, covered across shifts, escalated on a missed SLA, and requiring a quorum when the stakes justify it.

The agent still does the work: gathering context, preparing the command, moving the session forward. The accountability and the final call stay with the people who owned them before agents entered the process.

Minimal implementation flow

• Deploy the OpenClaw connector bridge as an operator client with an operator.approvals-scoped token.
• Set tools.exec.mode to ask and keep askFallback set to deny.
• Let the bridge poll openclaw approvals pending and create a Contro1 request per sensitive approval.
• Route by role and risk in Contro1; add quorum for high-value actions.
• Resume only from a verified signed callback, and re-check the action binding before resolving.
• Read approved, denied, auto-allowed, and blocked events back from the audit trail.

Open the OpenClaw human approval connector

This pattern is reusable

The shape here is not specific to OpenClaw. Any agent runtime that can pause before a side effect - LangGraph, the OpenAI Agents SDK, Claude Code, a broker or trading MCP - maps onto the same three moves: stop at the boundary, route the decision to the right human with trustworthy context, resume only from a verified, bound approval. The runtime-specific part is only how you detect the pause and apply the decision.

Human-in-the-loop for AI agents · Agent trading approvals

Frequently asked questions

Does OpenClaw need Contro1 if it already has exec approvals?

OpenClaw decides whether a command stops and lets someone press approve. Contro1 adds who the right approver is, on-shift coverage, quorum for high-risk actions, SLA escalation, and a signed evidence packet. Use OpenClaw for the pause and Contro1 for the governed decision and the record.

Should the approval control be an OpenClaw plugin?

No. OpenClaw native plugins run in-process with the gateway and are not sandboxed, so a fault takes the gateway with it. Run the approval bridge as an external operator client with a token scoped to approvals.

What if the approver never answers?

Keep OpenClaw askFallback set to deny, and set an SLA in Contro1 so a missed decision escalates to a fallback reviewer. OpenClaw also expires a pending exec approval after 30 minutes and then denies the waiting command.

Can the agent talk its way into approval?

Only a human can approve, and the risk level and routing are computed from machine-observed facts, not from the agent's justification. The approval is bound to the exact command, so an agent cannot get one decision applied to a different action.

Related resources