In the early days of network security, microsegmentation was a firewall tactic. You divided your network into trust zones, assigned rules to each zone, and tried to prevent lateral movement. Microsegmentation was slow to implement, hard to maintain, and designed primarily for static infrastructure: rack-mounted servers, predictable IP ranges, and tightly controlled perimeters.

But the world changed. Developers started deploying workloads to Kubernetes. Pods came and went in seconds. Applications stretched across clusters and clouds. IP addresses became ephemeral, namespaces replaced VLANs, and the network perimeter dissolved into abstraction. Ultimately, this shift evolved into a state where traditional microsegmentation is no longer the silver bullet. As the software delivery model evolved, so too have the security responsibilities. They’ve shifted into the application runtime.

Today, developers, platform engineers, and security professionals are all being asked to reason about something they were never trained for: runtime microsegmentation. Runtime identity Is the new security perimeter.

A new definition of microsegmentation

Microsegmentation used to mean separating network zones. Today, it means separating workload behaviors. The shift is both technical and cultural. 

Instead of segmenting by IP or subnet, we now segment by Kubernetes identity, process execution, file access, and even geographic origin. This isn’t just a new technique; it’s a new discipline. Developers need tools that understand their environment, their runtime, and their workflows.

Tetragon, a Kubernetes-native runtime security project built on eBPF, enables this shift. eBPF allows us to hook directly into the Linux kernel, capturing events like system calls, process executions, and network activity in real time. Tetragon uses this visibility to provide identity-based enforcement that aligns with the way Kubernetes applications work. It doesn’t just tell you what happened; it tells you which container ran the binary, in which namespace, on what cluster, and whether that action violated a policy.

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.

This level of control isn’t just about blocking bad behavior. It’s about enforcing the right behavior without friction. 

In AI-driven environments, for instance, researchers may need access to high-throughput training workloads. Tetragon allows platform teams to enforce policies that optimize for locality (for example, enforcing regional access boundaries to reduce consumption costs) while maintaining performance. Policies can ensure that inference models run only in designated clusters and cannot call back to noncompliant data sources, without requiring developers to configure networking primitives themselves.

Runtime microsegmentation: The new developer contract

Security is no longer the domain of specialists alone. Developers are increasingly responsible for configuring access controls, defining security policies, and responding to runtime anomalies. Microsegmentation, in this context, has to be accessible. It has to be built into the tools developers already use, and it has to speak the language of Kubernetes, not firewalls.

Tetragon brings the answers and framework needed for control. It exposes rich runtime context—process behavior, Kubernetes metadata, Linux identities—in a way that developers can use to define guardrails. These guardrails aren’t rigid ACLs; they’re flexible, declarative policies that can evolve with the application. Teams can start by observing what’s normal, and with advanced versions Tetragon can surface recommendations that show what policies might make sense. Over time, enforcement can be layered in gradually and confidently, without breaking things.

This is what runtime microsegmentation really means now: not just partitioning the network, but shaping acceptable behavior for every running process. Instead of chasing context across systems and logs, developers and platform teams can define it up front. Microsegmentation has become a shared contract across the stack, part of how modern software gets built, shipped, and secured.

Jeremy Colvin is a senior engineer at Isovalent.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.