Block when a failure is clear, high impact and cheap to fix. Warn when a rule is new or noisy and you need data. Require approval when a person must weigh context a rule cannot see. Most mature gates use all three, and move each rule from warn to block as its false positives fall.
The three outcomes defined
A block stops the change. A warn lets it through and tells someone. An approval pauses the change until a named person or team agrees, and records who did.
Kubernetes shows the pattern in its own controls. The ValidatingAdmissionPolicy documentation lists Deny, Warn and Audit as validation actions, and Pod Security admission offers enforce, audit and warn modes per namespace. GitHub environments add required reviewers, with an option to prevent users from approving runs they triggered.
A decision table
| Question about the rule | If yes | Outcome |
|---|---|---|
| Is it clearly wrong every time, such as a privileged container in production? | Rarely has a legitimate exception | Block |
| Is the rule new or untested against your real workloads? | You do not know the false positive rate | Warn and audit |
| Does the right answer depend on business context, such as a one off exception? | A human must decide | Approval |
| Is the fix hard or slow for most teams? | Blocking will create a pile of exceptions | Warn with a deadline |
| Is the change easily reversible? | Cheap to undo | Lean toward warn |
| Is the change hard to undo, such as data deletion or public exposure? | Costly mistake | Lean toward block or approval |
How to promote a rule
Every rule should follow the same path, so developers know what to expect.
- Start in warn and audit mode on one team or environment.
- Count how often it fires, and how often the firing was wrong.
- Fix the rule for common false positives, and fix workloads for the true ones.
- Announce a date when it becomes a block.
- Switch it, and keep the audit trail.
Skipping step 2 is the usual cause of blocked releases on a Friday and a gate that is switched off by Monday.
Design the approval path properly
An approval is only useful if it is more than a click. Decide who can approve, make the approver different from the person who triggered the change, and show them the evidence, such as the finding, the affected component and the reason for the exception. Time limit it. GitHub's documentation shows both a wait timer and a prevent self review option, which map onto those habits.
Avoid a design where approval is the default path for everything. People stop reading, and the approval becomes a rubber stamp.
Record the outcome
Whichever outcome fires, write it down: rule, version, decision, who, when. That record is also your evidence when an auditor or customer asks how releases are controlled.
Where Safeguard fits
Safeguard's policies, gates and guardrails let you set the outcome per rule, so a new check can start informational and tighten later. Compliance and evidence automation keeps the record of those decisions.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a failing check changes what a reviewer can do.
Quick check
Is warn mode just a weaker block?
No. It is a measuring step. Its job is to tell you the false positive rate before a rule can stop work.
When is approval better than a block?
When the right answer depends on context a rule cannot see, such as a time limited exception that someone must own.
Sources
- Kubernetes Validating Admission Policy
- Kubernetes Pod Security Admission
- GitHub: managing environments for deployment
Last reviewed: 19 October 2026.
