Nothing Is Pre-Authorized Until You Can Run It

Containment authority as executable policy: five experiments against a 72-minute clock

My previous article argued for assigning containment authority before an incident. I have now encoded that model as executable policy and rehearsed it against a 72-minute clock. Four experiments exposed assumptions the design document left unstated; the fifth uncovered a defect in the code.

The short version

In an earlier article, You Cannot Approve at Machine Speed, I set out a five-tier ladder for pre-authorizing containment: decide in advance which action may be taken, against which object, at what blast radius, on what evidence, by which role, and with what audit trail and recovery path. It was a design framework. It had never been executed.

So I wrote it down in a form that runs. The 72-Minute Defense is an open-source reference implementation: a containment policy written in YAML, a Python decision engine, dry-run adapters, a hash-chained audit log, and four synthetic scenarios replayed against a 72-minute exfiltration benchmark.

Writing and testing it changed my view of the ladder in five specific ways. Each finding came from an experiment and can be reproduced from a clean clone:

1. Escalation can destroy authority you already had. Removing one rule – do what is pre-authorized now, escalate the rest – changed the fastest scenario from containment at minute 19 to no containment at all.

2. The assets you protect hardest are often the ones you have pre-authorized least. A blanket rule that crown jewels always need two approvers can mean that you have pre-authorized nothing for them, including the least disruptive and most easily reversed action in the policy.

3. In this rehearsal, detection latency and approval latency consumed the same response margin. The scenario tolerated 52 additional minutes of detection delay or an approver who took 57 minutes. Each minute of either delay removed about one minute from the remaining window.

4. One unrecognized identity ended containment entirely. Change the compromised user's domain to one absent from the asset inventory and the same scenario is never contained. The fail-safe is correct. Its operational blast radius was larger than I expected.

5. My decision record was incomplete, and the tests could not see it. When two escalation conditions fired together, the engine explained only one of them. The decision was safe, but its human-readable justification was incomplete. Fifty-seven tests did not detect that failure because none asserted that every condition identified by the engine also appeared in its explanation.

The project's threat model documented the mechanisms behind two of those findings, but not their magnitude. That magnitude is what a risk committee needs. The final defect was undocumented because I did not know it existed.

A governance model you have never executed is a hypothesis about your organization, not a control.

Why this project matters

Security operations teams already invest in SIEM, XDR, EDR, SOAR, threat intelligence, detection engineering, cloud security, identity security, incident-response playbooks, and automation. During a high-severity incident, detection alone does not confer authority. The organization must have authorized a person or system to contain the activity before the attacker reaches the objective.

The 72-Minute Defense makes that hidden dependency testable. It turns incident-response governance into an executable specification that can be reviewed by CISOs, SOC and MSSP leaders, detection engineers, incident commanders, cloud and identity teams, GRC, legal, privacy, business owners, and internal audit.

The project can be used to:

• identify containment actions that are technically possible but operationally unauthorized;
• measure the interval from decision-ready to decision-made, alongside MTTD and MTTR;
• test whether escalation preserves lower-tier standing authority;
• expose asset-inventory and dependency-mapping gaps before a real incident;
• define blast-radius ceilings, approver roles, review deadlines, and recovery paths;
• produce an auditable decision record for tabletop exercises and post-incident review;
• test how detection failures, approval delays, and missing business context affect containment outcomes; and
• connect cybersecurity risk governance to the systems that actually execute response actions.

The output serves several operating roles at once. CISOs can see where the response model will stop under pressure. SOC leaders can rehearse decision authority alongside alerts. Engineers get a testable interface among detections, policy, approvals, and actions. GRC and audit teams can examine whether stated authority produces complete, reviewable evidence.

Scope and limitations

This is a reference implementation and governance pattern. It is dry-run by default. The published policy is a fictional Example Corp template carrying template: true, which the engine refuses to arm.

Every timing result below is deterministic output from a synthetic scenario file. It does not measure any organization's real performance. I selected the detection delays and approver response times for the experiment; they were not observed in production. The scoring weights are a transparent starting hypothesis. They have not been trained on real telemetry or evaluated for false-positive performance at scale.

The vendor adapters – Microsoft Entra ID, Microsoft Defender for Endpoint, Okta, CrowdStrike Falcon, and AWS – are mock- or stub-tested. None has been validated against a live tenant, and a request preview may differ from the final API call when runtime discovery is required.

Digest attestations in the policy file make edits visible in continuous integration. They do not authenticate the people named beside them; branch protection and required review must do that. The audit chain detects modification, reordering, and deletion from the middle of the log. It cannot detect clean truncation of the tail or wholesale replacement, and it needs external anchoring before anyone claims completeness.

The project is a reference decision layer that sits alongside SOAR, SIEM, XDR, EDR, and incident-management platforms. It addresses a decision those systems often leave to a bridge call.

It does not establish compliance with any framework or regulation. Its control mappings say supports and produces evidence for; they do not say compliant.

Authority, employment law, privacy obligations, and works-council consultation are also local. A policy that automatically disables an employee's account can become a workplace-monitoring and disciplinary question before it becomes a security question. Adapt it with security, legal, privacy, human resources, and employee representation in the room.

The 72-minute number, stated correctly

Unit 42's Global Incident Response Report 2026, based on more than 750 engagements across more than 50 countries, reports that the quickest quartile of intrusions reached data exfiltration in 72 minutes during calendar year 2025, down from 285 minutes the year before. The share of incidents reaching exfiltration inside an hour rose from 19% to 22%, and identity weaknesses played a material role in nearly 90% of investigations.

Two clarifications matter because the figure is being quoted loosely.

First, 72 minutes marks a quartile boundary. Palo Alto Networks' press release calls it "72 minutes in the fastest attacks." The underlying report describes the quickest quartile, and independent coverage consistently describes it as the fastest 25% of intrusions. That makes it a planning input rather than an anecdote.

Second, the median time to exfiltration in the same dataset is two days. Using the 72-minute figure without the median context overstates the urgency and weakens the planning argument.

Designing against the quartile is analogous to sizing a building's egress for more than an average Tuesday. Capacity should account for the fast tail when the consequence of missing it is unacceptable. Roughly one intrusion in four now completes inside a window most enterprises have never timed. I use 72 minutes here as an external stress test for management, not as a prediction or service-level target.

What the policy actually says

The policy file is the artifact that matters. Everything else in the project exists to enforce or test it. It defines four execution tiers. Each carries a score threshold, permitted actions, an authority level, a written statement of accepted impact, and – where applicable – a blast-radius ceiling and mandatory review deadline.

On a smaller screen, swipe horizontally across the tables and figures or open a figure to view it at full resolution.

Four conditions escalate a plan above its tier's authority regardless of score:

• a target matching a protected pattern, such as a break-glass account, backup service principal, executive mailbox, domain controller, or ERP database;
• a target absent from the business-context map;
• a target whose criticality meets the crown-jewel floor; or
• a blast radius exceeding the tier's ceiling.

The conditions do not behave identically. Protected and unknown targets raise the authority to two-person review. Crown-jewel and ceiling checks apply only while the plan is automatic. A ceiling breach escalates to a single approver on the premise that the action was already justified and only its scope is in question. That difference looks like implementation detail. It becomes the subject of the fifth experiment.

The engine's stated constraint is that it never invents authority. Every action in a plan traces to a tier named in the policy, and every deviation should be recorded as a sentence a human can understand afterward. Experiment 5 tests that final requirement.

Reconciling the ladder with the code

The earlier article described a five-tier ladder indexed on the object: what you are acting on, what depends on it, and how long it takes to restore. The policy file describes four tiers indexed on the action: what the system is doing and how severe it is. Those are different axes.

They meet in the engine, which carries a separate authority scale: automatic, single approver, two-person approval, and manual only. The execution tiers are the severity axis. The authority values are the accountability axis. Escalation conditions are where the object model re-enters and overrides the score.

Two tiers of the five did not survive contact with the shell, for the same reason: they concern human judgment rather than machine permission. Tier 0 is an incident commander deciding to delay containment to preserve evidence or map the adversary. Tier 4 is a named individual accepting an irreversible, customer-facing, or safety-critical consequence. Neither is a state a scoring engine can enter on its own, and neither belongs inside one.

They belong in the incident-command layer above it. That is the boundary between this project and the Cyber Incident Commander Toolkit, and I did not see that boundary clearly until the code refused to hold both.

The larger gap is the object model. The ladder assumes that each object carries a verified dependency map, measured detection precision, timed reversal, and recertification date. The business-context file has none of those. It uses glob patterns to map identifiers to a criticality, service, and owner. That is a much coarser instrument, and everything in Experiment 4 follows from it.

The rehearsal

Four synthetic scenarios replay an intrusion minute by minute. Each event becomes visible after a detection delay representing pipeline latency. The engine re-scores and re-decides after each event. Tiers requiring approval wait for the response times stated in the scenario.

The scenarios are deliberately varied:

• one tests automatic containment with no approvers available;
• one tests the operational cost of two-person approval;
• one removes a detection to see whether the chain still crosses the threshold; and
• one is a false positive on which a correct policy must decline to act.

From a clean clone, the baseline runs with four commands listed in the reproduction note below. Fifty-seven tests pass at 86% statement coverage. The policy template verifies and is blocked from live execution. All four scenarios produce their expected outcomes, and the audit chain closes intact.

Containment occurs at minutes 19, 28, and 32 in the three intrusion scenarios. The false-positive scenario is correctly not contained.

The repository README records the tests, coverage, and three containment times. I changed one variable at a time to examine how stable those results were.

Experiment 1 – Escalation is not free

The engine contains one rule that reads, in the source, almost like an afterthought:

# Do what is pre-authorized now; escalate the rest. A higher tier waiting on
# approvers must never block the automatic tier the score already earned.

In the fast scenario, a stolen-credential login at minute 0 is detected at minute 6. Credential dumping occurs at minute 8 and is detected at minute 12. The cluster score reaches 54.1 – Friction – so sessions are revoked automatically at minute 12.5.

An RMM tool appears at minute 16 and is detected at minute 18. The score reaches 94.2 – Sever – which requires two approvers. The scenario deliberately has none.

The engine records that Sever is blocked, drops to the highest automatic tier the score had already earned, and immediately executes Contain: disable the user, isolate the host, and deactivate the cloud keys. Containment occurs at minute 19, leaving 53 minutes of margin.

I disabled that single conditional and reran the suite. The scenario was not contained at minute 30, 50, or 71. It was never contained. The engine escalated to a tier nobody could approve and waited while the attacker continued toward exfiltration, even though the SOC retained authority to execute a lower tier.

This is the opposite of how escalation is commonly written. Many incident-response plans express severity as a single ladder: as the situation worsens, the decision moves upward. Encoded literally, that can mean a worsening situation withdraws authority the SOC held minutes earlier.

The correction is small but should be explicit in any authority model: escalation adds a decision; it never subtracts an existing permission. The pending approval and the pre-authorized floor run in parallel, and the floor executes immediately.

My original ladder did not say this. It treated an object as if it sat at exactly one tier at a time. It should instead say that an object sits at the highest tier its evidence justifies while retaining every lower tier's standing authority during the higher-tier decision.

Experiment 2 – Crown jewels can have nothing pre-authorized

The crown-jewel scenario places the same class of intrusion on a payments service principal. Token replay begins at minute 0 and is detected at minute 5. Cloud reconnaissance begins at minute 10 and is detected at minute 13. The score reaches 53.6 – Friction – whose action is session revocation: limited, relatively easy to reverse, and the least disruptive action available in the policy.

It does not happen.

The target's criticality meets the crown-jewel floor, so the protection rule escalates the plan to two-person approval. There is no fallback because the only tier below Friction is Watch, which executes nothing. The engine's floor is empty.

From minute 13.5 through minute 27.5, while the score climbs to 100 and the attacker disables logging, no containment action is taken against a compromised identity inside the payments service. Containment occurs at minute 28 because the on-call IR lead responded in 8 minutes and the CISO responded in 14.

I varied approver response times to identify the edge. Above roughly 11 minutes, containment tracks the slower approver one for one: in this scenario, the containment time equals the slower response plus 14 minutes. Below that point, it floors at minute 25 because that is when the evidence supporting the decision arrives; a fast approver cannot outrun the telemetry. The scenario survives a slower approver who responds in 57 minutes and misses the deadline at 58.

The exact timing is less important than the structural condition: for the assets the organization protects most carefully, the pre-authorization budget can be zero, leaving the defense entirely dependent on human reachability.

Protection may need to escalate by action and asset together. Isolating a payments host and revoking one session on a payments identity carry different operational consequences. A model that treats them identically is relying on a shortcut rather than a demonstrated safety property.

A more careful policy would allow low-impact friction to remain automatic on crown jewels while disablement, isolation, and quarantine escalate. Supporting that distinction requires changes to both the policy schema and the engine, which I have not made. A session revocation affecting a payments identity during an active overnight incident can still page a business owner and start an outage bridge. Labeling an action reversible in the data model does not guarantee easy reversal in operations.

Experiment 3 – Latency is fungible in this rehearsal

A detection engineer could reasonably argue that earlier detection would reduce the importance of approval latency.

To test that, I added latency to every detection in the fast scenario while holding authority constant. Separately, I added latency to the approvers while holding detection constant.

The honest reading is that neither source of delay dominates in this model. The scenario tolerated 52 additional minutes of detection latency or 57 minutes of approver latency before missing the 72-minute benchmark. The attacker's clock could not distinguish between them.

I did not expect that result. In this rehearsal, authority and detection consumed equal amounts of response margin, while many organizations explicitly measure only detection.

Mean time to detect appears on dashboards and board reports. The interval from decision-ready to decision-made – from the moment an analyst can recommend containment to the moment someone is permitted to execute it – is often not tracked as a distinct operational metric.

Start by measuring that interval; the project is optional. Across the last 20 incidents, capture when the analyst recommended containment and when the action executed. The resulting distribution will show whether decision authority is constraining response before you invest in changing it.

The second result is the one that flatters the design. Removing one detection entirely – the credential-dumping alert never fires – costs 13 minutes, but the scenario still contains with 40 minutes remaining. A model that accumulates weaker evidence across an attack chain degrades more gracefully than a rule waiting for one specific alert.

Experiment 4 – The same hole, created by omission

Experiment 2 emptied the floor intentionally: someone wrote a rule saying crown jewels always require two people, and a risk committee approved it. Experiment 4 empties the floor by omission, and nobody signs an omission.

The engine has a defensible fail-safe: a target absent from the business-context map never silently inherits standard criticality. It escalates to two-person review because the system should not automatically disable something it cannot identify.

I changed one field in the fast scenario – the compromised user's domain, from the corporate domain to one belonging to a recently acquired company that was absent from the asset inventory. Nothing else changed: same signals, timings, and score.

The scenario was never contained.

The unknown target appears in the candidate-action set of every tier that can act, so each tier escalates. The only tier underneath is Watch, which executes nothing and therefore is not a floor. The engine behaves as designed, and the design is defensible. The consequence is still significant: under any policy that escalates unknown objects, containment speed is bounded by the completeness of the asset inventory – and that boundary is discontinuous. For an object the system cannot identify, the organization has pre-authorized nothing.

In a real environment, those objects have familiar names: assets from a recent acquisition that have not been reconciled; contractor and partner identities; cloud accounts created outside the normal process; service principals introduced by SaaS integrations; unmanaged workloads; and systems whose business ownership changed without the security context changing with it.

Unit 42's dataset points in the same direction. Data from SaaS applications was relevant to 23% of its 2025 cases, up from 6% in 2022. Its analysis of more than 680,000 identities across cloud accounts found that 99% of cloud users, roles, and services held excessive permissions. The objects least likely to appear correctly in an inventory are often the ones identity and SaaS trends place closest to the attacker.

There is also a trap in my own template. The example business-context file contains a catch-all pattern matching every address in the corporate domain. That makes the fail-safe almost inert for users: nearly any corporate identity resolves to "standard," and escalation never fires.

That shortcut is convenient in a demonstration and dangerous in production because it converts an explicit inventory into an implicit assumption. Lookup is also first-match and order-dependent, so reordering the file can silently change an asset's criticality. Anyone adapting this policy should remove the catch-all and accept the resulting escalations. Here, the friction serves as the control.

Pre-authorization depends on inventory and dependency mapping as much as it depends on governance.

Experiment 5 – What the engine did not explain

Earlier I quoted the engine's claim that every deviation is recorded as a sentence a human can understand afterward. A claim in a docstring is still a claim, so I looked for a case in which it would be false. It took about 20 minutes.

Construct a plan that breaches two conditions simultaneously: 12 user accounts, exceeding the Contain tier's ceiling of 10, with one of those users absent from the asset map. Both conditions are detected. Only one is explained.

The unknown-asset check runs first and raises the plan to two-person review. The ceiling check runs next and is written to change authority only while the plan remains automatic. Because the first check has already escalated it, the second condition is computed and stored but never added to the reasons list.

The written justification says the target was absent from the business-context map. It does not say the organization was about to disable 12 accounts against an accepted ceiling of 10.

I want to be precise about the severity because my first draft overstated it. The breach is not lost. It appears in the hash-chained decision record as a structured field, and anyone parsing the log can find it. What is missing is the narrative explanation: the reasons list, rehearsal timeline, console output, and JSON report. The fact exists in the evidence but not in the explanation.

That distinction still matters. A SOAR playbook can execute the action, and a log can prove that an event occurred. The authority model must explain why the machine was permitted to act on those objects, whether the reader is an IR lead during the incident, an internal auditor months later, or a regulator.

Nothing about the decision was unsafe. Two-person review was the correct authority. The unknown asset alone required it, and it was stricter than the single approver the ceiling breach alone would have required. The action was right, the authority was right, and the account of it was incomplete.

The correction is to separate detection from escalation: record every breach when found, and change authority only when the plan remains automatic. It is a small edit, but not a one-line fix. It must be made in two places because the crown-jewel blast-radius check is gated in the same way and drops its reason under the same conditions. I found the second location only after correcting the first – its own lesson about assuming a defect is singular.

This finding applies to the public v0.1.0 reference implementation. I verified the tagged release at commit 0a571ae against the experiments described here; the incomplete explanation remains reproducible. At publication, main contains no later executable change affecting this finding.

The defect survived 57 tests, 86% statement coverage, four rehearsals, and a written threat model. The suite does test reason strings for the protected-pattern and unknown-asset conditions. It does not test them for the other two conditions, which are precisely the two that are gated. I wrote the right test twice and stopped.

One practical check costs nothing: inspect what your current security automation writes when it escalates for more than one reason at once. Short-circuiting implementations can preserve the right decision while recording only the first condition they encounter. Test yours explicitly. Mine did.

What I would change in the ladder

Four revisions follow from the experiments.

1. Preserve standing authority during escalation

An object sits at the highest tier its evidence justifies while retaining every lower tier's authority during the higher-tier decision. Any written authority model should say this explicitly. The natural reading of a severity ladder is often the opposite, and the natural reading is what gets implemented.

2. Index protection rules by both action and asset

"Crown jewels always require two people" is easy to write and approve. It can also leave an organization with no pre-authorized action on its most important systems. A more defensible policy specifies which actions remain standing even there.

3. Keep human judgment in the incident-command layer

A deliberate choice to delay containment to preserve evidence, and a named person accepting an irreversible consequence, are incident-command functions. Putting them on the same ladder as machine-executable permissions implies that a machine can enter those states. It cannot, and it should not be modeled as though it can.

4. Test every justification

Every escalation condition an authority model can detect needs a test that fails when the condition is met but the explanation does not name it. I wrote that test for two of four conditions, which was worse than writing none because a suite checking half the category looked like a suite checking the whole category.

The question to take to your next tabletop exercise

The usual opening question – "Can we contain in 72 minutes?" – invites a confident answer nobody can support.

Ask instead:

Name every containment action this organization has pre-authorized, the object class to which it applies, the person who accepted the risk, the evidence required to trigger it, and the date it was last rehearsed.

A short list reveals limited coverage. No list at all means the organization is not yet ready to debate a 72-minute target.

Then ask the follow-up produced by Experiment 4:

For what percentage of our identity, endpoint, cloud, SaaS, and critical-service estate could we answer that first question completely?

Those questions connect incident-response readiness, SOC operating models, security automation, asset management, cyber risk governance, operational resilience, and executive accountability. They also reveal whether the organization has a documented plan or a rehearsed capability.

Reproduce the experiments

The project is MIT-licensed and public. The results in this article were produced against release v0.1.0 on Python 3.11. Clone it, run the rehearsal, change one variable, and see what breaks.

git clone https://github.com/jessenkurien/72-minute-defense.git
cd 72-minute-defense
python -m pip install -e ".[dev]"

72md policy verify
72md rehearse --out out --audit out/audit.jsonl --fail-if-late
72md audit verify --audit out/audit.jsonl

To reproduce the individual experiments:

• Experiment 1: disable the fallback branch in seventytwo/engine/decide.py, then rerun the rehearsal.
• Experiments 2 and 3: copy a scenario file and vary response_minutes or detect_delay.
• Experiment 4: change the user identifier in scenarios/fast-72.yaml to a domain absent from policy/business-context.yaml.
• Experiment 5: score a cluster of 12 users with one outside the context map, then compare plan.blast_radius.over_ceiling with plan.reasons.

View and run The 72-Minute Defense on GitHub

From policy to operating capability

The project makes authority, evidence, blast radius, ownership, and recovery explicit enough to test. Each organization must still decide which containment actions it is willing to automate before an attacker forces the issue.

A practical containment-readiness assessment should answer four questions:

1. Authority: Which actions are already approved, by whom, and under what evidence threshold?
2. Coverage: Which identity, endpoint, cloud, SaaS, network, and business-service objects are actually mapped to those rules?
3. Execution: Can the SOC, MSSP, incident commander, and automation platform carry out the approved action within the available window?
4. Evidence: Can the organization reconstruct the decision, the conditions that triggered it, the action taken, and the recovery path?

The business value comes from converting an abstract incident-response policy into a measurable operating model, including clear evidence of where it stops. The same method can be applied to ransomware containment, identity compromise, cloud-account abuse, insider threats, destructive attacks, and AI-assisted security operations across mixed-vendor environments.

Discuss a containment-readiness assessment with Jessen

---

Technical-use disclaimer

The 72-Minute Defense and the Cyber Incident Commander Toolkit are independent, open-source reference implementations intended for research, evaluation, rehearsal, and organization-specific adaptation. They are not production-ready security products, legal advice, compliance certifications, or substitutes for organization-specific engineering, risk, privacy, employment, regulatory, and safety review. Validate all policies, integrations, permissions, recovery procedures, and response actions in a controlled environment before operational use.

The projects are not affiliated with or endorsed by Microsoft, Okta, CrowdStrike, Amazon Web Services, Palo Alto Networks, NIST, or MITRE. ATT&CK is a registered trademark of The MITRE Corporation.

Sources

1. Palo Alto Networks Unit 42, Global Incident Response Report 2026, published February 17, 2026.
2. Palo Alto Networks, 2026 Unit 42 Global Incident Response Report – Attacks Now 4x Faster.
3. Help Net Security, One stolen credential is all it takes to compromise everything, February 18, 2026.
4. SecureWorld, The Machine-Speed Mandate: Breaking Down a New Global IR Report.
5. TechHQ, Unit 42: Identity gaps and AI speed increase enterprise risks, February 17, 2026.
6. Jessen Kurien, You Cannot Approve at Machine Speed, September 5, 2026.
7. NIST, SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, April 2025.
8. NIST, Cybersecurity Framework 2.0.
9. Jessen Kurien, The 72-Minute Defense, MIT-licensed reference implementation.
10. Jessen Kurien, Cyber Incident Commander Toolkit, open-source reference implementation.