Runtime Application Self-Protection for AI Workloads

There's a specific kind of security problem that only reveals itself after you've already been burned. Prompt injection, RAG poisoning, malicious tool calls. These aren't theoretical attack categories. They're what happens when you deploy a language model into production and assume the same defenses that protected your web app will protect your AI workload.

They won't protect your AI workload.

Stanford's 2025 AI Index documented 233 AI-related incidents in 2024 alone. That's a 56.4% year-over-year increase. During the same period, organizational AI adoption climbed from 55% to 78%. More deployments, more incidents, roughly in lockstep. By late 2024, 41% of enterprises had already reported some form of AI security incident (data poisoning, model theft, exfiltration).

That's not a maturity gap: that's a structural problem.

So what is the structural problem, exactly? The threat lives inside the inference process itself. And most security tooling isn't designed to look there. That's the question this piece tries to answer: if the attack happens inside the model, what does a defense that lives there too actually look like?

RASP Is Actually a Pretty Old Idea. That's Why It's Worth Revisiting.

Runtime Application Self-Protection (RASP) is not new. The concept has been around in Java and.NET environments for years. The core idea is simple: instead of standing outside the application and watching traffic, you embed an agent inside the application that watches execution as it happens.

That distinction matters more than it sounds.

A perimeter defense sees the shape of a request. RASP sees what the application actually does with it. It observes method calls, memory behavior, data access (the real execution path) and blocks exploitation in-line, before consequences propagate.

Traditional RASP deployments build behavioral baselines. Normal execution looks like X. When the runtime deviates meaningfully from X, the agent flags it, blocks it, or both. No signature required. No prior knowledge of the specific exploit needed.

Now ask yourself: why wouldn't that principle apply to an AI workload?

The execution flow in an LLM pipeline is different. Prompt in, model processing, tool calls, output out. But the principle is identical. You want in-process observation, behavioral detection, and in-line blocking. The behavioral anomaly isn't a buffer overflow anymore. It's a prompt that steers the model outside its intended operating envelope. But the architectural response is the same: watch what's actually happening, not just what's approaching the front door.

The Threats That Live and Die at Inference Time

Here's the uncomfortable part. Most of the meaningful AI attack categories are invisible to anything sitting outside the inference process.

Prompt injection is ranked number one in the OWASP Top 10 for LLM applications (2025 edition). Attack success rates range between 50% and 84% depending on model configuration. One dataset cited in security research logged over 461,000 prompt injection submissions in 2025 alone. That's not a niche research problem — that's industrial-scale exploitation.

There are two main flavors worth understanding:

• Direct injection. A user crafts input that overrides the system prompt. The model starts following attacker instructions instead of developer instructions.
• Indirect injection. Malicious instructions are embedded in content the model retrieves. A webpage. A document. A tool response. The model reads it, interprets it as instruction, and complies. Multi-hop attacks through agents and tools increased over 70% year-over-year between 2025 and 2026.

RAG poisoning targets retrieval-augmented generation pipelines, where the model pulls from a document store before responding. Research has shown that just five carefully crafted documents can manipulate AI responses 90% of the time. More than half of companies now rely on RAG and agentic pipelines. The retrieval step is a trust boundary that most architectures treat as clean input, and it isn't.

Excessive agency attacks (OWASP LLM06:2025) are worth pausing on because they're particularly counterintuitive. The model isn't malfunctioning. It's doing exactly what it was built to do: calling real APIs, querying real data stores, executing legitimate tool functions. It's just doing those things under adversarial direction. No signature distinguishes a legitimate tool call from an injected one without behavioral context.

Model extraction happens through the production API. Valid-looking queries, abnormal aggregate pattern. Success rates in research settings range widely depending on query budget and architecture complexity, and remain high enough to constitute a real operational concern.

Insider data exfiltration deserves its own line. Samsung engineers leaked source code and internal meeting notes to a public LLM service within weeks of the company lifting its usage ban. Three separate incidents. Gartner projects that 80% of unauthorized AI transactions through 2026 will stem from internal policy violations rather than external attacks. The threat is not always adversarial — well-intentioned employees bypassing policy create the same exposure.

What connects all of these? None of them leave a signature at the network perimeter. All of them require visibility into what the model receives, processes, and emits.

WAFs and Static Scanners Are Fighting the Last War

This isn't a knock on WAFs. They do what they were designed to do. They inspect inbound traffic, block known attack patterns, and prevent malformed requests from reaching the application. That's valuable. But it's also irrelevant to inference-time attacks.

A WAF has no visibility into what happens once the request is inside the model. And for AI, the problem is structurally worse than it is for conventional apps. Semantically valid natural language can carry adversarial intent that no pattern-matching rule can distinguish from legitimate use. The injection doesn't look malformed. It looks like a user asking a question.

WAFs also generate high volumes of low-context alerts. Per Contrast Security's research, WAF signals show an extremely low correlation to real exploits. That false-positive rate is already hard to manage in a conventional application. In a high-volume inference environment, it's operationally unsustainable.

Static analysis and pre-deployment scanning have a different problem. They examine code and model weights before the system runs. That's useful (and necessary) but it tells you nothing about what the model will do given an arbitrary future input. You can't scan your way to runtime safety.

CrowdStrike's 2025 Global Threat Report documented attacker breakout times as fast as 51 seconds, with 79% of detections being malware-free. That's the speed-of-attack problem in concrete terms. By the time a perimeter alert fires, the injection may already have triggered a tool call or produced a poisoned output. The detection window has to be inside the execution path, not behind it.

Three Control Points. Miss One and You've Left a Door Open.

Runtime security for an LLM pipeline concentrates around three specific places. Think of them as checkpoints in the inference flow.

Control Point 1: System Prompt Integrity

The system prompt defines the model's operating envelope. It's the developer's instructions to the model: what it can do, what it can't, and how it should behave. Unauthorized modification of the effective system prompt is the precondition for most agentic exploitation.

Runtime monitoring here means verifying that the prompt the model is actually operating under matches the authorized version. Injection attempts that prepend rogue instructions or override existing ones deviate from that baseline and are detectable.

Control Point 2: Input Inspection Before Inference

This is where you catch the attack before it reaches the model. Type checking, length limits, and format validation handle malformed requests. The more important layer is semantic inspection: analyzing whether an input carries injection patterns that would pass any structural validator cleanly.

Rate limiting and behavioral anomaly detection matter here too, specifically for extraction attacks. A sudden spike in boundary-probing queries from a single source is a behavioral signal. Not a signature, but a pattern.

Control Point 3: Output Inspection Before Delivery

Post-processing catches what got through. Data leakage, harmful content, and exfiltrated internal information are all stopped here before they reach users or downstream automation.

For agentic systems, this control point extends to tool call validation. The space between the model's decision to invoke a tool and the tool's actual execution is where you block excessive agency attacks. The model wants to call an API — is that call within the authorized scope of the current task? If not, block it before it executes.

Together, these three control points recreate what RASP does for traditional applications. Observe the full execution path. Detect deviation from intended behavior. Block before consequences propagate.

It's also worth considering what happens when only one or two are covered. The threat categories from the previous section map directly onto whichever control point is missing. RAG poisoning bypasses input inspection if retrieval outputs aren't treated as potentially hostile. Excessive agency attacks bypass output inspection if tool call validation isn't in place. The gaps are predictable and specific.

Below the Model, There's Still an Infrastructure Problem

There's a layer of this problem that application-level inspection doesn't reach. LLM inference runs on Kubernetes clusters, shared GPU nodes, and containerized runtimes. Container escape, privilege escalation, and cross-tenant access are runtime threats that exist independently of anything the model does.

Catching them requires kernel-level visibility, and that's where eBPF comes in.

Extended Berkeley Packet Filter is a technology that lets you run instrumentation code inside the Linux kernel without modifying the kernel itself, and without the performance overhead of traditional agents. It has become the substrate for infrastructure-layer runtime security in a wide range of production environments.

A few real deployments illustrate how this is landing in AI-specific contexts:

• Meta's BpfJailer, presented at Linux Plumbers 2025, uses eBPF-based mandatory access control to isolate untrusted AI training and inference workloads. Open-source release was planned for 2026.
• DeepFlow provides zero-instrumentation observability for GPU, RDMA, and LLM serving workloads via eBPF (deployed at Tencent BlueKing).
• OpenTelemetry's eBPF Instrumentation project (the successor to Grafana Beyla) includes GenAI instrumentation covering OpenAI, Anthropic, Gemini, Bedrock, and MCP tracing. That's observability infrastructure, and observability is the foundation that makes detection possible.
• Datadog's GPU Monitoring uses eBPF system-probe for per-pod GPU telemetry, integrated with its LLM Observability product.
• KubeArmor provides open-source runtime enforcement via eBPF and Linux Security Modules, targeting model poisoning and cross-container privilege escalation in Kubernetes and edge deployments.

eBPF is also the substrate driving the Application Detection and Response (ADR) category, which delivers the same host-based blocking outcomes as RASP with easier instrumentation and cloud-native deployment via something as lightweight as a Helm chart annotation.

The picture here has two distinct layers: application-layer inspection at the LLM pipeline, and kernel-layer enforcement at the infrastructure. In a multi-tenant AI deployment, you need both.

What This Looks Like When You Have to Actually Deploy It

Theory is one thing. Running this in production is another. A few operational realities shape what "RASP for AI" actually requires.

Latency is a real constraint. In-line blocking that adds meaningful delay to inference is a genuine production constraint. Instrumentation that can't keep up with inference throughput creates pressure to disable it, and that's a security failure hiding as an engineering tradeoff.

Detection logic needs to be behavioral rather than signature-based. Signatures break on novel prompt variants. Behavioral baselines (what the model normally calls, what it normally returns, how long it normally takes, what query patterns look normal) catch deviation regardless of the specific attack form. For extraction attacks especially, the aggregate shape of boundary-probing behavior is recognizable even when individual queries look completely benign.

Agentic pipelines need tool call validation as a first-class control, not an afterthought. Every function the model can invoke is a potential lateral movement path. Least-privilege scoping of tool permissions is the preventive layer. Runtime monitoring of actual calls is the detective layer. You need both.

Output-side controls matter as much as input-side ones. This is especially true given Gartner's projection about insider threats. Monitoring what leaves the model, as well as what enters it, is required to catch well-intentioned policy violations alongside adversarial attacks.

More than 58% of companies are adopting DevSecOps frameworks. Integrating AI runtime controls into CI/CD and deployment pipelines (rather than bolting them on post-deployment) keeps coverage current as models and prompts change. A security layer that isn't updated when the model is updated is already drifting toward blind spots.

The Market Is Real, But It's Running Faster Than the Tooling

The RASP market is growing rapidly, by any estimate. Different research firms give different numbers, and the variance is wide enough that you should treat specific projections with some skepticism. The scope definitions differ. But every projection agrees on high-double-digit compound annual growth, and the directional signal is consistent.

What matters more than the market size is where the tooling actually stands.

eBPF-based infrastructure monitoring is production-proven at hyperscale. Meta and Tencent are running it, and the technology is mature at that layer.

Application-layer LLM-specific inspection is earlier-stage. Most vendors are adapting existing RASP or WAF architectures rather than building from inference up. That's not inherently bad (good ideas should be reused) but it means coverage of LLM-specific threats (prompt inspection, output filtering, tool call validation) varies significantly across vendors — considerably.

Agentic pipelines are the leading edge of the unsolved problem. Multi-hop indirect injection increased over 70% year-over-year, and the tooling to monitor chains of model-to-tool-to-model calls is still nascent. Most vendors don't have a real answer here yet.

The ADR category is formalizing RASP-for-modern-workloads as a distinct product space, with easier instrumentation, an eBPF substrate, and cloud-native deployment by design. That's the right direction. But LLM-specific coverage within ADR products is still uneven.

What remains hard, and probably will for a while: detecting adversarial intent in semantically valid natural language at inference speed, without a ground-truth label for "malicious prompt" that generalizes across models and domains. Current tools approximate it, but none solve it cleanly.

The architectural argument, though, is settled. In-process, behavior-aware instrumentation is the right model for securing AI workloads. The perimeter can't see what happens at inference, and only something inside the inference process can.

The open question isn't whether to instrument — it's how well, and whether the tooling can keep pace with agentic systems as they get more complex, more autonomous, and more connected to real consequences.