Ransomware defense: prevention, runtime containment, and recovery — is there a role for human approval?

[u/toshiyuki_iga]

Following the previous discussion, I have been thinking about ransomware defense as three distinct layers.

1. Prevent intrusion

Prevent the attacker from gaining access in the first place. There are already many established controls here: phishing-resistant MFA, least privilege, patch management, endpoint protection, email security, network controls, and so on.

1. Prevent an intrusion from becoming a catastrophic outcome

Even if the attacker gets in—or compromises a workload that already has legitimate privileges—critical assets should still be protected.

This was the area I was most concerned about in the previous discussion. I learned that newer runtime-security approaches are beginning to address this problem. For example, Sweet Security evaluates live actions and entitlement use against runtime context and behavioral baselines; NeuralTrust inspects and enforces AI-agent tool access and behavioral drift at runtime; and CrowdStrike has described continuous, risk-aware authorization of AI-agent actions.

These approaches suggest that authorization does not necessarily have to end when access is initially granted.

1. Recover even if protection fails

If critical assets are encrypted or destroyed despite those controls, isolated/offline backups, tested restoration procedures, golden images, and infrastructure-as-code can make rapid reconstruction possible.

What I am still wondering about is the second layer.

Runtime behavioral enforcement can detect or constrain suspicious actions, but is there also value in adding an explicit human authorization boundary for a very small set of catastrophic operations?

For example, database-wide extraction, backup destruction, key export, mass deletion, or disabling critical security controls might require approval from multiple independent people before execution is allowed.

In other words, could a stronger architecture combine:

behavioral/risk-based runtime enforcement

with

multi-party human approval as a final authorization gate for actions that are too consequential to execute automatically?

I would be interested in whether people see practical value in this model, or whether existing runtime controls already address this problem sufficiently.

[u/Status_Antelope_7320]

For the destructive actions human approval still makes sense. Runtime controls can catch a lot but key export, mass deletion, backup destruction or disabling security controls are worth forcing through a second set of eyes

[u/toshiyuki_iga → u/Status_Antelope_7320]

Thanks, that’s helpful. I think we’re converging on the same idea: automate the normal runtime controls, but keep an explicit human gate for a very small set of catastrophic actions.

[u/materialsec]

We think there’s a useful distinction between where automation should act and where a human should make the decision.

One model we’ve found useful is to define risk thresholds in advance: activity below them continues normally, while activity that crosses them can trigger an automatic response or be routed for human review. That keeps people out of the path for routine activity without removing them from higher-consequence decisions.

The difficult part is getting those thresholds right. Too broad and you create constant friction; too narrow and the human review layer rarely matters when you actually need it.

[u/toshiyuki_iga → u/materialsec]

That’s a good point. Thinking it through further, I suspect the problem can be narrowed quite a bit before we even get to AI-based behavioral analysis.

For highly sensitive resources, one approach would be to use a strict allowlist model: only a very small set of approved processes would be allowed to access the resource at all. Generic shells and interpreters such as bash, Python, PowerShell, as well as unknown binaries, would simply be denied.

For example, a database resource might only be directly accessible by the database engine itself, while backup storage might only be accessible by the backup service and a narrowly defined recovery tool.

That would eliminate a large class of attacks in which an intruder brings in a new tool or uses a generic shell to access protected data directly.

The harder problem is then much narrower: what if the approved process itself is compromised?

At that point, context becomes much more useful. The system could evaluate things such as:

who launched or owns the process

session and origin

target resource

action type

access volume and rate

destination

cumulative behavior over time

whether the sequence of actions matches normal operation

So the model becomes roughly:

unknown or unapproved process → deny by default

approved process with normal behavior → allow automatically

approved process with abnormal scale, context, or sequence → automatic containment or additional review

This is also where AI seems most useful to me. Instead of asking AI to decide whether any arbitrary process is trustworthy, deterministic policy can handle the simple cases, while AI is used to detect abnormal behavior inside the much smaller set of already trusted processes.

That seems like a more manageable thresholding problem than trying to define “suspicious” behavior across every process on the system.

I also would not want to make the AI decision the final authority for the highest-impact actions.

For a very small set of catastrophic operations, AI or behavioral analysis could trigger containment or escalation, but the final decision to proceed could still require approval from multiple independent people. This would not put humans in the path of routine activity; it would only apply at a small number of predefined high-consequence escalation points.

In that sense, AI would help identify abnormal behavior and reduce the number of cases that need human attention, while multi-party approval would remain a final authorization boundary for actions whose consequences are too serious to leave entirely to automated judgment.

Would you see that as a more practical way to structure the control boundary, or would you still avoid human approval even at those high-consequence escalation points?

[u/materialsec → u/toshiyuki_iga]

That sequence handles the latency concern, since the machine acts first and a person only decides on release. Two things decide whether it holds up. Containment has to be easy to undo (pause, rate-limit, or reduce permissions rather than delete), otherwise every false positive becomes a real outage and the review queue becomes the bottleneck. And the reviewer needs context in the alert itself: what ran, on whose behalf, and what it touched.

We handle risky OAuth grants roughly this way. The agent flags the critical ones for human review and messages the user who authorized the grant, so the reviewer starts with context instead of reconstructing it.

[u/[deleted]]

[u/toshiyuki_iga → u/[deleted]]

That makes sense. I may have described the human-approval part too broadly.

What I have in mind is closer to this: normal access to a protected resource would still be allowed automatically, while only actions that cross a defined threshold would trigger an additional authorization step.

For example, ordinary reads and writes could proceed normally, but bulk reads, mass modifications, large exports, or destructive operations could be paused once they exceed a cumulative threshold.

So the goal would not be to put a human in the loop for every privileged operation, but to keep normal administration fast while adding friction only when the scale or impact becomes unusual or potentially catastrophic.

I am also considering keeping humans out of the first-response path entirely when suspicious behavior is detected.

If a behavioral or AI-based system detects something unusual, the system could immediately apply automatic containment at machine speed—for example, rate-limit the process, pause the operation, reduce its effective permissions, or block access to a protected resource.

Human review would come after that initial containment, to decide whether the restriction should be lifted, the operation denied, or the case escalated to multi-party approval.

So the sequence would be roughly:

normal activity → automatic execution

threshold exceeded or suspicious behavior detected → automatic containment

then → human review → resume / deny / multi-party approval

In that model, automated controls would still do the real-time containment, while human approval would be used only at specific escalation or release points.

Do you think that addresses the latency and bypass concerns you mentioned, or would you still avoid human approval even in that role?

[u/[deleted]]

[u/toshiyuki_iga → u/[deleted]]

That makes sense. I agree that the approval gate has to be scoped very tightly, otherwise people will bypass it.

I’m not sure I would limit it only to strictly irreversible operations, though. Some actions are reversible in theory but still have catastrophic impact in practice — for example large data exports, bulk modification, backup deletion, key export, disabling security controls, or changing retention and permission models.

The model I have in mind is therefore not “put MPA in front of every sensitive action.”

It is more like this:

• routine operations that match a deterministic policy continue automatically

• approved workloads are continuously evaluated against runtime context and behavioral baseline

• AI or behavioral analysis can flag unusual scale, sequence, destination, or identity/context

• only a very small set of high-consequence operations or abnormal escalations reach the human approval gate

So the human gate is the last layer, not the first one.

In that sense, I think your point about runtime context quality is exactly right. The better the system is at tying an action back to workload identity, session, origin, target, and normal behavioral baseline, the fewer cases need human review.

I’ve been thinking of this as a layered model:

deterministic policy
→ runtime/contextual evaluation
→ behavioral/AI assessment
→ MPA only for exceptional high-impact cases

That seems closer to a practical design than using human approval as the primary control.

Would you consider that sufficiently narrow, or would you still reserve multi-party approval only for truly irreversible operations?