Remit

Built on VAOM (CC BY 4.0), by the VAOM authors.

Remit is personal agent authority for OpenClaw. You decide, in plain terms, what your agent may do on its own, what it must ask you about first, and what it may never do. Remit enforces that at the tool layer — not in a prompt — and records every decision as it happens.

Status: v0.3. Enforcement core, anti-pattern detectors, local dashboard, confidence transport, first-run wizard, deny cooldown, per-agent tier layers, job grants, config tamper-evidence, and self-protection of the authority surface — built, tested (229 tests), and dogfooded against a live multi-agent build. Wrapper/scene decomposition for home control lands with Home Assistant support.

The dashboard (demo data): two anti-pattern detectors firing, and the thesis on a card — confidence 0.99 next to resolved: deny. High belief never manufactures authority. Rendered as code (SVG), like every Remit visual.

The model

Three tiers, set per action category by you:

The one rule that makes this different from a plain allow/deny engine: confidence is not authority. The agent may report how sure it is, and Remit records that signal — but a 99%-confident request to do a Never action is still blocked. High belief never manufactures permission. On the decision log you see confidence: 0.99 and outcome: blocked side by side, which is the whole point.

How it enforces

Remit registers on OpenClaw's real enforcement seams, so a prompt injection or a persuasive argument cannot route around it:

• remit-never trusted tool policy — runs before any ordinary plugin hook can allow an action. Never means never.
• before_tool_call hook — decides Allow / Ask, routes approvals to your channel with allow-once and deny only (no standing approvals until the runtime can guarantee them), and fails closed: engine error, missing config, or an unmapped tool in strict mode all become Ask, not Allow.
• Decision log — every decision writes one vaom.decision/0.1 record: what the agent wanted, its stated confidence and reason, the tier it hit, the outcome, and for asks the resolution and latency.

Tools are grouped into human categories (send messages as me, spend or move money, change my files, run commands, change settings or permissions, read my private data, …) so you set tiers over things you care about, not over tool names. The category-to-tool map is versioned against the OpenClaw tool catalog it was written from.

Job grants: autonomy without rubber-stamping

An autonomous job — a software build, a batch migration — is thousands of file writes and shell commands. Routed through Ask, you get flooded, start rubber-stamping, and then turn the tool off. Remit's own Review Queue Flood detector names that failure; grants fix it (and when the flood detector fires, it now offers you the grant it thinks you're implicitly making):

/remit grant modify-files,run-commands scope:~/Builds/lm agent:builder for:2h reason:"LM build"

A grant converts specific Ask-tier categories to Allow for one agent, one path scope, one time window — then expires on its own. While it runs you get periodic digests instead of per-action prompts, every granted action is recorded (unattended: true, traceable to the grant id), and /remit revoke ends it early with a closing digest. The invariant, enforced by code placement rather than by a check that could be forgotten: a grant only ever converts Ask to Allow. It can never touch Never. The trusted remit-never policy runs before the grant layer exists and doesn't know grants exist.

The honest part, stated up front: a path scope is a real fence for file tools — a write outside it falls back to Ask. It is not a fence for shell commands (a shell can cd anywhere), so Remit refuses scope: on run-commands instead of pretending; command grants are bounded by agent, time, and the audit trail. Blanket shapes (no scope on a file grant, or for:never) demand an explicit second confirmation, and unspecified durations default to one hour. The safe shape is the easy shape.

Tamper-evidence: the config can't change quietly

The tier map lives in openclaw.json, and no tool-layer hook can stop a process outside the agent from editing that file directly — so Remit makes sure it can't happen silently. Two mechanisms, both born from a real incident during dogfooding:

• Self-protection: any file write or shell command whose parameters reference openclaw.json or Remit's own state files classifies as change settings (default: Never) regardless of which tool carries it — a modify-files allowance or grant can't reach the authority surface. Escalation-only: it can tighten a classification, never loosen one.
• Drift detection: Remit fingerprints the authority-carrying slice of config and stamps its own writes. A change nobody stamped becomes one drift:config-changed-outside-remit record in the decision log at next load — "who changed the tiers, and when" is a log line, not a forensic dig.

How this differs from security plugins

Several good policy engines already exist on the same before_tool_call hook, aimed at production deployments and ops teams. Remit does not compete with them on the security axis. They answer "is this action allowed by the org's rules" — security blocks known-bad and malicious actions, and they assume a technical operator writing policy. Remit is an intent tool: it answers "did the person who owns this agent decide it may do this." It assumes a non-technical owner, ships a guided first run instead of a policy file, and carries a design vocabulary — the tier model, the confidence-versus-authority distinction, and named calibration anti-patterns you can watch fire on your own traffic.

Security posture

A tool whose entire pitch is authority has to be visibly above reproach:

• Reads no credentials, touches no secrets file, declares the narrowest manifest surface that works.
• No network calls in the enforcement path. The decision log is local, owner-only (mode 0600).
• The log stores parameter digests and names, never raw values, so it cannot become a data-exfiltration target. What the owner sees in an approval prompt is richer — the deciding authority deserves disclosure — but that detail is ephemeral and never written to the log.
• Fails closed everywhere: missing config, engine errors, unmapped tools in strict mode, unresolved approvals, undecomposable wrappers — all land on Ask or deny, never on silent allow. Recording failures never change an enforcement outcome.
• Small and readable in one sitting. One runtime dependency (typebox). No vendored blobs, no telemetry.
• The security pass is executable: src/security.test.ts fails the build if source ever gains an outbound network call, a process.env read, a spawned process, a credential-field reference in the config writer, or a wider manifest surface. Claims you can rerun beat claims you have to trust.

Gate your installs. OpenClaw's security.installPolicy lets you run a trusted local command that approves or blocks every skill and plugin install — including this one — and fails closed if the policy is unavailable. If you run an always-on agent, enable it. We would rather you audit Remit before trusting it than install it on faith; the code is deliberately short enough to do that.

Install

From ClawHub, on the OpenClaw host (Node >= 22.19, OpenClaw >= 2026.6.11):

openclaw plugins install clawhub:@verkflode/remit
openclaw gateway restart

Or from source, if you'd rather audit first (we encourage it):

git clone https://github.com/verkflode/remit
cd remit
pnpm install
pnpm test        # full suite, including the executable security pass
pnpm run build && pnpm pack
openclaw plugins install ./verkflode-remit-0.3.4.tgz
openclaw gateway restart

Two host settings to check:

• Pin trust: add "plugins": { "allow": ["remit"] } to openclaw.json so only explicitly trusted plugins load. (If you already use plugins.allow, just add "remit" — the allowlist is exclusive.)
• Tool profile: the remit_intent confidence tool is a plugin tool, and profiles like coding exclude plugin tools entirely. Run tools.profile: "full", or accept that enforcement works but confidence reporting stays empty. Never add plugin tools via tools.allow — that key replaces your whole profile.

Setup

Message your agent's channel as the owner:

/remit setup

Nine plain-language questions, one per area of your life, conservative defaults offered first. Nothing persists until the last answer; /remit cancel aborts. Afterwards: /remit status shows your tiers, /remit set <area> <allow|ask|never> changes one. Categories you set to never that map to whole tools are also structurally denied (tools.deny) — the model never even sees those tool schemas, and Remit reconciles its own deny entries when you soften a tier later.

Approvals arrive on the same channel: each one shows what the agent wants to do (command excerpt, file path, recipient), the rule that matched, and the agent's own declared confidence and reason — or a flag that it declared nothing. /approve allows once; /deny stands: repeats of a denied tool are auto-blocked for a cooldown (default 2 minutes) instead of asking you again.

For autonomous jobs: /remit grant <areas> [scope:<path>] [agent:<id>] [for:<duration>] [reason:"…"] pre-authorizes the batch, /remit grants lists what's live (with countdowns and usage), /remit revoke <id|all> ends one. The wizard teaches this at setup so the first flood never has to happen.

Dashboard

The gateway serves the dashboard at /remit, loopback-only by default. From another machine, tunnel:

ssh -N -L 18789:127.0.0.1:18789 <user>@<host>

then open http://127.0.0.1:18789/remit and paste your gateway token once (from gateway.auth.token in openclaw.json; it's stored in your browser and sent only as an Authorization header — deliberately never in a URL). You'll see the five detector lights and every decision: what the agent wanted, how sure it said it was, and what actually happened, side by side.

Lineage

The authority model — the tiers, the confidence-versus-authority distinction, the calibration anti-patterns — descends from VAOM and is credited plainly here. Past that credit, Remit is its own tool, judged on its own job: keeping a person in control of what their agent does. It is not a demo of VAOM and not a smaller VAOM. The decision record schema (vaom.decision/0.1) keeps the shared namespace on purpose: the brand is the product's, the decision language is the family's.

License

• Plugin code: MIT
• VAOM-derived design content (the authority model, tier definitions, anti-pattern names): CC BY 4.0