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:
- A new policy defaults to
monitor— it records what it would have done
and changes nothing.
CLAWMETRY_POLICY_ENFORCE=0is the default, and one environment variable
disables every policy on a node.
- 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.
| Surface | Gate |
|---|---|
| Manual control — you press Pause/Stop/Kill | Not entitlement-gated: you made the call. Origin-checked. |
| Autonomous policy — a Guard policy fires | The three locks above |
| Pre-tool gates — hold an action before the tool runs | Requires a runtime hook, and configuration |
| Cron management via gateway RPC | Explicit 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.
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.
Where to start#
The eight signals, what each one means, and its evidence.
PoliciesMatching, actions, escalation ladders and the durable latch.
Process controlWhat pause, stop and kill actually do, per OS and runtime.
Enforcement proxyBudgets and in-flight loop detection.
Roll it out in the order in Your first week: watch the detectors, read the dry-run log, and only then turn enforcement on.