What is a destructive action?

A destructive action is any cloud operation that deletes, disables, or permanently alters live systems or data in a way that is difficult or impossible to reverse. The damage is not always immediate or obvious, but the defining quality is that undoing the effect requires significant effort, or cannot be done at all.

What counts as a destructive action?

Any operation whose effects cannot be cleanly reversed falls into this category. Deletion is the clearest example, but destruction takes other forms too.

In AWS, common destructive actions include deleting an RDS instance, dropping a DynamoDB table, removing an S3 bucket that contains data, stopping CloudTrail logging, disabling GuardDuty, and revoking IAM policies that protect other resources. In GCP the same pattern applies: deleting a Cloud SQL instance, removing a Pub/Sub topic with active subscriptions, or disabling a VPC firewall rule that controls access to production workloads. In Azure, removing a resource group cascades deletion to everything inside it, which makes it one of the most impactful single actions available to any operator.

Not all destructive actions delete data. Disabling logging removes your audit trail without touching your infrastructure. Changing a security group to allow broad public access is destructive in the sense that it exposes systems immediately, even though nothing was deleted.

Why does intent matter as much as the action itself?

The same API call can be routine in one context and catastrophic in another.

dynamodb:DeleteTable is a perfectly valid operation. Every team running database migrations executes it regularly against non-production tables. Blocking the call outright breaks those workflows. But the same call against a production table in the middle of business hours, made by an identity that was not near that table yesterday, tells a very different story. The action is identical; the context changes everything. Good detection reads both.

This is why simple blocklists are the wrong model for destructive actions. You cannot blocklist s3:DeleteBucket without breaking legitimate cleanup workflows. You cannot blocklist iam:DetachRolePolicy without preventing normal role management. The action name alone does not carry enough information to make a safe decision.

Why do blocklists fail?

Blocklists fail in both directions at once: they block too much and miss too much.

When you block a broad action like ec2:TerminateInstances, you immediately break autoscaling, blue-green deployments, and every test environment teardown script. Teams route around the block or get the control removed. When you try to narrow the blocklist to avoid those collisions, you create gaps that miss real incidents. An attacker who knows your blocklist simply uses an adjacent API that achieves the same outcome.

The underlying problem is that blocklists are static and the cloud API surface is enormous. AWS alone exposes thousands of distinct API actions. Any fixed list of bad actions will be both over-inclusive for legitimate use and under-inclusive for novel attacks.

How does context determine whether an action is destructive?

Context has several dimensions: the environment, the identity, the timing, and what happened just before.

Deleting a staging database at 2am after a routine deploy script runs is expected behavior. Deleting the same database from an identity that has not touched that resource before, thirty seconds after that identity read a configuration file containing production credentials, is a very different situation. The action is the same. The surrounding sequence changes the risk completely.

Effective detection captures all of this: which account, which region, which resource class, what the preceding actions were, and whether this pattern matches anything seen before from this identity or from known attack sequences. Evaluated together, these signals let you distinguish routine from dangerous without stopping legitimate work.

Korvalis reads action sequences in real time against these dimensions, catching destructive operations that look benign in isolation but reveal intent when viewed in context.