A single break-in can leave clues scattered across a company’s systems. Say an attacker signs in to a cloud server with a stolen password, runs a program that harvests more passwords, and then uses one of those passwords to reach a second system. The cloud account logs the sign-in and the second system records the visit. The password-harvesting program shows up only if something on the server is recording what runs.

On its own, each record might look routine. Spotting and tracking the attack requires connecting the records, which is a challenge when each one sits in a separate system.

A security tool can only act on the records it has access to, and that depends on where the tool runs. Choosing the best runtime security tools therefore starts with a practical question: where do the organisation’s servers, containers and cloud services actually run, and which cybersecurity tools can reach them?

Broadly, security platforms collect runtime data from one of five places: inside the Linux kernel, through an existing monitoring agent, through a server security agent, from cloud and identity logs, or from a graph that combines an agentless view with an agent-based sensor. Each reveals something different about an attack. The final approach, illustrated by Wiz, connects activity inside workloads with the wider environment.

The best way to monitor a running workload for attacks

Runtime security watches what a workload does while it runs, including starting processes, changing files and opening network connections, which enables a response when behaviour turns malicious. Scanning container images before they ship addresses an earlier stage in the same security process.

Agentless scanning within a cloud-native application protection platform (CNAPP) uses provider APIs to inspect disks, configurations and permissions. It establishes what is installed and exposed without watching processes execute. That execution view generally requires an agent on or alongside the workload. A CNAPP can provide both when runtime components are included and deployed.

For the first time, Uptime Institute’s 2026 survey found more corporate IT workloads running in third-party facilities and services (46%) than in enterprise-owned data centres (44%). That near-even split makes coverage across owned and rented infrastructure a practical starting point for the five approaches below.

Inside the Linux kernel with open-source eBPF tools

On a Linux server, every process has to go through the kernel, the core of the operating system, to start a program, open a file or make a network connection. Collecting data at that level records activity close to its source, before it passes through any other software.

eBPF makes that possible by running small, sandboxed programs inside the kernel without changing the kernel’s source code. Cilium Tetragon uses that access to monitor process, file and network activity and enforce policies, including terminating a matching process directly from the kernel.

Tetragon is an open-source Cilium project under the Cloud Native Computing Foundation, created by Isovalent, which is now part of Cisco. In Kubernetes, it tags each event with the pod and workload it came from.

The project carries no licence fee and gives engineering teams substantial control. It is Linux-only, however, and while predefined policies offer a starting point, teams still need to tune them and arrange event storage, correlation and prioritisation.

From the monitoring agent already on the host

Many organisations already run an agent on their servers to collect performance metrics and logs for operations teams. Adding security detection to that same agent avoids installing more software on every host and keeps security and operational data in one place.

Datadog Workload Protection takes this approach, adding runtime security to the Datadog Agent used for infrastructure monitoring. It uses eBPF on Linux and supports Windows hosts through a separate driver, while AWS Fargate containers need additional instrumentation.

Datadog supplies maintained detection rules, supports custom rules and provides file integrity monitoring. With enforcement enabled, rules can also terminate malicious processes on supported hosts.

Because security events sit alongside performance metrics and logs, operations and security teams can investigate an outage and suspicious behaviour as parts of the same incident. The fit is strongest where teams already work in Datadog, although coverage still depends on enabling the relevant components across the estate.

From a server security agent built for mixed estates

Server security agents come from the endpoint protection tradition. They treat each machine as a host to defend, whether it is a physical server in a company’s own data centre or a virtual machine in the cloud, which suits estates that span both.

TrendAI Vision One Server & Workload Protection approaches runtime defence this way. It covers physical servers, virtual machines, cloud workloads and containers across AWS, Azure and Google Cloud.

Its controls include intrusion prevention for known but unpatched threats, application control, exploit prevention and endpoint detection and response (EDR), and the wider Vision One platform adds extended detection and response (XDR). Trend Micro’s enterprise business adopted the TrendAI name in March 2026.

Buyers should assess the agent’s local controls alongside the Vision One integrations that connect alerts with identities, exposure paths and sensitive data. Those connections determine how much of an incident an analyst can reconstruct within the platform.

From the logs, in a security data lake

Not every vantage point needs software on the workload. Cloud providers, identity systems and SaaS applications all keep detailed records of who did what, and a security data lake can gather those logs in one place for analysis. That makes it possible to trace an attacker across accounts and services, within the limits of what those systems record.

Databricks Lakewatch, introduced in 2026, is an agentic security information and event management (SIEM) product built on Databricks’ lakehouse and extended with Panther, which Databricks acquired in August.

Lakewatch brings together cloud, identity, SaaS and endpoint logs, normalises their formats and supports detections managed as code through CI/CD pipelines, with AI agents helping to triage alerts.

This vantage point can connect a cloud account change to a suspicious login elsewhere without adding an agent. Process activity inside a workload appears only when an endpoint agent or another collector supplies it, so log analysis complements workload runtime monitoring.

From a graph that joins an agentless view to a runtime sensor

The final vantage point combines two of the approaches above: an agentless view of the cloud environment built from provider APIs, and an agent-based sensor on the workloads themselves, both feeding one graph of how resources, identities and data connect.

Wiz brings its agentless assessment and the agent-based Wiz Sensor together in the Security Graph. The agentless side maps resources, identities, exposure and data. Wiz Sensor records workload behaviour.

A disk scan identifies installed packages without showing which ones execute. A process alert, taken alone, cannot establish the workload’s exposure, cloud permissions or access to sensitive data. Wiz Sensor identifies vulnerable packages loaded into memory, and the graph connects its detections to that wider context.

Wiz Sensor covers Linux and Windows VMs, Kubernetes nodes, supported serverless containers and AI infrastructure, and extends into owned environments. It uses eBPF on Linux hosts, and on Windows a thin kernel driver passes events to a userspace engine. Runtime Response Policies can terminate malicious processes across workloads and, on containers, block drift, and teams can simulate the policies before enabling enforcement.

For organisations with extensive cloud estates, this is the most compelling combination here because it joins execution evidence to the relationships needed to assess an incident. Wiz Sensor is a separate, opt-in deployment, so teams that run only the agentless side get the map of their environment without the runtime view.

Choosing where to stand

The strongest runtime security tools cover the environments an organisation operates and connect observed activity with the rest of its estate. Choosing them starts with mapping owned and rented infrastructure, operating systems and serverless deployments.

Wiz is particularly compelling for cloud-heavy organisations that want posture and runtime analysis together, provided they can deploy Wiz Sensor where required. Other organisations will start elsewhere. Teams that already use Datadog for monitoring can add security to the agent they run, engineering teams with the skills to run kernel tooling may prefer Tetragon, and estates with large owned data centres may suit TrendAI’s server-first approach. Lakewatch fits alongside any of them for teams that want their cloud and identity logs analysed in one place.

The attacker in the opening example left three routine-looking records in three different places. Whether that break-in gets caught depends on having tools positioned to record each step, and the context to connect them before the attacker moves on.