Rule Await Approval Before Mitigation
system-sync· noviceslug: rule_await_approval_before_mitigation element_type: RULE mutability: LOCKED inline: true current_version: 0 status: seed-draft contentURI: null implements_principles: [human_approval_for_destructive, defensive_only] uses_terms: [incident, response, asset]
Any mitigation action under this Sub-Leviathan that would block, quarantine, isolate, delete, or revoke capability from any system, account, asset, or participant MUST be queued in a pending-approval state until an approver holding at least guardian standing (inherited from meta) records explicit approval in the action's audit trail. The audit record MUST include: action identifier, target identifier, action class, evidence references (incident or vulnerability ID being mitigated), proposed effect, approver identity, approval timestamp. Pre-authorized actions (per principle:human-approval-for-destructive's pre-authorization clause) bypass the queue only if their pre-authorization is itself a ratified constitutional element citable in the audit trail. Tooling MUST refuse to execute mitigation actions without a valid audit record.
Status
Seed-draft, no personal attribution. Cyber Security Sub-Leviathan opening set (2026-05-16). LOCKED because operationalizing the human-approval principle requires structural enforcement that cannot be quietly weakened.
What this rule operationalizes
principle:human-approval-for-destructive defines the boundary. This rule turns that boundary into a check that tooling enforces: every mitigation has an audit record before execution, or it does not execute.
Required audit record fields
| Field | Notes |
|---|---|
action_id | Unique per action instance |
target_id | The asset/account/system/participant being mitigated against |
action_class | block / quarantine / isolate / delete / revoke / (other) |
evidence_refs | Array of incident or vulnerability IDs justifying the action |
proposed_effect | Concrete description ("revoke API key XYZ", "isolate host abc.local from network") |
approver_id | Participant identity, must hold at least guardian standing |
approval_timestamp | ISO-8601 |
pre_authorization_ref | (Optional) Cite the constitutional element that pre-authorized this class if applicable |
A record missing any required field is invalid. Tooling refuses execution.
Why a record-based gate, not a UI-based confirmation
A UI confirmation ("Are you sure? [Yes/No]") is too easy to click through. A required audit record forces the approver to provide the evidence reference and acknowledge the target — this surfaces context and slows the action just enough to catch errors. The audit record also serves the post-incident review function: every mitigation, even mistakes, is traceable.
What this rule does NOT gate
- Detection, monitoring, alerting, evidence collection
- Communication actions (notification of operators, opening tickets)
- Read-only investigation (querying logs, snapshot capture)
- Preparation work (drafting a mitigation, queuing it for approval)
These remain unconstrained. The gate is at execution of capability-removal only.
Pre-authorization pattern
A federation may pre-authorize certain mitigation classes through proposal lifecycle (inherited from meta). Example:
Proposal: "Auto-revoke any AWS API key whose use pattern matches indicator-of-compromise IOC-XXX."
If ratified, automated tooling may execute matching revocations without per-instance approval — but the audit record still cites the pre-authorization element. The pre-authorization is the constitutional act; per-instance executions are the operational acts under it.
This prevents the "fast path" from becoming an undocumented exception. Every fast path traces back to a ratified rule.
Failure modes this rule prevents
- Over-eager automation. Detection-only tooling sometimes acquires mitigation capability through feature creep. This rule severs that path at the constitutional level.
- Mass false-positive blast. A single broken classifier could otherwise block thousands of legitimate users. The approval gate provides last-look review.
- Adversarial misdirection. Attacker triggers defender's automated revocation against a target the defender intends to protect. Approval gate provides verification of context.
Sub-Leviathan inheritance
LOCKED. Instances cannot weaken (cannot remove the audit record requirement or lower the approver standing). Instances may strengthen (require multiple approvers, require senior standing for high-classification assets, add cooling-off period).
Related elements
principle:human-approval-for-destructive— the principle operationalizedprinciple:defensive-only— the orientation that bounds mitigationterm:incident,term:response,term:asset— the operational vocabulary- Inherited from meta:
term:standing(guardian threshold),rule:proposal-process(pre-authorization lifecycle)
Awaiting domain author
Tooling implementation (which audit logger, which approval UI, which integration with existing security tools) is instance-specific. The constitution sets the requirement; instances define implementation.