A fail-closed security gate you enforce on your own terms - from the UI.
Every security team that has run a build gate has watched the same thing happen. The gate fires too often, on findings nobody trusts, and within a sprint someone adds the flag that skips it. The gate is still in the pipeline, still reporting green, and enforcing nothing. An over-strict gate that fails constantly does not get fixed - it gets bypassed, and a bypassed gate is worse than no gate, because it looks like coverage you do not have.
The way out is not a softer gate. It is a gate you can turn on in stages, watch before you enforce, and tune until it fails rarely but meaningfully. That is the gate teams respect, and it is the one we built around two ideas: a Monitor mode you roll out behind, and a fail-closed default you never have to argue about.
When you wire the gate into CI, it does not block on day one. It runs in Monitor mode: it evaluates the full policy against every build and records the decision it would have made, but it never breaks the build. The pipeline stays green while you watch what the gate sees. For a week, or a release, you get a precise answer to the only question that matters before enforcement - what would this gate have blocked, and would the team have agreed.
This is not a dry-run flag bolted onto a blocking gate. The same evaluation path runs in both modes; the only difference is whether the recorded decision is allowed to set the build's exit status. So the Monitor data is not a forecast of how the gate might behave. It is exactly how it will behave, captured before it can cost anyone a deploy.
When the Monitor data looks right - the blocks are real, the gaps are closed - you turn on enforcement from the UI. There is no second integration, no YAML change, no pull request against the pipeline definition. The CI job is identical before and after the flip; only the policy state changed, server-side. The same property that let you observe safely lets you enforce instantly, and roll back just as fast if a release window needs it.
That separation matters in practice. The person tuning the policy is usually not the person who owns the pipeline, and asking for a pipeline edit every time the gate's strictness changes is exactly the friction that gets gates abandoned. Decoupling the decision to enforce from the code that runs the check means security can tighten or loosen the gate without touching anyone's build file.
A gate has three outcomes, not two. It can pass, it can fail on a real violation, and it can fail to evaluate at all - the scan did not finish, a dependency was unreachable, the policy could not be resolved. Most gates treat that third case as a pass, because erroring out into a red build feels like a bug. That is the silent gap an attacker, or a rushed release, slips through: the gate that returns green because it never actually ran.
Our gate fails closed. If the decision cannot be evaluated, the build fails, and the reason is recorded in the audit trail exactly like any other block. "Could not evaluate" is a decision, not an absence of one, and it is auditable after the fact. The default is deliberately the safe one: a build never passes because the check was skipped, only because the check ran and was satisfied.
| Situation | Monitor mode | Block mode |
|---|---|---|
| Policy satisfied | Records pass | Build passes |
| Policy violated | Records the would-block, build stays green | Build fails, decision audited |
| Gate cannot be evaluated | Records the failure to evaluate | Build fails closed, decision audited |
The whole rollout - observe in Monitor, flip from the UI, fail closed - exists to make one thing affordable: a gate narrow enough that a failure means something. When the gate only fails on findings the team already agreed are real, a red build is a signal, not noise, and nobody reaches for the bypass flag. That is only possible because the engine raises findings on proof rather than heuristics, so the queue the gate enforces against is one developers trust in the first place.
A gate is a social contract as much as a technical control. Monitor mode is how you earn the team's agreement before you spend their build time; the UI flip is how you keep that agreement cheap to maintain; failing closed is how you make sure the contract is never quietly void. A focused gate that fails rarely and means it will outlast a strict one every time, because the strict one gets routed around and the focused one gets respected.