back to resources
Blog

Let’s Not Water Down What Runtime Means

Bret Settle
Co-Founder, Chief Product Officer
Posted:
October 19, 2026
read time:
0 mins
words by:
Bret Settle

For the past year and a half, we’ve been talking about the importance of runtime security at RoonCyber. It’s encouraging to see runtime becoming a much bigger part of the cybersecurity conversation, especially as organizations try to secure rapidly expanding AI environments.

There’s a reason the market is moving in this direction. Security needs to keep pace with software while it runs. In an AI environment where agents take actions, call tools, access APIs, touch data, and make decisions at machine speed, knowing what is actually executing has never been more important.

What I don’t want to see is the industry embrace runtime while watering down what the term means.

Inspecting the Conversation Is Not Runtime

I’ve increasingly seen technologies described as runtime because an LLM, or a set of models, is listening to or analyzing agent activity as it occurs. The market seems increasingly willing to accept that definition.

We should be careful here.

Sending an event to an LLM for analysis does not suddenly make the underlying security technology runtime. The event may have happened at runtime, and the LLM may provide valuable analysis of it, but that is fundamentally different from directly observing workload execution.

If we need a category for that approach, it is much closer to a guardrail or gateway. Those technologies have a role to play and can be very good at what they were designed to do. The problem comes when we call them runtime and create the impression that they provide visibility they simply do not have.

Consider what an AI gateway or control plane sees when an agent calls a tool: the request going in and the response coming back. Both can look perfectly reasonable. What it doesn’t see is everything in between: the tool spawning a shell, reading a credentials file, writing to disk, or opening a connection to a host nobody approved.

Inspecting requests and responses at machine speed is valuable. But that is inspection at the boundary, not observation of execution. Runtime is what happens between the request and the response.

We Already Have the Technology to Do This Right

This is particularly frustrating because we no longer need to redefine runtime around technical limitations.

The technology exists.

At RoonCyber, we took the time to build at the runtime layer. We use eBPF to continuously observe activity at the kernel level: process execution, syscalls, file access, network connections, and application behavior as it happens. That gives us direct visibility into execution with low performance overhead.

That foundation makes runtime more than another detection mechanism. It provides a continuously updated inventory of what is actually running and the context to understand what those workloads are doing. When something malicious happens, the same runtime evidence drives the response, from killing a malicious process to isolating an impacted application to contain the threat.

That is what we believe runtime was always supposed to become: security that runs alongside the software it protects, with the context to understand execution and the ability to act when necessary.

Real-Time Is Not the Same as Runtime

Security has spent years moving beyond point-in-time visibility, and many of the tools now claiming runtime are genuinely real-time. They inspect every request as it happens. But real-time is a measure of speed. Runtime is a vantage point. A tool can see every request and response the moment they occur and still never see the execution behind them.

If we start describing request inspection, event analysis, or LLM-based interpretation as runtime, we risk moving backward. We take a term that describes a meaningful technical capability and turn it into another marketing label that can be applied to almost anything.

Cybersecurity already has enough of those.

There are plenty of technologies that do specific things extremely well. Guardrails enforce policies around AI interactions. Gateways control the traffic passing through them. LLMs help security teams make sense of enormous amounts of telemetry. Scanners identify risk at a point in time.

None of that is a criticism. Most organizations will need several of these. But none of them is runtime, and calling them runtime doesn’t let them see what runtime sees. Let’s keep the word meaning something.

‍

we're online

We’re ready for you! Schedule a demo

Request A Demo
Blog

Let’s Not Water Down What Runtime Means

Words by:
Bret Settle
read time:
This is some text inside of a div block.
This is some text inside of a div block.

For the past year and a half, we’ve been talking about the importance of runtime security at RoonCyber. It’s encouraging to see runtime becoming a much bigger part of the cybersecurity conversation, especially as organizations try to secure rapidly expanding AI environments.

There’s a reason the market is moving in this direction. Security needs to keep pace with software while it runs. In an AI environment where agents take actions, call tools, access APIs, touch data, and make decisions at machine speed, knowing what is actually executing has never been more important.

What I don’t want to see is the industry embrace runtime while watering down what the term means.

Inspecting the Conversation Is Not Runtime

I’ve increasingly seen technologies described as runtime because an LLM, or a set of models, is listening to or analyzing agent activity as it occurs. The market seems increasingly willing to accept that definition.

We should be careful here.

Sending an event to an LLM for analysis does not suddenly make the underlying security technology runtime. The event may have happened at runtime, and the LLM may provide valuable analysis of it, but that is fundamentally different from directly observing workload execution.

If we need a category for that approach, it is much closer to a guardrail or gateway. Those technologies have a role to play and can be very good at what they were designed to do. The problem comes when we call them runtime and create the impression that they provide visibility they simply do not have.

Consider what an AI gateway or control plane sees when an agent calls a tool: the request going in and the response coming back. Both can look perfectly reasonable. What it doesn’t see is everything in between: the tool spawning a shell, reading a credentials file, writing to disk, or opening a connection to a host nobody approved.

Inspecting requests and responses at machine speed is valuable. But that is inspection at the boundary, not observation of execution. Runtime is what happens between the request and the response.

We Already Have the Technology to Do This Right

This is particularly frustrating because we no longer need to redefine runtime around technical limitations.

The technology exists.

At RoonCyber, we took the time to build at the runtime layer. We use eBPF to continuously observe activity at the kernel level: process execution, syscalls, file access, network connections, and application behavior as it happens. That gives us direct visibility into execution with low performance overhead.

That foundation makes runtime more than another detection mechanism. It provides a continuously updated inventory of what is actually running and the context to understand what those workloads are doing. When something malicious happens, the same runtime evidence drives the response, from killing a malicious process to isolating an impacted application to contain the threat.

That is what we believe runtime was always supposed to become: security that runs alongside the software it protects, with the context to understand execution and the ability to act when necessary.

Real-Time Is Not the Same as Runtime

Security has spent years moving beyond point-in-time visibility, and many of the tools now claiming runtime are genuinely real-time. They inspect every request as it happens. But real-time is a measure of speed. Runtime is a vantage point. A tool can see every request and response the moment they occur and still never see the execution behind them.

If we start describing request inspection, event analysis, or LLM-based interpretation as runtime, we risk moving backward. We take a term that describes a meaningful technical capability and turn it into another marketing label that can be applied to almost anything.

Cybersecurity already has enough of those.

There are plenty of technologies that do specific things extremely well. Guardrails enforce policies around AI interactions. Gateways control the traffic passing through them. LLMs help security teams make sense of enormous amounts of telemetry. Scanners identify risk at a point in time.

None of that is a criticism. Most organizations will need several of these. But none of them is runtime, and calling them runtime doesn’t let them see what runtime sees. Let’s keep the word meaning something.

‍

Register now:
we're online

We’re ready for you! Schedule a demo

Request A Demo