CClawMetryDocs

Guard & governance

What Guard does#

Two halves that existed separately for a long time before they touched:

  • Detection — judge-free, CPU-cheap heuristics over the tool stream that

find agents which have gone off track.

  • Action — pause, stop or kill a real process.

Guard is the wire between them. Before it, the only edge from detection to action was a human noticing a banner and pressing a button.

The design position#

Autonomous enforcement is a genuinely dangerous feature. A tool that can kill your agent's process, deciding on its own, is exactly the kind of thing that should be hard to turn on by accident and easy to turn off completely.

So the whole design is about how intervention is gated, not whether it exists:

  1. A new policy defaults to monitor — it records what it would have done

and changes nothing.

  1. CLAWMETRY_POLICY_ENFORCE=0 is the default, and one environment variable

disables every policy on a node.

  1. An entitlement check that fails closed.

All three must be open. A kill policy on a node with enforcement off is recorded as a dry run, exactly as a kill step in an escalation ladder would be.

The four ways ClawMetry can affect an agent#

This is the complete list. Adding a fifth means adding it here, with locks of the same strength.

SurfaceGate
Manual control — you press Pause/Stop/KillNot entitlement-gated: you made the call. Origin-checked.
Autonomous policy — a Guard policy firesThe three locks above
Pre-tool gates — hold an action before the tool runsRequires a runtime hook, and configuration
Cron management via gateway RPCExplicit action in the UI or API

Everything else — every adapter, every ingest path, every rollup — is read-only by construction.

One actuator#

Both control paths end in the same actuator. An automatic pause and a hand-pressed pause do exactly the same thing to the process, including resume, which used to bypass it.

That matters because it means there is one place where "what happens to the process" is defined, and one place to audit.

Pause, stop, kill

Capability is answered once, per session#

runtime_control_support(runtime, session_id, cwd) is the single verdict the Guard tab, the daemon and the actuator all read. Nothing re-derives it.

Three axes vary independently, and each has caused a wrong answer at some point:

  • OS — POSIX signals versus the Windows native equivalents. A Windows stop

cannot be addressed to one process; it reaches the whole console, and the UI says so.

  • Runtime, per session — a Cursor CLI session is controllable; a Cursor

editor conversation is not. Ask per session, do not refuse a whole runtime.

  • OpenClaw pause — there is no pause primitive. ClawMetry's pause is a flag

file enforced only by the enforcement proxy, so with no proxy running it is advisory and is reported as advisory_only.

A control that cannot work says why, next to a disabled button. Never one that quietly does nothing.

Severity is money#

An incident carries spend_at_risk_usd — the estimated cost of the flagged stretch, not the session — plus the spend_basis that produced it. A warning crossing CLAWMETRY_GUARD_CRITICAL_USD (default $5) becomes critical.

Where no cost is known the field is 0.0 with basis unknown, never a fabricated figure. Sorting a list by an invented dollar number is worse than sorting it by severity.

Thresholds are resolved, not hard-coded#

Four layers, each overriding the last: module defaults → the runtime profile → the cohort's learned baseline → a per-runtime environment override. Every incident carries threshold_source so a reader can tell a measured threshold from a shipped constant.

Thresholds and baselines

Where to start#

Roll it out in the order in Your first week: watch the detectors, read the dry-run log, and only then turn enforcement on.

Cookie preferences