When should teams add in-kernel ADR instead of relying on RASP?

What in-kernel ADR adds that RASP cannot see

RASP and in-kernel ADR are solving different layers of the same problem. RASP is strongest when you want application-aware visibility into injection, request flow, and business logic abuse inside the process. In-kernel ADR is the better fit when you need host-level enforcement or visibility after execution crosses the application boundary, especially when native code, shell spawn, or process-to-process activity can bypass app-only instrumentation.

That difference matters because many real-world attacks do not stay inside the app. Once an attacker reaches a shell, loads native code, or pivots into child processes, application instrumentation can lose context. Kernel-level monitoring can still observe execution, process lineage, file and network activity, and policy violations at the host boundary, which makes it more useful for post-compromise detection and containment.

In practical terms, the decision is not “which tool is better” but “where does the control need to operate.” If the abuse is still expressed as a malformed request or injected application action, RASP is usually the sharper first layer. If the concern is runtime behavior after compromise, or blocking activity that originates below the app framework, in-kernel ADR is the more relevant control plane.

When the host becomes the security boundary

Teams should move toward in-kernel ADR when the security question changes from “is the application being abused?” to “what is this workload doing on the host?” That shift usually appears when defenders need to correlate spawned shells, suspicious child processes, credential access, unexpected network calls, or policy-breaking execution that would not be visible from request-level telemetry alone.

Kernel visibility is also valuable when the protection requirement is consistent enforcement across many applications, containers, or services. A host-level control can reduce dependence on each codebase implementing its own telemetry correctly. NIST Cybersecurity Framework 2.0 is useful here as a governance lens for deciding whether the control objective is protection, detection, response, or recovery, while NIST SP 800-207 Zero Trust Architecture reinforces the idea that trust should be continuously evaluated rather than assumed because code is running inside the environment.

Kernel-level controls also suit environments where you care about hard containment rather than only alerting. If a workload can generate dangerous side effects after compromise, the host layer is where you can stop those actions or at least make them observable enough to trigger response.

Choosing the right control mix for app abuse versus post-exploitation

The best deployment pattern is often layered. Use RASP where you want the application to recognize and stop injection-class abuse at the point of execution. Use in-kernel ADR when the threat model includes native execution, lateral movement from the host, or an attacker living off the land after initial access. Those two controls are complementary, not interchangeable.

It is also important to be honest about failure modes. RASP can be bypassed if the app is poorly instrumented, the runtime is altered, or the malicious behavior happens outside the app’s visibility. Kernel-level ADR reduces that blind spot, but it introduces a stronger dependency on host compatibility, tuning quality, and operational discipline. MITRE ATT&CK Enterprise Matrix is a useful reference for mapping those post-compromise behaviors to privilege escalation, persistence, lateral movement, and defense evasion patterns. FIRST is also relevant as a coordination reference when host-level detections need to feed incident response workflows and containment decisions quickly.

Risk and Threat Considerations

Choosing only RASP can leave a gap once an attacker escapes the application layer. Native code execution, child-process spawning, and host-level policy violations are classic conditions where app-centric visibility becomes too narrow, especially if the attacker is aiming to persist or move laterally after the initial compromise.

Failure mechanism: Application instrumentation can miss behavior that occurs after process boundaries are crossed, so the attacker shifts from request abuse to host activity that is invisible or only partially visible to RASP.

Impact: Defenders may detect injection attempts but miss the follow-on actions that actually create outage, data access, privilege escalation, or persistence. That delay increases blast radius and makes containment harder.

Practitioner Guidance

What to prioritise: Decide first whether your highest-risk scenarios are in-app abuse or post-compromise host activity. If your incidents tend to end at the request layer, start with RASP; if they extend into shells, native execution, or runtime policy violations, prioritise kernel visibility.

What to verify: Confirm that the control can still observe and constrain the exact behaviors you care about, especially child processes, outbound connections, file writes, and privilege-changing actions. If it cannot see those, it is not the right primary layer.

Practitioner takeaway: Treat RASP as an application-layer control and in-kernel ADR as a host-layer control, and choose based on where the attacker is most likely to survive after the first exploit.

Related resources from NHI Mgmt Group

• How should security teams detect Linux malware that uses masquerading, persistence, and kernel rootkits instead of relying only on hashes?
• When should organisations add runtime controls for AI agents instead of relying on monitoring?
• When should teams use step-up verification instead of relying on reusable identity?
• When should security teams use kernel-level controls instead of eBPF for workload identity?