--- title: What Guard does description: Guard detects agents that have gone off track and, only when you opt in, stops them. The detectors, the policy engine, the actuator and the three locks. keywords: AI agent kill switch, stop runaway agent, agent governance, agent enforcement policy, agent loop detection eyebrow: 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. 2. **`CLAWMETRY_POLICY_ENFORCE=0` is the default**, and one environment variable disables every policy on a node. 3. **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. → [Pause, stop, kill](/docs/guard/process-control/) ## 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](/docs/guard/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](/docs/guard/thresholds/) ## Where to start
Detectors

The eight signals, what each one means, and its evidence.

 Policies

Matching, actions, escalation ladders and the durable latch.

 Process control

What pause, stop and kill actually do, per OS and runtime.

 Enforcement proxy

Budgets and in-flight loop detection.
Roll it out in the order in [Your first week](/docs/start/first-week/): watch the detectors, read the dry-run log, and only then turn enforcement on.