Production incident. The deploy gate is in the way. Safeguard's break-glass flow gives the on-call a tiered approval, a time-boxed bypass, a sigstore-signed audit-log entry, and a guaranteed post-incident review trigger — all without anyone disabling the policy gate by hand.
A gate that blocks a hotfix at 02:00 gets disabled by the on-call engineer. The gate goes back on the next morning, but the audit record of why it was off is a Slack scrollback nobody reads.
The pattern is well known: tiered approval based on severity, time-boxed bypass with automatic expiry, cryptographic audit entry written at the moment of the bypass, and an automatic post-mortem trigger on close. Most organisations rebuild this badly each time.
Safeguard ships the workflow as a primitive. The on-call gets the bypass; security gets the evidence; the gate stays trustworthy because it was never disabled out-of-band.
Without a structured bypass, the on-call disables the gate. The disable persists. The next deploy bypasses unintentionally. The audit becomes guesswork.
"I'll remove the exception tomorrow" is the most expensive sentence in software ops. Auto-expiry is the only durable answer.
A Slack message saying "approved" is not an audit trail. A sigstore-signed entry tied to the actor identity is.
Without an automatic trigger, the post-mortem after a break-glass either happens late or not at all. Tying it to the bypass close fixes that.
Low-impact bypasses need a single peer approval; high-impact need two designated approvers; production-database bypasses escalate to a named senior. Tiering is per-tenant policy.
Every bypass carries an explicit TTL set at approval (15 min, 1 h, 4 h). At expiry the gate snaps back to enforce; no manual re-enable required.
The bypass action writes a signed entry to the tenant audit log with actor identity, justification, scope, and TTL. Tampering after the fact is detectable.
On bypass close, a post-mortem is auto-created from a tenant template with the bypass entry, the deploys it covered, and a draft timeline pre-populated.
Engineer requests a specific gate be bypassed for a specific scope (service / branch / artefact) with a stated justification and proposed TTL.
The request routes to the right approvers per the tenant policy; designated approvers are notified out-of-band so they don't miss the page.
On approval, the bypass entry is written to the audit log signed with the approver's workload identity; the gate enters bypass mode for the specified scope.
The on-call ships the fix; every deploy under bypass is annotated in the audit log with the bypass entry ID.
At TTL the gate snaps back; any in-flight deploys revert to standard enforcement automatically.
Bypass close triggers a post-mortem from the tenant template, pre-filled with the bypass entry, deploys, and audit timeline; assignee notified.
Use with incident-response for the campaign loop, guardrails-and-enforcement for the gate primitives, and Safeguard Code for the deploy provenance link.
Configure a tenant policy in fifteen minutes and the workflow ships with the existing gates you already have.