Your team has a mature detection stack. Years of rules tuned against real incidents: suspicious parent-child process trees, LSASS access patterns, lateral movement over SMB. Then someone spins up a project in AWS, an access key gets phished out of a CI config file, and the actual attack unfolds entirely inside CloudTrail: a sequence of IAM API calls with no process, no host, no EDR agent anywhere near it. Every detection rule your team has ever written assumes a process tree exists. This attack doesn't have one. It has an audit log, and nobody wrote a rule against it.
This isn't a hypothetical gap, it's the default state of most detection programs, because cloud-native attacks are a genuinely different signal type than the one host and network detection engineering was built around, and the switch from reading process trees to reading API call sequences doesn't happen automatically just because you already know how to write a good detection rule.
Here's the shape of the attack that actually gets missed. A compromised IAM credential, on its own, is not loud. The first thing an attacker with a stolen access key typically does is sts:GetCallerIdentity, to confirm what they've got, followed by a burst of iam:List* and iam:Get* calls: listing roles, listing attached policies, listing users. None of that touches data. None of it deletes anything. On a host, that reconnaissance pattern would look like whoami and a directory listing, mundane enough to ignore. In CloudTrail it's exactly as mundane, and exactly as worth flagging, if you know a normal developer credential doesn't enumerate the entire IAM structure of the account in a two-minute burst right after a login from a new IP.
