Build the exception path before you need it: a named approver, a narrow scope, an expiry, and a record. Then an urgent fix can ship in minutes while the gate stays on for everyone else. Switching a gate off for the incident is the failure to avoid.
Why gates get disabled
A gate that blocks an urgent security patch will be bypassed by someone, under pressure, in whatever way is fastest. If the fastest way is to delete the policy, you lose the control and the evidence at the worst moment. A designed exception path is faster than the bad path, so people use it.
What an exception should look like
| Property | Good design | Weak design |
|---|---|---|
| Scope | One workload, one namespace or one rule | The whole cluster |
| Duration | Hours or days, with an expiry that removes it | Open ended |
| Approver | A named role who is not the requester | The requester |
| Record | Ticket, reason, approver, times | A chat message |
| Visibility | Shows in audit logs and a weekly report | Silent |
Two Kubernetes features help. Validation actions let a policy binding warn and audit instead of deny, so you can narrow an exception to a warn-only binding for one namespace. And the audit policy records who changed bindings and exemptions, if you log those resources.
A step by step procedure
- The requester files the reason, the artifact and the rule that blocks it.
- The approver checks whether a quicker fix exists, such as correcting the manifest.
- If the exception is justified, apply a narrow exemption, for example a binding for that namespace set to warn and audit, with an expiry date in the ticket and a calendar reminder.
- Deploy the fix and verify it.
- Remove the exemption as soon as the deploy is done, not at the expiry.
- Review the exception in the next weekly sync. Ask whether the rule needs changing.
Protect the exemption mechanism
An exception path is a target. Restrict who can create or edit policy bindings and exemption labels with RBAC, and alert on changes. Anyone who can add an exemption can switch off the control, so the group should be small and the changes visible.
Measure the exceptions
Track the number of exceptions per month, how long each lasted, and which rule caused them. A rule with frequent exceptions is either wrong or hard to meet. Fix the cause: improve the rule, give developers tooling to meet it, or move it to warn mode. A steady stream of approved exceptions is a sign the gate is losing credibility.
Practice it
Run a drill each quarter with a harmless test change. Confirm the approver can be reached, the exemption works, it expires, and the evidence is complete. A procedure nobody has tried tends to fail on the day.
Where Safeguard fits
Safeguard's policies, gates and guardrails and its compliance and evidence automation support documented exceptions with a record of who approved what. Autonomous remediation, which is off by default with every category on Manual, can prepare fix pull requests so urgent patches reach the gate sooner.
Quick check
Should the person who needs the exception approve it?
No. Use a different approver so the decision has a second set of eyes.
When should the exemption be removed?
Right after the fix is deployed and verified, rather than waiting for the expiry.
Sources
Last reviewed: 19 October 2026.
