RASP vs WAF for Runtime Protection of AI Code Execution Endpoints

I've spent enough time staring at incident writeups from AI code execution platforms to have a strong opinion here: WAF and RASP are both necessary, and both, on their own, address a narrower slice of the problem than most teams assume. The dangerous thing at an AI endpoint is rarely the HTTP request itself. More often it's the sentence in plain English that an LLM reads, decides to act on, and turns into a running process with filesystem access and maybe a live credential sitting in the environment. Getting from "request arrived" to "agent did something irreversible" is the whole story, and most security stacks I've looked at aren't built to see the middle part happen at all.

OWASP's 2025 Top 10 for LLM Applications puts prompt injection in the number one spot. Separately, security audits find 73% of production enterprise AI deployments are vulnerable to prompt injection. That's a routine occurrence, not an edge case you insure against. So the real question isn't which vendor's product wins some bake-off; it's which layer of your stack can physically see the danger as it forms. Visibility, more than cleverness, is what decides whether a tool can stop anything.

What WAF is designed to do and where its visibility ends

A WAF sits at the network and HTTP layer, checking requests before they reach the application. Predefined rules, known signatures, pattern matching against things that look like SQL injection or cross-site scripting. At an inference endpoint this catches real problems: volumetric abuse, malformed requests, obvious exploit strings in headers, rate limiting so one client can't hammer an API into the ground.

What it can't see is the content of a perfectly well-formed POST body carrying an adversarial prompt. Nor can it see the code an LLM writes in response, and it has limited visibility into what that code does once it starts running, which is really the whole problem in one sentence.

Here's the thing though: the perimeter problem is straining WAF on its own terms, before AI even enters the picture. Web application and API attacks reached hundreds of billions in 2024, up sharply year over year. Volume, more than sophistication, is outscaling even the threats WAF was purpose-built for. Add in the industry breach reporting finding that the large majority of breaches in the basic web application attack pattern involved stolen credentials, and the picture gets uglier. A request made with valid, stolen credentials looks completely legitimate to a perimeter filter. There's no signature to match, and nothing malformed to flag.

Now set a prompt injection payload next to that. It isn't obfuscated. It's grammatically ordinary language, engineered to read as a normal request, and that's the crux of it: this isn't a missed rule update or a stale signature list. It's a category mismatch. WAF hunts structural anomalies, and the attack is structurally unremarkable by design. It earns its keep at the edge of an AI endpoint, but its usefulness tapers off right where the AI-specific risk actually starts.

How RASP works and why its position inside the runtime changes what it can observe

RASP, Runtime Application Self-Protection, sits inside the process rather than at the edge, hooked into the runtime, watching how the application handles a request instead of what the request looked like on the wire. Small distinction on paper. Enormous in practice.

Because it's in-process, RASP sees call stacks, memory state, system calls, the actual path a piece of code takes once it's executing. Those are exactly the signals that give away something dangerous: an unexpected outbound connection, a file write somewhere it has no business touching, a subprocess spawning out of nowhere. When RASP flags a path like that, it can kill the process, cut the request, or fire an alert, all from inside the context where the thing is actually happening.

That's a different kind of decision than a WAF makes. A WAF asks whether a payload resembles something known to be bad. RASP asks what the application actually did, in real time, regardless of whether the input looked suspicious going in.

Worth noting: the category's been consolidating. ADR, Application Detection and Response, is now the standard framing for mature RASP, same in-process instrumentation plus SOC-facing extras like attack timelines, MITRE ATT&CK mapping, SIEM and XDR hooks. Contrast Security rebranded its RASP line as Contrast ADR in 2024. Datadog and Dynatrace went the same direction. Imperva, meanwhile, announced end-of-life for its standalone RASP product in 2025, with support running out March 2028, which reads less like the category dying and more like it getting absorbed into a bigger runtime security umbrella.

Why RASP's contextual awareness maps directly onto the AI agent threat model

Line up the dangerous behaviors in AI code execution against what RASP was built to watch, and the overlap is almost suspicious. Arbitrary code running. Filesystem writes. Outbound calls. Credential access. These are runtime signals, full stop, and runtime signals are exactly what in-process instrumentation exists to catch.

Walk prompt injection through to where it actually lands. A crafted prompt sails past HTTP inspection because there's nothing in the text itself to flag. The LLM processes it, writes code, and that code opens an outbound connection carrying data it shouldn't touch. The exfiltration shows up as a syscall or a network connection, visible to anything watching the runtime, invisible to anything that only ever looked at the request body.

This already happened, more than once. EchoLeak, CVE-2025-32711, CVSS 9.3, involved a specially crafted email that triggered Microsoft 365 Copilot into quietly exfiltrating sensitive documents while summarizing an inbox. No malicious HTTP payload anywhere in the chain; the entire attack lived in the model's output and the runtime action that followed it. CurXecute, CVE-2025-54135, CVSS 9.8, worked the same trick from a different angle: prompts hidden inside a repository's README caused Cursor's AI assistant to run arbitrary commands the moment a developer opened the project. Execution time, not the edge, both times.

Here's an uglier fact worth sitting with for a second: the code an agent writes can be a liability on its own, with no injection attack involved at all. Veracode's 2025 report found 45% of AI-generated code fails security tests. Nearly half. That means runtime inspection ends up being the layer best positioned to catch execution-time faults in code the agent wrote for entirely legitimate reasons, no attacker required.

There's a supply chain angle too, and it's a nasty one. The Shai-Hulud campaign, which surfaced in late 2025, compromised npm packages specifically targeting AI agent workflows. An agent installing dependencies freely, with no runtime visibility into what those packages do once they execute, is handing an attacker a lateral movement path dressed up as routine tooling.

Simon Willison named the shape of this back in June 2025: the "lethal trifecta," access to private data, the ability to talk to the outside world, and an agent acting without a human checking each step. Stack those three and you've got a threat that the HTTP perimeter simply cannot address, because none of the three conditions looks unusual in a request header. Not one.

The attacks that expose RASP's own limits in the AI execution context

RASP isn't the final word here, and I'd rather say that plainly than dress it up. It instruments the runtime it's attached to. If an agent spins up a subprocess or hands work off to a separate execution environment, that child process can fall entirely outside RASP's view. It only watches what it's wired into, which sounds obvious until you're the one debugging why an alert never fired.

The ground under it is also shifting fast. Frontier model performance on apprentice-level cybersecurity tasks rose from under 10% in late 2023 and early 2024 to roughly 50% by 2025, per industry benchmarking. Sandbox and instrumentation designs calibrated to what models could do two years back may already be undersized for what they can do now. Not a knock on any specific vendor. Just a statement about how fast the target moves.

Some attack surfaces sit entirely outside RASP's field of view. RAG poisoning is one: research has shown that as few as five carefully crafted documents inserted into a knowledge base can manipulate AI responses in the large majority of cases, through retrieval-augmented generation. RASP has no visibility into the knowledge base at query time; that's not part of the application's execution path in any sense it can instrument. Data poisoning goes further upstream still. CyLab research from 2025 found that manipulating as little as 0.1% of a model's pre-training dataset is enough to launch an effective poisoning attack. That's training-time compromise, well outside the application layer where RASP lives.

Even the fixes can create new problems. LLM-generated patches introduce new vulnerabilities in roughly 9.5% of cases while resolving the original one, so the corrective loop carries its own risk. RASP can catch a known attack pattern showing up in patched code well enough. A genuinely novel logic flaw it's never seen before is a much harder ask, because pattern recognition, however contextual, still needs a pattern.

Then there's the infrastructure layer sitting below everything. CVE-2025-6514, CVSS 9.6, is a remote code execution flaw in core MCP infrastructure used across a huge swath of the agent developer ecosystem. A vulnerability at that depth bypasses application-layer controls entirely, RASP included, because the compromise happens beneath whatever RASP is watching.

None of this is an argument for dropping runtime inspection. It's an argument for putting something underneath it that holds the line when instrumentation misses, because it will miss eventually.

Isolation at the sandbox level as the layer RASP and WAF both assume exists beneath them

Both WAF and RASP are detection-and-blocking tools, and both quietly assume that if they miss something, a boundary still exists to contain the fallout. In AI code execution, that boundary is the sandbox. Yet "sandbox" is doing a lot of work as a word, because the isolation strength it can mean varies wildly, and that variance matters a great deal once something actually goes wrong.

Standard containers share the host kernel. Namespace isolation, useful, but thin. gVisor intercepts system calls in user space, which adds a kernel boundary on top of a container-style deployment. MicroVMs, Firecracker and Kata Containers being the names most people in this space recognize, give each workload its own dedicated kernel, the strongest isolation available for running code you don't fully trust. These aren't interchangeable tiers of the same thing. They're a hierarchy, and where a platform sits on it decides what a worst-case escape actually costs you.

The Leaky Vessels container escape, CVE-2024-21626, made the container-only weakness concrete: a crafted Dockerfile could resolve the container's working directory out to the host filesystem, opening a path to host traversal. NIST SP 800-190 states the underlying reason plainly: containers rely on OS-level virtualization where multiple applications share a single host kernel. That shared kernel is exactly the attack surface microVMs remove, by giving each workload its own from the start.

AI agent workloads raise the stakes on this in a way that's easy to overlook. Agents run long, and they're stateful, which means the isolation boundary has to hold not for one HTTP request but across a session that might run hours, sometimes days in agentic workflows. A boundary solid enough for a millisecond-scale request isn't automatically solid for a multi-hour agent task carrying persistent state the whole way through.

The division of labor, stated plainly: RASP tells you something bad is happening inside the application. The sandbox limits what that bad thing can reach once it's happening, whether or not anything upstream caught it in time.

How purpose-built agent runtimes operationalize all three layers together

Bolt a WAF onto a generic container orchestrator and call it a day, and you're likely missing the actual threat, which is untrusted, machine-written code running at scale. A purpose-built agent runtime is built around that specific fact: the code it executes was written moments ago by a model, from a prompt it didn't fully control.

In practice the three layers stack like this. Edge filtering, the WAF or API gateway, handles rate limiting, auth enforcement, basic abuse prevention on the inference endpoint. Runtime instrumentation, RASP or ADR, gives in-process visibility into what the agent's generated code is actually doing: syscall monitoring, outbound connection inspection, anomaly detection on the execution path itself. Kernel-level isolation, a microVM or a gVisor sandbox, provides the hard boundary that contains the damage if the runtime layer misses something.

Two operational requirements get underweighted constantly in this conversation, and I think it's because they sound like infrastructure trivia rather than security decisions. First, statefulness: agents running long tasks need sandboxes that hold filesystem and memory state across an entire session, because a throwaway container that resets on every call breaks any agentic workflow building on a prior step. Second, provisioning speed. Do the math on this one: a sandbox that takes several seconds to cold start means a platform serving many concurrent users pays that latency tax on every single session, and it adds up fast at any real scale. Sub-second cold starts aren't a nice-to-have anymore. They're closer to an architectural requirement.

Purpose-built agent runtimes designed around these constraints address them differently than tooling retrofitted from general developer infrastructure. Sub-90ms cold starts, persistent stateful workspaces, a dedicated kernel, filesystem, and network stack per sandbox, Docker-native compatibility, and coverage across SOC 2, HIPAA, and GDPR. LangChain, n8n, Clay, and SambaNova use it, and it's open source rather than a closed execution service, which matters if you actually want to verify what the isolation boundary is doing instead of taking a vendor's word for it.

Other platforms made different bets on the same underlying problem. Northflank runs a high volume of isolated workloads monthly using Kata Containers and gVisor, with no cap on session duration, which suits multi-week agent projects needing state alive for a long stretch. Google's Agent Sandbox, launched as a CNCF project at KubeCon NA 2025, gives teams a declarative Kubernetes API for managing isolated, stateful sandbox pods, with gVisor or Kata Containers as selectable backends depending on risk tolerance. Microsandbox, open-source, released May 2025, targets teams that want to self-host, using microVM isolation through libkrun.

Choosing among these is as much a security decision as an infrastructure one. The isolation technology, the session persistence model, and the compliance posture are all decided at the runtime layer, which makes picking an agent runtime a security decision whether or not it gets treated as one during procurement.

Where WAF still earns its place in an AI endpoint security stack

None of the above argues for ripping WAF out. AI inference APIs are still HTTP endpoints, exposed to the same DDoS traffic, credential stuffing, and API abuse WAF has handled competently for years. Stripping it out to go "AI-native" would open a real, well-understood gap for no good reason.

WAF also does something quiet and easy to undervalue: it filters noise before it reaches the runtime layer. Block the obvious junk at the edge, and RASP has less to sift through, which lowers the false-positive rate on runtime alerts and keeps the signal cleaner for whoever's watching it.

The industry framing here is settled, and for good reason. WAF and RASP work very differently but aim at the same outcome; if something slips past the WAF, RASP is positioned to catch it with code-level context the WAF never had. Additive layers, not competing bids for the same job. The practical setup for an AI code execution endpoint follows directly: WAF at the API gateway for edge-layer threats, RASP or ADR inside the agent runtime for execution-context threats, sandbox isolation underneath both as the hard containment boundary when the first two both miss.

What "structurally insufficient" means for teams building AI code execution products today

I use that phrase deliberately, not as a flourish. WAF-only protection on an AI code execution endpoint leaves a gap that no amount of rule tuning closes, because the threat model demands visibility into runtime behavior that the WAF layer, by its architecture, was never given access to. That's not a knock on WAF engineering; it's just what the tool is.

So where does a team actually start? Map what the agent can do at runtime: filesystem access, outbound calls, subprocess execution, the scope of whatever credentials it's holding. That capability surface is the real attack surface, and it needs coverage at the runtime layer, not just at the gateway.

The trend line says this stops being optional soon, if it was ever optional. OWASP's 2026 LLM Security Report puts year-over-year growth in prompt injection attacks at 340%. That kind of growth rate means perimeter-only postures are being exploited right now, actively, not theoretically outmatched by some future threat model nobody's built yet.

Ask yourself two things, then, before deciding your current stack is fine. Does your security tooling actually see what the agent's generated code does after it runs, or does it only ever see what showed up at the endpoint before execution even started? And if runtime monitoring misses something, what's the actual blast radius: a hard isolation boundary sitting beneath the application, or a missed detection turning straight into host-level exposure? The answers matter more than any feature comparison between vendors, because they tell you whether the stack you built actually matches the threat you're running against, or just looks like it does on a slide.