WAF, RASP and ADR: what runtime security layers change

At a glance

What this is: Aikido’s analysis separates WAF, RASP and ADR by where each control sits in the request-to-runtime chain, showing that edge, app and OS visibility solve different security problems.

Why it matters: IAM and security teams need to understand these boundaries because runtime controls only reduce risk when they are aligned to the exact point where abuse becomes visible and enforceable.

Context

Web application security controls are often grouped together even when they inspect different layers of the stack. The real governance issue is visibility: edge controls see traffic patterns, in-app controls see code execution, and kernel-level controls see operating-system behaviour after execution has already begun.

That distinction matters for identity and access decisions because many runtime abuse cases are really authorization failures, dangerous sinks, or post-compromise actions rather than simple request filtering. In practice, the question is not whether to buy one class of control, but where each layer can enforce policy without guessing about application intent.

Key questions

Q: How should security teams layer WAF, RASP, and ADR for application protection?

A: Use WAF for edge filtering and volumetric abuse, in-app runtime controls for precise sink-level blocking, and eBPF-based ADR when you need host-level visibility or post-exploitation detection. The layers are complementary because each sees a different part of the attack path. The right design follows the threat phase, not a single tool category.

Q: Why do WAFs and in-app runtime controls catch different attacks?

A: They operate at different visibility points. A WAF sees the shape of the request, while an in-app control sees how that request behaves inside the code and whether it reaches a dangerous sink. That means a WAF is better for noisy edge abuse, while in-app controls are better for injection and context-sensitive blocking.

Q: What breaks when runtime protection is detection-only?

A: Detection-only controls leave the final decision to humans after the request has already been processed. In AI environments, that is often too late because prompts, tool calls and API actions can complete in seconds. If the control cannot block at execution time, it is a visibility layer, not protection.

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

A: Add in-kernel ADR when your risk includes post-exploitation activity, native-code bypasses or host-level policy enforcement. If the main problem is injection-class abuse inside the app, RASP is usually the better first control. If you need to see what happens after a shell spawns, kernel-level visibility becomes the relevant layer.

Technical breakdown

WAFs: edge filtering before application context exists

A web application firewall sits outside the application and inspects HTTP requests before they reach code. It works by matching patterns, headers and payload shapes against known attack signatures, which makes it effective for high-volume abuse such as bot floods and DDoS traffic. The trade-off is that it cannot see what the application will do with the request, so it must infer intent from the network layer alone. That makes tuning continuous, because benign traffic can look hostile and hostile traffic can be disguised.

Practical implication: Use a WAF to absorb noisy edge traffic, but do not expect it to decide whether a specific input becomes dangerous inside the app.

RASP and in-app ADR: tracing input to dangerous sinks

RASP and in-app ADR run inside the application and observe how user input moves through code until it reaches a sink, meaning a point where data becomes an executable action such as a database query or shell call. Because the tool sees request origin, data flow and execution context together, it can block attacks with far lower false-positive rates than pattern matching alone. This is why it is strong for injection-class attacks and for detecting issues in third-party libraries at runtime. Its blind spot is anything that bypasses the runtime entirely.

Practical implication: Place in-app runtime controls where you need sink-level blocking and precise authorization-aware decisions inside the application path.

In-kernel ADR and eBPF: observing post-exploitation activity at the OS layer

In-kernel ADR uses eBPF to watch system calls across processes at the Linux kernel layer. It does not understand application logic, but it can see shell spawning, file reads, outbound connections and other host-level behaviour after an attacker has already crossed the application boundary. That makes it useful for post-exploitation visibility and policy enforcement, especially when native code or direct syscalls bypass in-app hooks. The downside is that it has little context for the original request, so it is better at binary policy violations than nuanced application decisions.

Practical implication: Add kernel-level monitoring when you need visibility into host activity after compromise, not as a substitute for application-aware blocking.

Threat narrative

Attacker objective: The attacker wants to move from a filtered request into execution and then into host-level control or post-exploitation activity without being seen by all three layers.

1. Entry occurs at the HTTP edge, where a WAF can inspect requests for known attack patterns but cannot know whether the payload will become dangerous inside the app.
2. Credentialed or malicious input then travels through application code until it reaches a sink such as a database driver or shell call, where an in-app control can still stop it.
3. If the attacker bypasses the runtime or spawns a shell, the operation shifts to operating-system behaviour that only in-kernel ADR can reliably observe.
4. The impact is broader runtime abuse, including post-exploitation commands, lateral movement and host-level policy violations that lower layers no longer see.

Breaches seen in the wild

• Laravel-Lang Composer compromise 2026: A stolen GitHub PAT let an attacker rewrite every Laravel-Lang release tag in May 2026, serving a PHP stealer of cloud, CI and SSH credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime security is a visibility problem before it is a blocking problem: the decisive question is which layer can actually observe the abuse at the moment it becomes enforceable. Edge filtering, code-level tracing and kernel-level monitoring are complementary because they answer different questions about the same request path. Practitioners should map controls to observation points, not buy overlapping products that all fail at the same stage.

In-app context is the only layer that can reliably judge sink-level risk: once user input reaches a database call, command executor or other dangerous function, pattern matching is no longer enough. That is why runtime controls inside the app reduce false positives and handle injection more precisely than perimeter-only tools. For identity and authorization governance, the important insight is that the control point is the sink, not the request source.

Post-exploitation visibility belongs to the OS layer, not the WAF: when an attacker spawns a shell or uses native code, the security problem changes from malformed input to host behaviour. In that phase, kernel-level policy and syscall monitoring become the relevant controls, especially where lateral movement or unexpected process activity is the concern. Practitioners should treat this as containment after execution, not as prevention of initial abuse.

Runtime layering creates a governance stack, not a product stack: the strongest posture comes from assigning each control a distinct responsibility and accepting that no single runtime layer covers edge abuse, application abuse and host abuse equally well. That is the governance model teams should use when evaluating runtime security, because it turns overlap into deliberate coverage rather than accidental duplication.

What this signals

Runtime control strategy should be built around enforcement boundaries, not feature lists. Teams that collapse edge filtering, in-app tracing and kernel telemetry into a single category usually misplace one of the controls. The more mature pattern is to decide which abuse phase each layer can actually stop, then measure coverage gaps between request handling, execution and host behaviour.

Application-runtime governance is becoming a three-layer model: edge controls manage hostile traffic, in-app controls manage dangerous data flow, and OS-level controls manage post-exploitation activity. That split is especially relevant for teams that need both injection prevention and identity-aware authorization decisions inside runtime workflows. A layered model reduces the chance that one control is forced to compensate for another control’s blind spot.

For practitioners

• Define control placement by attack phase Map each runtime control to the phase it can actually observe: edge request inspection, in-app sink blocking or host-level syscall monitoring. Use that map to expose gaps where one layer is being asked to do another layer’s job.
• Treat sink-level decisions as application policy Identify database drivers, shell execution points and other sinks, then require in-app controls for the inputs that reach them. This is where context-aware blocking belongs, because request patterns alone cannot decide whether execution is safe.
• Reserve kernel monitoring for post-exploitation visibility Use in-kernel ADR where you need to see shell spawning, file reads, network calls and lateral movement after an attacker has already executed code. Do not rely on it as the primary guard for injection or request-layer abuse.
• Tune WAF policy around noisy edge abuse Use the WAF for high-volume threats such as bot traffic, scrapers and DDoS, then review false positives continuously. If the edge layer is being used as an application-policy engine, tighten the scope and move the decision closer to the code.

Key takeaways

• WAF, RASP and ADR solve different visibility problems, so runtime security fails when teams treat them as interchangeable.
• The meaningful control boundary is where request data becomes executable behaviour, not where traffic first arrives.
• Layering edge, app and OS monitoring creates broader coverage for injection, post-exploitation and host-level abuse.

Key terms

• Web Application Firewall: A web application firewall inspects HTTP traffic and applies rules to detect or block malicious requests and responses. Unlike a network firewall, it understands application-layer content such as headers, parameters, and body fields, which lets it catch attacks like injection and path probing.
• Runtime Application Self-Protection: RASP is a runtime control that detects and can block suspicious application behaviour as it happens. In NHI contexts, it can contain abuse from service accounts or tokens, but it does not replace identity ownership, entitlement review, rotation, or deprovisioning.
• eBPF-Based ADR: eBPF-based ADR is kernel-level runtime detection and response that observes system calls and host activity below the application. It is strong for post-exploitation visibility, shell spawning and unexpected process behaviour, but it lacks the application context needed to judge request intent or sink-level risk.
• Sink: A sink is a point in code where input stops being inert data and becomes an action, such as a database query, shell command, or file write. Runtime controls focus on sinks because that is where a benign-looking request can turn into a security incident.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, machine identity security, and secrets management in a way that helps teams connect identity controls to runtime risk. It is the industry's only accredited NHI security programme, designed for practitioners who need governance clarity across modern security stacks.