Skip to content

agent-ruler-approval-gates.md

Latest commit

 

History

History
68 lines (58 loc) · 4.13 KB

agent-ruler-approval-gates.md

File metadata and controls

68 lines (58 loc) · 4.13 KB
Raw
title Agent Ruler for OpenClaw: Approval Gates and Audit Receipts for Safer Agent Workflows
slug agent-ruler-approval-gates
summary Adds deterministic policy enforcement, approval gates, and audit receipts around OpenClaw runs so local agents can work with less blast radius and clearer operator visibility.
whatItDoes Runs OpenClaw behind Agent Ruler to confine workspace actions, gate risky boundary crossings, and surface approvals plus receipts in a local control panel.
category operations
difficulty advanced
tags
approval-gates
audit-trail
security-governance
telegram-bridge
prompt-injection-defense
targetUser
Platform engineers
SRE teams
Self-hosted operators
skillsUsed
updatedAt 2026-03-22
published true

What it does

  • Puts OpenClaw behind a deterministic reference monitor and confinement runner instead of relying on model judgment for enforcement.
  • Separates work into zones such as workspace, shared-zone, system-critical, and secrets to reduce accidental damage.
  • Adds approval gates for risky boundary crossings including network access, export or delivery actions, privilege elevation, and sensitive writes.
  • Exposes approvals, receipts, policy views, and runtime status in a local control panel, with an optional Telegram bridge for approval flows.
  • Lets operators keep the gateway local-first while still reviewing important actions without watching every step in real time.

Skills You Need

Pain Point

OpenClaw is most useful when it can touch real files, tools, and external services. That same power increases the blast radius of prompt injection, bad tool choices, and unattended automation. Without an external control layer, operators often end up choosing between weak autonomy and weak safety.

Core value of this case

This case adds a governance layer around OpenClaw without turning every task into manual babysitting. Normal workspace operations stay fast, while higher-risk actions become explicit, reviewable, and auditable. The result is a more production-friendly setup for local agent workflows.

Typical scenarios

  • Running OpenClaw on a personal workstation or home server where sensitive files and accounts live nearby.
  • Keeping a Telegram-first operating model while routing risky approvals back through a controlled surface.
  • Allowing long-running automations to prepare files in a workspace, then gating delivery or export to the real destination.
  • Operating multiple local agent runners but wanting one consistent boundary model and approval workflow.

How to setup

  1. Prepare a Linux host with bubblewrap installed and a working OpenClaw setup outside Agent Ruler first.
  2. Install Agent Ruler from the latest release, then run agent-ruler init to create its managed workspace.
  3. Run agent-ruler setup and import or configure the OpenClaw runner wiring.
  4. Start OpenClaw through Agent Ruler with agent-ruler run -- openclaw gateway.
  5. Open the local control panel at the URL printed in the terminal. The documented fallback is http://127.0.0.1:4622.
  6. Keep the gateway local-only by default, then optionally enable Telegram or Tailscale-assisted remote access during setup.

Related Links

FAQ

Does this replace OpenClaw's own sandboxing?

No. It adds an external governance layer around the runner. The project explicitly positions itself as damage reduction, not a perfect guarantee.

Does every agent action require approval?

No. The documented model is that normal workspace work stays fast, while risky boundary crossings move to allow, deny, or pending_approval.

Is Telegram required?

No. The canonical operator surface is the local control panel. Telegram is optional for approval and channel workflows.