This kind of context is critical. Let’s say a pod attempts to exfiltrate data by making an outbound request to an external endpoint. In a traditional setup, you might see the egress traffic and block the IP. But that doesn’t answer the real question: What process made the call, from which container, and what was it doing before that? Tetragon can tie the network flow to a specific binary running in a specific pod and enforce a policy that stops the behavior mid-execution. It’s microsegmentation enforced at the level of identity and intent, not just connectivity.
Enforcing policies before bad behavior executes
Most cloud-native security tools generate alerts. They observe suspicious activity and send logs to SIEMs or dashboards for human triage. This model doesn’t scale in Kubernetes. With thousands of ephemeral workloads, alert volume explodes and investigation timelines stretch beyond the point of usefulness. By the time a team sees the alert, the container may already be spun down.
Tetragon flips this model. Because it operates in the kernel using eBPF, it can filter, aggregate, and act on events before they leave the host. It doesn’t just report suspicious behavior; it can stop it. For example, if a container starts an unexpected shell process, Tetragon can issue a SIGKILL or override immediately. If a file access doesn’t match policy, the action can be blocked at run time, not merely logged for later review. Developers can write Kubernetes-native policies that define exactly what processes are allowed to run, what files they can touch, and where they can connect.
