The short version. Putting defense inside the application was the right idea. RASP proved it and then died of it anyway. It failed not because it could not catch attacks, but because it could not be left on. The category is now being reborn as ADR, and it is on track to repeat the same mistakes for one reason: it still asks a developer to trust a black box that might break production. The successor that survives will be the one that earns the right to block, one feature at a time, and can prove why it blocked.
A good idea with a body count
RASP, Runtime Application Self-Protection, had a clean thesis. A web application firewall guesses at intent from outside the app, where it cannot see what the request will actually do. RASP moved the defense inside, into the running application, where intent is unambiguous. On paper this ends the guessing game.
A decade later the verdict is in. RASP never became a default. Incumbents have been sunsetting it; Imperva announced end-of-life for its RASP product. The market quietly re-branded the same in-application premise as "Application Detection and Response," ADR, and analysts started drawing new quadrants. Almost nobody wrote down why the first attempt failed, which means the second attempt is walking into the same wall with a new logo.
Here is the autopsy, and it is not about detection.
Why it actually failed
RASP could catch attacks. That was never the problem. It failed for reasons that have nothing to do with exploit-catch rate and everything to do with living inside a real engineering org:
- The false-positive death spiral. One wrongful block of a legitimate request, one Friday outage traced to the security agent, and the developers rip it out. It only has to happen once. After that the tool is disabled or permanently pinned to "monitor only."
- Monitor-mode forever. Because nobody trusts it to block, it watches and alerts and never enforces. A defense that never enforces is a very expensive log.
- The instrumentation tax. Every language and framework is its own integration, its own overhead, its own compatibility surface. The debt compounds with every runtime you add.
- Split ownership. AppSec owns the risk, Dev owns the app, and the tool sits on the seam. Nobody wants to be the one who turned on blocking and broke checkout.
Notice that none of these are about whether the technology works. They are about whether a human will leave it turned on. RASP lost the adoption game, not the detection game. Any successor that does not fix adoption will lose it the same way.
The trap ADR is walking into
The current ADR pitch is mostly a better sensor. Deeper tracing, eBPF, per-library visibility, richer signals. All genuinely useful. None of it addresses the thing that killed RASP. A more accurate black box that a developer still does not trust to block is still going to sit in monitor mode. You cannot detect your way out of an adoption problem.
There is a second, quieter trap. Most of these products, RASP and ADR alike, learn from a global, cross-customer model. That gives you day-one coverage, but it also means the baseline is everyone's average, not your application. Your app has its own shape: its own endpoints, its own parameter types, its own legitimate weirdness. A global model treats your normal as someone else's anomaly, and that is a false-positive factory.
What the successor has to do
Three commitments, and they are non-negotiable if the goal is enforcement in production rather than another monitor-only shelfware line item.
One. Learn what is normal for you, not for everyone. The unit of defense should be a per-tenant behavioral envelope, learned from your application's own traffic: which endpoints exist, what shapes their parameters take, what a valid response looks like, what sequence of calls is real. An attack is then a deviation from your normal, not a match against a generic pattern. This is a positive security model, and it is the only model that catches app-specific abuse and the occasional exploit that manifests as behavior your app has never produced before.
Two. Earn the right to block. Never jump straight to enforcement. Observe, then alert, then enforce, and gate each transition on evidence: enough samples, a stable baseline, a projected false-positive rate under budget. Enforcement should turn on per feature when that feature is statistically ready, not globally on a hopeful switch. And the first wrongful block should be one click to approve as legitimate and re-learn, not a support ticket and an outage.
Three. Prove why you blocked. Every enforcement action should ship with its evidence: the learned-versus-observed diff, the request, the reason. A block that a developer can inspect and understand in ten seconds is a block they will leave on. A block with no explanation is the exact thing they ripped out of RASP.
How Nemesis Shield is built around this
Nemesis Shield is a runtime protection platform built from the RASP autopsy outward. Its application engine learns a per-tenant baseline of your app, API, and LLM behavior, then blocks the deviations a signature WAF cannot see. It installs in one line, with no access to your source code: the SDK ships structural sketches of request and response shapes, hashed on the device, never your raw payloads or PII. What leaves your process is the shape of traffic, not its contents.
The enforcement model is observe, then alert, then enforce, gated on readiness, with shadow mode so you can see what it would have blocked before it blocks anything. Every block carries its proof. And Shield is honest about the edges: a positive security model catches deviations, it does not prevent every zero-day, and an attack that stays entirely inside your learned envelope, pure logic abuse that looks like normal traffic, will not be caught on behavior alone. That is a narrow band, and we name it rather than paper over it.
Shield is in early access, and the honest status matters: the behavioral learning, cross-layer correlation, and enforcement logic are built and tested, while the production edge data plane and scale-out are still being wired. We would rather tell you that than sell you a deployed system that is not.
The test for any runtime defense you evaluate
Hold every vendor, us included, to the criteria that predict whether a tool reaches enforcement:
- Can it be left on? How many weeks from install to blocking by default, and what is the documented false-positive budget?
- Whose normal does it learn? Per-tenant, or a global cross-customer average?
- What happens on a wrongful block? One-click re-learn, or a ticket and an outage?
- Does it explain its blocks? Can a developer understand a specific enforcement action without calling support?
- What does it admit it misses? A vendor that claims to prevent every attack is telling you it has never been honest about the ones it will not.
RASP was right about where defense belongs. It was wrong about how to earn the trust to enforce there. The category that gets that second part right is the one that finally gets to stay on.
Nemesis Shield is the runtime protection platform from Nemesis Labs: per-tenant behavioral baselines for apps, APIs, and LLMs, observe-then-enforce, and proof on every block. In early access. nemesislabs.xyz/shield