Docs/Concepts

Guardrail escape rate

v1 roadmap

On the v1 roadmap, not in the POC you install today. The headline metric. The percentage of scanner findings that should have been caught at pre-write verification but weren't. It quantifies how good your guardrails are, where they're weakest, and whether they're improving over time.

01

Definition

Take all scanner findings ingested in a window. Count the ones whose correlated_threat was predicted at design review. Of those, count the subset where no Layer 2 guardrail blocked the write. Divide. That's the escape rate.

flowrailv0.4.2
escape_rate = ( findings_with_predicted_threat_AND_no_blocking_guardrail )
              ÷
              ( findings_with_predicted_threat )

  example: 14 escapes ÷ 102 findings linked to a prediction  →  13.7%
02

Why it's the metric

Scan pass rates conflate "we don't have a problem" with "we don't see a problem." Total finding count rewards noisy scanners. Escape rate isolates the failure mode that actually matters: the prediction was right, the threat was real, and the guardrail still missed the write. Lower escape rate = your guardrails are doing their job. Rising escape rate = a new attack pattern is sneaking past you.

Per-category breakdownv0.4.2
Category                     30d escape rate    Δ vs prior 30d
  injection                   8.2%               −1.4 pp
  secret_exposure             0.4%               −0.2 pp
  scope_escalation            21.3%              +6.1 pp   ⚠
  dependency_supply_chain     2.1%               flat
  cryptographic_weakness      4.8%               −0.6 pp
03

What you do with it

When a category climbs, the Triage & Feedback agent has already drafted candidate guardrail tightenings against the escape findings; the dashboard surfaces them with replay-test results from the last 30 days of writes. You decide whether to merge, modify, or defer. The metric closes the loop between findings, guardrails, and outcomes.