Troubleshooting

When a guardrail keeps firing on the wrong line

A guardrail fires on a path the threat model considers risky but you know is safe. Three options: tighten the rule, scope the file, or update the threat model.

6 min read

Your team complains. A guardrail keeps flagging a line that's actually fine. The route is internal-only. The data is already validated upstream. The rule needs to see the wider context.

Option 1: tighten the rule

Edit the YAML. Add the upstream-validation pattern as an allow-list. The rule now fires only when validation is absent. Commit, review, merge.

Option 2: scope the file

If the path is structurally different from what the rule targets, narrow the trigger. File patterns under /internal/ may not need the same public-traffic enforcement that /api/ does.

Option 3: correct the threat model

If the model wrongly classified the trust boundary, fix it. The next refresh propagates the change. Several guardrails will retire on their own. Others will get re-scoped to the right code.

When to silence and when to fix

Silencing a guardrail is a last resort. A rule that fires noisily on safe code today catches a real bug on unsafe code tomorrow. Tightening or scoping beats silencing every time.

Want a walk-through on a shared screen?

Book a 30-minute session with our team.

Book a session