Detect vs enforce, safely

The spectrum and a waved rollout.

Detection tells you an attack happened; enforcement stops it. Understanding when to observe and when to prevent — and how to move safely between them — is what separates a mature runtime program from a wall of alerts nobody acts on.

The detection–enforcement spectrum

Runtime controls sit on a spectrum. Pure detection (Falco) observes and alerts, with no risk to workloads but a gap between the malicious action and any response. In-kernel enforcement (Tetragon Sigkill, BPF-LSM deny, Cilium default-deny) acts synchronously, closing that gap but carrying the risk that a wrong rule breaks production. Most estates combine them: broad detection everywhere for visibility, and targeted enforcement on the highest-value, highest-confidence conditions — reading a secret file, spawning a shell in a locked-down workload, egress to an unapproved destination.

# Phase 1 — observe: Tetragon reports reads of sensitive files (no action).
#   matchActions: [{ action: Post }]        # event only → SIEM, measure noise
 
# Phase 2 — enforce, after validating the match is unambiguous:
#   matchActions: [{ action: Sigkill }]     # now block it in-kernel
 
# Roll enforcement out in waves (namespace by namespace), watch for breakage,
# and keep an escape hatch (a label that reverts a workload to observe-only).

Rolling out enforcement safely

Enforcement rollout mirrors policy rollout everywhere in security: start in audit/observe mode, measure what would have been blocked, fix the legitimate cases, then flip to enforce in waves — never everywhere at once. Keep an escape hatch to revert a workload to observe-only, so a bad rule is a quick rollback rather than an outage. Pair enforcement with detection rather than replacing it: you still want the alert and the forensic trail even when the action was blocked, because that record is what tells you the attack happened and how.