Most security tooling makes its decisions before a workload ever runs: scan the image, check the policy, verify the signature, admit or reject. That work matters, and it stops a lot of bad things at the door. But all of it happens while the system is still just an idea, before it becomes a running process handling real traffic and real data.
The harder problem shows up a moment later, once everything has been admitted and is doing exactly what it was allowed to do. Right up until it isn't.
Prevention answers a different question
Prevention asks, “Should this be allowed to start?” Runtime security asks a question you can only answer while the system is live: “Is this still behaving the way it should?” Those aren't the same question, and passing the first tells you very little about the second.
A workload can be built from a clean image, pass every admission check, and still drift into behavior nobody intended. Maybe a dependency got compromised upstream. Maybe a credential leaked. Maybe an operator was tricked. None of that shows up before the process is running.
Why this gap keeps widening
- Systems are more distributed, so there are more moving parts and more places for behavior to drift from intent.
- Workloads are more dynamic, so a static rule written last quarter rarely describes what “normal” looks like today.
- Sensitive work increasingly runs in environments you should assume are already partly compromised.
Security that only inspects a workload before it runs is inspecting the one moment it is least likely to misbehave.
What good runtime defense looks like
The bar is simple to state, even if it's hard to meet: understand what a workload normally does, notice when it stops doing that, and hand a person evidence they can actually investigate. Not a wall of alerts, but a clear account of what changed and why it was worth surfacing.
That's the frontier we're focused on. Prevention will always have its place at the door. The interesting, unsolved work is what happens after the door closes.