Runtime Application Self-Protection Tools Compared

The analyst projections for the RASP market diverge sharply enough to demand some skepticism before you cite any of them. Mordor Intelligence places the market at roughly $2.59 billion in 2026, projecting $8.88 billion by 2031 at a compound annual growth rate near 28%. Research and Markets estimates $1.9 billion in 2025, growing to $9.9 billion by 2032 at 26.3%. Reanin Research, in a June 2026 update, puts 2025 revenue at approximately $2.9 billion and projects $21.7 billion by 2032 at over 33%. That spread reflects a definitional dispute more than measurement error. Some analysts count only purpose-built RASP agents. Others fold in runtime protection capabilities embedded in APM platforms, ADR suites, and cloud-native security tooling. Until the category stabilizes its own boundaries, no single projection deserves uncritical confidence.

The more interesting shift is categorical. The market is migrating from "blocking agent" to "Application Detection and Response." Vendors now layer SOC-grade telemetry, MITRE ATT&CK framework mapping, and incident response workflows on top of the classic inline engine. Contrast Security rebranded Contrast Protect as Contrast ADR in 2024. Datadog and Dynatrace followed with parallel ADR positioning. For a buyer, that evolution changes the evaluation entirely: choosing a "RASP" tool today often means choosing between a lightweight blocking agent and a full ADR platform, each with different cost structures, integration requirements, and operational demands.

The structural driver behind growth, whatever its precise magnitude, is deployment velocity. Microservices and rapid release cycles mean vulnerabilities surface in production faster than traditional security teams can triage and patch. RASP fills that gap continuously, without requiring a rule update or a traffic reroute. As release cadence increases, that value proposition gets stronger, not weaker.

The instrumentation models that separate one tool from another

Instrumentation model is the most consequential differentiator in this category, and it receives less attention in vendor comparisons than feature matrices. Three approaches dominate, and they make different tradeoffs that only become visible under production conditions.

Agent-based bytecode instrumentation intercepts at the method level inside a managed runtime: the JVM for Java, the CLR for.NET. It offers the deepest visibility, the ability to observe data flow at the precise point where logic executes, before results reach any downstream system. The tradeoff is maintenance. Each language requires its own agent, and that agent must be updated against framework and runtime version changes. That work is not glamorous, and teams consistently underestimate it.

Library or module injection wraps specific library calls: SQL drivers, HTTP clients, file I/O APIs. Overhead is lighter, deployment is sometimes simpler, but coverage is narrower. An injection assembled through an unconventional code path, one that bypasses the wrapped library entirely, may escape detection.

eBPF and kernel-level hooks observe system calls from below the application without modifying application code. Language agnosticism is the genuine appeal: a single eBPF probe can observe an execve call regardless of whether the process is Java, Go, or Python. The cost is context. eBPF sees that a shell was invoked; reconstructing the application logic that led to that invocation requires significant additional correlation. In complex applications, that gap elevates false-positive risk in ways that are difficult to predict before deployment.

Why does this matter in practice? Consider a single attack class. Bytecode instrumentation catches SQL injection at the point the query is constructed, before the driver call. Library wrapping catches it at the driver call but misses injections built through unconventional paths. eBPF catches the downstream database connection syscall, but by that point the application context that would distinguish a legitimate parameterized query from an injected one is largely gone. Same attack class, three different interception points, meaningfully different detection rates.

Language coverage is where most teams hit the practical limit first. Java and.NET have broad agent support across vendors. Go has limited but growing coverage from Contrast, Datadog, and Dynatrace. Rust has almost none. Compiled languages make runtime instrumentation significantly harder because there is no managed bytecode to intercept. Teams running polyglot microservices frequently end up with uneven coverage: protected Java services sitting alongside uninstrumented Go or Rust services. That asymmetry is a constraint of the underlying technology, not a vendor failure. But it must be mapped explicitly before any deployment decision, because discovering it afterward tends to produce unpleasant conversations.

The instrumentation choice also determines whether the agent requires an application restart or can attach at runtime, whether it supports a monitor-only mode before enforcement is enabled, and how tightly it couples security posture to a specific framework version. These are operational constraints that surface quickly in production and rarely appear in feature comparison tables.

Contrast Security: the purpose-built RASP baseline and ADR pivot

Contrast Protect, rebranded as Contrast ADR in 2024, is the most established purpose-built commercial RASP option by most informed assessments of the vendor landscape. Its instrumentation model is bytecode-level in the managed runtime: Java and.NET are its strongest languages, with Go support in active development.

The architectural distinction worth examining is the pairing with Contrast IAST. The same agent that protects in production instruments the application during testing, surfacing vulnerabilities as the application exercises them under test traffic. The platform's core claim is unified telemetry across development and production, and it is a defensible one. Teams that instrument once and gain visibility across the full software lifecycle are not running two separate security programs; they are running one continuous program with shared data.

The 2024 ADR repositioning adds MITRE ATT&CK mapping of detected attacks, SOC-facing dashboards, and incident response workflow integration. These are real capabilities, not cosmetic rebranding. They also represent a meaningfully different operational model, one that assumes you have, or want to build, the SOC workflow to use them.

The fit question is straightforward when you frame it clearly. Contrast ADR suits teams that want both runtime protection and a developer-facing security program, and are prepared to invest in a purpose-built platform rather than enabling a security feature inside an APM tool they already own. Teams running significant Go or Rust workloads will have coverage gaps, a constraint that applies broadly to the category. Teams that want only blocking, not the ADR telemetry layer, may find the overhead exceeds their requirements.

Datadog ASM and Dynatrace Application Security: RASP inside the observability platform

Datadog Application Security Management is built on the Sqreen technology Datadog acquired in 2021. For teams already running Datadog for APM, the deployment path is direct: the instrumentation agent is shared, enabling runtime protection requires minimal additional work. Dynatrace Application Security fills the same role on the Dynatrace platform. The logic is identical: one agent, unified telemetry, security alerts presented alongside performance data.

The integration advantage is genuine. When a security event appears in the same pane as a distributed trace, an engineer can immediately correlate an anomalous request with an attack attempt. An engineer investigating a latency spike does not need to pivot to a separate security console. For teams already operating a substantial Datadog or Dynatrace estate, the marginal cost of enabling runtime protection is low enough to make the decision fairly easy.

The constraint is equally real, and worth sitting with. An APM agent is optimized for performance visibility, latency measurement, and error tracking. Those instrumentation points do not map identically to the points a security-focused agent would choose to intercept attack classes. Coverage overlap between the two is substantial but incomplete. In certain attack scenarios, a purpose-built RASP agent will reach points in the execution flow that an observability agent does not reach. How often that gap matters depends on your workload and threat model, and it is difficult to assess before deployment.

Teams not already standardized on either platform face a different calculation entirely. Adopting Datadog or Dynatrace to access RASP capability means taking on full APM cost. That is a legitimate architectural decision if you need the observability platform independently. It is a poor value proposition if RASP is the primary objective.

Both vendors have pushed ADR positioning with MITRE ATT&CK mapping and SOC-facing workflows, parallel to Contrast's repositioning. The category convergence is real. Buyers evaluating all three should apply the same ADR criteria rather than relying on legacy assumptions about what a RASP agent is.

Waratek, Imperva, and OpenRASP: specialist, legacy, and open-source options

Waratek occupies a specific niche that deserves recognition for its narrowness as much as its depth. It instruments at the JVM level without bytecode modification, operating below the application code rather than inside it. For teams running large, complex Java estates where coupling in application code makes bytecode instrumentation risky or operationally impractical, that approach offers surgical coverage with minimal interference. The same characteristic that makes it a poor fit for polyglot environments makes it a strong fit for mature, Java-heavy ones. These tradeoffs rarely get discussed clearly in procurement conversations, and they should.

Imperva RASP, now under Thales following the acquisition, pairs naturally with Imperva WAF for teams already in that ecosystem. Unified policy management across edge and runtime is a real operational benefit. As of 2025, however, Imperva RASP is at end-of-life for new procurement. It is not a viable choice for teams beginning an evaluation today, and existing customers should be actively mapping migration paths rather than waiting.

OpenRASP, developed by Baidu, remains the only free option in the category. It has been unmaintained since early 2022. Using it in production at this point carries the same risk as any abandoned security dependency: vulnerabilities found after the maintenance window closed remain unpatched indefinitely. Its value is as an educational artifact. A team that wants to understand how RASP instrumentation works, how hooks are placed, how detection logic evaluates execution context, before committing to a vendor, can learn a great deal from the codebase. That is not nothing. But it is not a production option.

Outside the core server-side category, AppSealing and LIAPP address mobile application runtime protection; Jscrambler focuses on JavaScript and browser-side execution. For teams with mobile or web-client runtime concerns, these warrant separate evaluation. They sit outside the server-side comparison above.

What each protection model can and cannot intercept

The attack classes where RASP demonstrates structural advantage are reasonably consistent across mature platforms. RASP intercepts SQL injection and NoSQL injection at query construction, before the database driver is reached; the false positive rate for this class is structurally lower than WAF-based detection because there is no ambiguity about what the query contains and where its components came from. RASP catches command injection at the point a shell call is invoked from application code. It detects path traversal when file system access is attempted with attacker-controlled path components. Bytecode-level agents detect deserialization attacks during object instantiation, with Java and.NET coverage strongest. RASP detects SSRF at the outbound HTTP call inside the application, the point where the application initiates a network request based on attacker-controlled input.

The structural limits are equally important, and they define where RASP cannot substitute for other controls. Business logic abuse is the most significant gap. RASP sees execution; it cannot distinguish a legitimate high-value transaction from an abusive one, because there is no instrumentation point that maps cleanly to intent. Authentication and session attacks, credential stuffing and session fixation among them, present a similar problem: RASP sees the call but lacks the behavioral and historical context to distinguish automation from a legitimate user. Compiled native code (Rust, C, C++) leaves almost no instrumentation surface.

The enforcement mode decision deserves more attention than it typically receives. Blocking mode eliminates the attack at the point of detection, but a misconfigured agent in blocking mode can terminate legitimate traffic. Monitor mode produces telemetry without risk but leaves the vulnerability open to exploitation. The standard recommendation across vendors is a staged rollout: monitor to establish a baseline, then transition to blocking once the instrumentation behavior is understood in context. Teams that skip this step tend to encounter blocking-mode incidents that undermine organizational confidence in the tool, sometimes permanently. I have seen this happen more than once, and recovery is slower than people expect.

How containerized and AI agent environments stress-test RASP assumptions

RASP was designed under a specific threat model: the application code is trusted; the attacker is external. The agent's job is to protect known, stable application logic from exploitation by inputs the attacker controls. That assumption held reasonably well for monolithic and early microservices architectures.

Containerized environments complicated it somewhat. Docker containers share the host OS kernel, so a privilege escalation or kernel exploit does not need to escape the application layer; it can move directly from the container to the host. RASP instruments application code and cannot prevent a kernel-level exploit from executing below it. That is a scope boundary, not a product failure. The agent's protection stops at the bottom of the process it instruments. Teams sometimes discover this boundary only after an incident.

AI agent workloads do not merely complicate that assumption; they invert it. When an AI agent generates and executes code, the code being executed is not trusted application logic. It is machine-generated, potentially adversarial, and in many architectures dynamically fetched and run without human review. Veracode's 2025 State of Software Security report found that 45% of AI-generated code fails security tests, suggesting that vulnerabilities are not exceptional occurrences in agent-generated code but a structural condition.

The NVIDIA AI Red Team has documented how unsandboxed AI code execution workflows enable remote code execution via prompt injection, where attacker-controlled input directs the model to execute malicious commands. These are not theoretical findings. Claude Code, Anthropic's coding agent, wiped a user's home directory by executing an rm -rf command with a trailing path separator. Cursor IDE deleted files despite an explicit user instruction not to execute anything. Both incidents were reported from general use, not adversarial research settings.

The structural threat is container escape. A malicious payload in AI-generated code that exploits a kernel vulnerability does not need RASP to fail; it simply needs to operate below the layer RASP can see. Which raises a question worth sitting with: if the execution boundary RASP protects is the application layer, and the threat now originates within code the application itself generates and executes, is the right response a better RASP agent, or a different kind of boundary entirely?

Gartner's projection that the vast majority of cloud security failures through 2026 will result from misconfigurations and runtime risks on the customer side suggests that runtime isolation is moving from optional hardening to foundational infrastructure requirement.

Why AI agent execution requires isolation below the application layer

Application-layer instrumentation, however deep, cannot provide hardware-enforced boundaries. That is the core problem for AI-generated code execution, and it is worth stating plainly before working through the implications.

RASP's instrumentation model assumes the agent can observe the application completely. When the code being executed is generated at runtime by a model, that assumption cannot be verified. The agent is watching code it did not anticipate, code that may have been shaped by an attacker-controlled prompt, running in a context that was never tested or reviewed.

MicroVM isolation, using hypervisors such as Firecracker or gVisor, provides a hardware-enforced security boundary. Each execution environment runs in its own virtualized kernel. A kernel exploit in one microVM does not propagate to the host or to other VMs, because the boundary is enforced by the hypervisor, not by application logic or namespace separation. That is a categorically different guarantee from container isolation, which relies on cgroup and namespace boundaries within a shared kernel. Shared kernel means shared risk.

The principle that makes RASP effective for traditional application security, observing execution from within the runtime, applies at a different layer for AI agent workloads. Some tools operate on this principle by containing each agent execution within a sandboxed environment that instruments the runtime itself, applying the same visibility RASP offers to traditional applications but within a hardware-bounded execution context. The distinction matters because in an AI agent workflow, the code being run cannot be assumed trustworthy before execution. It must be assumed suspect until proven otherwise, which is a different starting posture than anything RASP was designed to handle.

The broader implication is that updating the threat model must come before updating the tooling. RASP remains a well-suited control for its intended environment: protecting known application logic from external exploitation in production. That use case has not disappeared. The injection and deserialization risks RASP addresses are expanding as API surfaces grow.

But teams building agent-driven workflows and extending their existing RASP deployment to cover agent execution without re-examining the threat model are applying a sound control to a context it was not designed for. The right question is not which RASP agent to deploy for AI workloads. The right question is whether the execution boundary the agent protects is the correct boundary for the workload in question, because in a growing number of architectures, it is not.