The Runtime Gap: Introducing Runtime Integrity

The chain of trust ends the moment your OS finishes booting.

If you operate an AI data center, GPU cloud, or shared AI infrastructure, the same question comes up every time a machine changes hands:

When a machine moves between tenants, how do you know it is still trustworthy?

The textbook answer is to bring the system back to a known-good state from the ground up. That means a full reboot, firmware re-validation, and a fresh chain of trust from hardware through the operating system.

In practice, that is not always how production clusters are operated. Faster paths exist for returning a machine to rotation, and many environments rely on them.

Those paths assume something boot-time security cannot verify: that nothing in the runtime environment has been tampered with. A kernel rootkit, an eBPF backdoor, a user-space implant, or a malicious runtime library can leave a machine fully under attacker control while it continues to pass every boot-time integrity check the cluster runs. The system attests cleanly. It reports the expected configuration. It serves workloads as instructed.

In a multi-tenant GPU cluster, that gap is real. A single compromised node can persist silently across tenants, move laterally across the fabric, and observe or exfiltrate everything that runs on it: model weights resident in GPU memory, training data, and inference traffic. Boot-time security never sees any of it.

In this three-part series, we explain what runtime integrity is, walk through real-world attacks against it, and detail how to mitigate them.

The Limits of the Chain of Trust

AI infrastructure relies on a layered chain of trust that begins in hardware, extends through firmware and boot integrity, and ultimately reaches the operating system and the workloads running on top of it. This model assumes that if a platform starts from a trusted state, the system can continue operating securely throughout its lifetime.

In practice, however, this assumption does not always hold. Modern attackers increasingly target the system after the chain of trust has already been established, manipulating the runtime environment and the integrity of the running kernel and system state.

Over the past several years, attacker toolkits and techniques have evolved specifically to exploit this gap. Kernel rootkits, user-space implants, eBPF-based backdoors, and runtime library injections allow adversaries to manipulate the live system without modifying boot artifacts or files on disk. By altering the behavior of the running kernel or injecting logic into user-space processes, attackers can hide processes, intercept syscalls, conceal network activity, and maintain long-term persistence while remaining largely invisible to traditional monitoring tools.

This challenge becomes even more significant in large distributed environments such as AI clusters, cloud infrastructure, and modern data centers. These environments operate thousands of machines and frequently host multiple tenants on shared infrastructure. Once attackers gain initial access - often through exposed services, credential theft, or misconfigured infrastructure - they can manipulate the runtime environment to move laterally across workloads, access sensitive datasets, steal model weights, or even tamper with running models and inference pipelines, potentially introducing backdoors or manipulating model behavior.

For organizations operating these environments, this creates a difficult balance. Businesses depend on highly dynamic systems that prioritize scalability, performance, and operational continuity, while security teams must ensure the integrity of the underlying infrastructure. Runtime integrity - particularly the integrity of the kernel and the live system state - therefore sits at the center of the problem.

What is Runtime Integrity?

Runtime integrity is the assurance that a system remains trustworthy while it is actively running, not just when it boots. It focuses on protecting and validating the live execution environment: the kernel, loaded modules, memory-resident components, user-space processes, shared libraries, and the mechanisms that connect them.

In other words, runtime integrity asks a simple but critical question:

Is the system still behaving as the trusted system we expect, or has its live state been altered by an attacker?

In the broader context, we typically focus on five core components whose integrity must be preserved:

In the context of this blog, we discuss runtime integrity.

Modern systems are dynamic by design, which makes this problem difficult. Some components are expected to remain stable, while others change constantly during execution. The kernel loads code and manages memory structures, processes start and stop, libraries are linked at runtime, and technologies such as eBPF intentionally allow new logic to be loaded into the kernel after boot. That flexibility is powerful for observability, performance, and security, but it also creates opportunities for attackers to implant malicious logic directly into the running environment.

From a defender’s perspective, runtime integrity sits between boot integrity and application trust. Firmware integrity and measured boot help establish a trusted starting point, but they do not guarantee that the system remains clean afterward. A machine can boot in a trusted state and later be compromised by a kernel rootkit, a user-space rootkit, a backdoor, a malicious eBPF program, or library hijacking. This is what makes runtime integrity different from static integrity checking: it is not only about verifying files on disk, but whether the live system state remains trustworthy over time.

A practical way to think about runtime integrity is through two major layers: Kernel runtime integrity and User-space runtime integrity

The first is kernel runtime integrity, which covers the operating system core, kernel memory structures, system call handlers, kernel modules, and eBPF programs. The second is user-space runtime integrity, which covers running processes, shared libraries, utilities, and application behavior. Attackers can operate in either layer, and increasingly in both, to hide activity and maintain persistence while blending into normal operations.

In this blog, we introduced the concept of runtime integrity. In our next blog, we will examine modern attack techniques that target runtime environments.