A chatbot rarely fails in one clean dramatic explosion. More often, it is nudged.

First, the user asks for a harmless explanation. Then a role-play frame. Then a historical analogy. Then a translation. Then a “purely fictional” operational detail. By the time the final request arrives, the model has already been walked across the room. The last prompt is not the attack. It is the receipt.

That is the uncomfortable starting point of DeepContext: Stateful Real-Time Detection of Multi-Turn Adversarial Intent Drift in LLMs.1 The paper argues that many current guardrails are solving the wrong temporal problem. They classify prompts. Attackers shape conversations.

This distinction matters because the enterprise AI stack is no longer just a polite chatbot sitting in a corner, answering refund questions with corporate cheerfulness. Models now call tools, search internal knowledge bases, write code, trigger workflows, and mediate customer or employee requests across long sessions. In that environment, safety is not only about blocking a bad sentence. It is about noticing when a sequence of ordinary-looking turns starts bending toward an unsafe objective.

DeepContext’s core claim is simple enough to be dangerous: for multi-turn attacks, a smaller stateful guardrail can beat a larger stateless one. Not because small models have discovered enlightenment. Because remembering the right thing is often more useful than rereading everything badly.

The useful comparison is not small versus big, but stateless versus stateful

The obvious summary of this paper would be: “DeepContext is a new guardrail model and it performs well.” That is technically true and editorially unhelpful.

The better comparison is between three ways enterprises might defend an LLM application:

Guardrail pattern How it sees the conversation Strength Failure mode
Lightweight stateless classifier Current prompt, or a small local window Very fast and cheap Misses intent distributed across turns
Large LLM judge Full transcript or sliding context Better semantic judgment Slow, costly, and vulnerable to signal dilution
Stateful intent tracker Current turn plus a learned recurrent state Tracks accumulated risk at low latency Needs careful training, evaluation, and threshold design

DeepContext belongs to the third category. It does not try to solve multi-turn safety by repeatedly feeding a growing transcript into a large judge model. Instead, it turns each conversational turn into a safety-oriented embedding, passes those embeddings through a recurrent model, and maintains a hidden state that evolves as the dialogue evolves.

That is the important architectural move. A stateless guardrail asks, “Is this prompt bad?” A stateful guardrail asks, “What has this user been moving toward?”

Those are not the same question. In a single-turn jailbreak, they may collapse into one another. In a slow-burn attack such as Crescendo-style grooming, they diverge sharply. The individual turns may be ambiguous or even benign. The trajectory is the signal.

DeepContext treats safety as a trajectory through intent space

The paper’s mechanism can be reduced to three stages without losing the main idea.

First, each user turn is encoded with a fine-tuned BERT-style encoder and task-attention weighting. The purpose is not to create a generic semantic embedding of the text. It is to emphasize tokens and patterns relevant to safety categories such as jailbreaks and prompt injection.

Second, these turn-level embeddings are fed into a GRU-based recurrent intent tracker. The GRU maintains a hidden state across turns:

$$ h_t = \mathrm{GRU}(x_t, h_{t-1}) $$

Here, $x_t$ is the current turn’s safety-oriented embedding, and $h_t$ is the accumulated latent state. The paper frames this state as a representation of adversarial accumulation: not a raw transcript summary, but a compressed memory of the conversation’s safety-relevant direction.

Third, DeepContext uses a residual shortcut so that the classifier sees both the recurrent state and the immediate turn signal. In simplified terms, the final risk vector combines:

$$ \text{risk}_t = [x_t ; P(h_t)] $$

That shortcut is not a decorative engineering flourish. It prevents the recurrent state from smoothing away obvious single-turn attacks. A guardrail that is excellent at detecting slow intent drift but blind to a direct harmful request would be a very elegant way to get fired.

So the architecture is not “stateful instead of stateless.” It is stateful plus immediate signal. The paper’s main contribution is the combination: task-attention embeddings for each turn, recurrent tracking for accumulated intent, and a residual path for sudden violations.

The benchmark is designed to test memory, not just politeness

The evaluation dataset contains 1,010 conversations: 210 multi-turn jailbreak conversations and 800 benign conversations. The jailbreak conversations have a median length of seven turns and a maximum of 49 turns. The benign conversations have a median length of four turns and a maximum of 18 turns.

That composition matters. A benchmark dominated by obvious one-shot attacks would mostly test whether a model can recognize forbidden content after the attacker has helpfully made it obvious. This benchmark is instead built to stress the “slow drift” problem: benign-looking setup, distributed intent, delayed violation.

The paper evaluates DeepContext against several classes of baselines:

Test group Examples in the paper What the comparison is meant to show
Lightweight specialized encoders Llama-Prompt-Guard-2-86M, DeBERTa-v3 Prompt Injection Whether small stateless models can catch drift through local pattern recognition
Generative guard models Llama-Guard-4-12B, Granite-Guardian-3.3-8B, Qwen3Guard-Gen-8B, GPT5-Nano Whether larger semantic judges can infer multi-turn adversarial intent
Managed enterprise services Azure Prompt Shield, AWS Prompt Attack Guardrails, GCP Model Armor How the method compares with practical black-box tools used in production

This is a useful comparison set because enterprise buyers rarely choose between “paper model A” and “paper model B.” They choose between cheap local filters, large model-based judging, and managed APIs. In other words, they choose an operating model.

The benchmark does have a boundary: some source families used in evaluation also appear in the broader training corpus, although the authors state that the specific evaluation samples were not seen during training. That does not invalidate the results, but it does mean the paper should be read as strong internal evidence, not final independent proof.

A shocking distinction, I know. Vendor-adjacent security benchmarks sometimes require a little adult supervision.

The main result: DeepContext wins by catching more attacks earlier

On the multi-turn benchmark, DeepContext reports the strongest overall result: F1 score 0.84, recall 0.83, precision 0.86, and mean turns to detection of 4.24.

Model F1 Recall Precision Mean turns to detection
DeepContext 0.84 0.83 0.86 4.24
Llama-Prompt-Guard-2-86M 0.67 0.60 0.76 5.83
Granite-Guardian-3.3-8B 0.67 0.57 0.83 5.03
GPT5-Nano 0.65 0.55 0.81 5.73
DeBERTa-v3 Prompt Injection 0.62 0.61 0.62 5.27
GCP Model Armor 0.58 0.54 0.63 4.56
Qwen3Guard-Gen-8B 0.51 0.36 0.84 3.12
Llama-Guard-4-12B 0.51 0.42 0.65 6.09
AWS Prompt Attack Guardrails 0.38 0.40 0.36 5.61
Azure Prompt Shield 0.19 0.11 0.62 8.00

The headline is not merely that DeepContext has the highest F1. The more revealing point is the recall/latency relationship.

High precision is nice. It tells you the model is not constantly screaming “jailbreak” at ordinary users who asked about API documentation. But in multi-turn adversarial settings, recall is the painful metric. Low recall means the guardrail misses the attack. The user experience remains smooth, right up to the moment the system does something regrettable.

Qwen3Guard is a good example of why mean turns to detection needs interpretation. It reports the lowest mean turns to detection at 3.12, which sounds excellent until you notice its recall is only 0.36. A detector can look fast if it only catches the most obvious cases. That is not early warning. That is selective eyesight.

DeepContext’s result is more interesting because it combines high recall with reasonably early detection. It does not merely wait for the final harmful payload. The recurrent state is supposed to pick up the accumulated direction of the conversation before the violation becomes explicit.

This is the practical difference between a smoke alarm and a historian. Enterprises generally prefer the former.

Bigger context windows are not automatic memory

The most useful misconception addressed by the paper is the belief that long context solves multi-turn safety.

The intuitive argument sounds reasonable: if the guard model can read the whole transcript, surely it can understand the attack. More tokens, more context, more safety. This is the kind of reasoning that makes procurement committees feel temporarily intelligent.

The paper’s results complicate that story. For several LLM-based guardrails, full-context evaluation performs the same as or worse than a sliding window over the last five turns.

Model Full context F1 Sliding window F1
Granite-Guardian-3.3-8B 0.65 0.67
GPT5-Nano 0.58 0.65
Qwen3Guard-Gen-8B 0.51 0.51
Llama-Guard-4-12B 0.42 0.51

This table is small, but it carries much of the paper’s business relevance.

A longer transcript is not the same as a better state representation. In long-context review, adversarial signals may be diluted by benign preamble, side discussion, assistant responses, and irrelevant turns. The model sees more text, but not necessarily more structure. It receives a transcript, not a trajectory.

Sliding windows reduce noise, but introduce another obvious weakness: an attacker can spread the setup beyond the window. If the window is short, the model loses the early grooming. If the window is long, the signal is diluted. Pick your favorite compromise and pretend it is a strategy.

DeepContext’s answer is to maintain a fixed-size hidden state that updates each turn. That is the architectural reason the paper frames safety as state estimation rather than transcript classification. The guardrail does not need to reread the whole conversation. It needs to carry forward the parts of the conversation that matter.

For enterprise systems, this changes the design question. Instead of asking, “How large should the safety model be?” the better question is, “What memory should the safety layer maintain between turns?”

The single-turn test checks that statefulness did not create tunnel vision

The paper also evaluates DeepContext on JailBreakBench, a single-turn jailbreak benchmark. This test is not the main thesis. It is closer to an implementation validation: if the architecture is built around recurrent tracking, does it still catch ordinary one-shot attacks?

The answer reported by the paper is yes. DeepContext reaches F1 0.98, recall 1.00, and precision 0.95 on the single-turn benchmark.

Model F1 Recall Precision
DeepContext 0.98 1.00 0.95
Qwen3Guard-Gen-8B 0.88 0.95 0.83
Llama-Guard-4-12B 0.86 0.86 0.86
GPT5-Nano 0.83 0.91 0.76
GCP Model Armor 0.83 0.96 0.74
Granite-Guardian-3.3-8B 0.78 1.00 0.65

This matters because stateful systems can fail in a particular way: they may become so focused on accumulated context that they underweight the current input. DeepContext’s residual connection is designed to avoid that. The classifier receives both the current turn embedding and the projected recurrent state, so a direct jailbreak does not have to wait for a multi-turn trajectory to become visible.

For business readers, the interpretation is straightforward. A stateful guardrail should not replace immediate prompt screening. It should absorb it. If the architecture forces a choice between catching direct attacks and catching slow attacks, the architecture is probably undercooked.

Latency is where the architecture becomes a product argument

Security systems live under a cruel constraint: the better they inspect, the more they can slow down the product. A guardrail that adds too much latency becomes a beautiful compliance diagram and a terrible user experience.

DeepContext reports an average per-turn latency of 19 ms. That is slower than the smallest stateless encoders at 4 ms, but substantially faster than the LLM-based and managed guardrail baselines in the paper’s comparison.

Model or service Average latency per turn
Llama-Prompt-Guard-2-86M 4 ms
DeBERTa-v3 Prompt Injection 4 ms
DeepContext 19 ms
Llama-Guard-4-12B 43 ms
Qwen3Guard-Gen-8B 64 ms
Azure Prompt Shield 77 ms
GCP Model Armor 81 ms
Granite-Guardian-3.3-8B 125 ms
AWS Prompt Attack Guardrails 235 ms
GPT5-Nano 317 ms

The paper also states that DeepContext requires about 2 GB of VRAM and can run on a T4-class GPU at the same 19 ms latency, while a CPU-only Colab run reached 474 ms. Those numbers should not be treated as a universal deployment guarantee, because infrastructure, batching, networking, implementation quality, and traffic patterns will matter. But they are enough to make the architecture commercially interesting.

The key trade-off is not “DeepContext is the fastest.” It is not. The tiny stateless encoders are faster.

The key trade-off is that DeepContext offers much higher multi-turn recall while staying close enough to real-time that it can plausibly sit inside a production interaction loop. That is why the paper’s strongest product claim is not raw safety. It is safety at a latency budget that does not turn every chat session into a government queue.

The business value is adaptive risk control, not just better blocking

The obvious deployment pattern is to use DeepContext as another binary gate: safe or unsafe, allow or block. That would be useful, but slightly unimaginative.

The more interesting business use comes from the continuous risk signal. If the system can estimate that a conversation is drifting toward adversarial intent, the application does not need to jump immediately from normal operation to hard refusal. It can introduce graduated controls.

Rising risk signal Possible operational response Business meaning
Mild suspicious drift Increase logging, lower confidence in user intent, ask clarifying questions Low-friction monitoring
Moderate drift Restrict tool access, disable sensitive actions, narrow RAG retrieval scope Prevent privilege escalation
High drift Trigger human review, conservative decoding, or refusal Stop likely abuse before execution
Repeated drift across sessions Flag account-level probing patterns Detect systematic red-team or abuse campaigns

This is especially relevant for three enterprise settings.

First, customer-service and technical-support bots. These systems often need to handle long conversations with frustrated users, ambiguous requests, code snippets, screenshots, and operational details. A stateless filter can easily confuse technical complexity with malicious intent, or miss a slow setup because each turn looks harmless. A stateful monitor could help distinguish escalating risk from ordinary troubleshooting.

Second, RAG systems. Many enterprise assistants retrieve from internal documents, policy manuals, customer records, or engineering knowledge bases. The risk is not only that a user asks a prohibited question directly. The risk is that the user gradually steers the assistant toward retrieving, summarizing, or transforming sensitive information under a benign frame. A recurrent safety state could become a control input for retrieval permissions.

Third, tool-using agents. Once the model can send emails, execute code, create tickets, update databases, or call APIs, the safety problem becomes procedural. The system needs to know whether the current action is still aligned with the user’s legitimate objective. DeepContext does not fully solve agentic alignment, but its stateful framing points in the right direction: track trajectory, not just utterance.

The Cognaptus inference is therefore practical but bounded: stateful safety layers should become part of the orchestration fabric around enterprise agents. They should not be treated as magic shields. Magic shields have a long and distinguished history of failing immediately after the sales demo.

What the evidence supports, and what it does not

The paper’s results support a clear claim: in the reported benchmark, recurrent intent tracking substantially improves multi-turn jailbreak detection compared with the tested stateless guardrails, while keeping per-turn latency low enough for real-time use.

They do not prove that DeepContext is universally superior across all enterprise environments. Several boundaries matter.

First, the integrated training corpus is partly proprietary. The paper lists major open and academic subsets, but the complete dataset cannot be independently inspected. That limits reproducibility.

Second, the evaluation benchmark is meaningful but modest: 1,010 conversations, with 210 multi-turn jailbreaks. That is enough to show a strong signal. It is not enough to close the subject.

Third, some dataset families appear in both training and evaluation sources, even though the authors state that the exact evaluation samples were not seen during training. This is common in applied ML evaluation, but it still narrows how confidently we should generalize.

Fourth, managed enterprise APIs are black boxes, and their latency includes network effects. That is fair from a buyer’s perspective because API latency is real latency, but it makes architectural comparison messier.

Fifth, the paper notes false positives in complex function-calling scenarios. This is important. Enterprise workflows often contain exactly the kind of dense, technical, instruction-heavy content that can resemble prompt injection or malicious code manipulation. A guardrail that overreacts in those workflows may protect the system by quietly damaging the product.

Finally, the benchmark measures detection, not the full governance loop. In production, detection must connect to policy, escalation, logging, user experience, compliance, and human review. A risk score without a response design is just a dashboard having feelings.

The real lesson: memory is now part of the safety layer

DeepContext is best read less as “one more guardrail model” and more as evidence for a design shift.

Early LLM safety could often be framed as prompt inspection. A user sends a request; the system classifies the request; the model answers or refuses. That world is fading. Multi-turn attacks exploit continuity. Agentic systems create longer action chains. RAG applications expose more sensitive context. The safety layer has to become temporal because the product has become temporal.

The paper’s strongest insight is not that GRUs are newly fashionable. They are not. The stronger insight is that a compact recurrent state may represent conversation risk better than a large model repeatedly judging a transcript. Bigger context is not the same as better memory. More parameters are not the same as temporal awareness.

For business leaders, this suggests a useful procurement question: does your AI safety stack remember risk, or does it merely reread text?

For builders, it suggests an architectural pattern: separate immediate content screening from stateful trajectory monitoring, then connect the resulting risk signal to adaptive controls.

For everyone else, it is a reminder that the next generation of AI guardrails may look less like judges and more like air-traffic control. They will not only inspect what is happening now. They will track where the conversation is heading.

That is less glamorous than “a bigger model will fix it.” It is also more likely to be true.

Cognaptus: Automate the Present, Incubate the Future.

/2602.16935.


  1. Justin Albrethsen, Yash Datta, Kunal Kumar, and Sharath Rajasekar, “DeepContext: Stateful Real-Time Detection of Multi-Turn Adversarial Intent Drift in LLMs,” arXiv:2602.16935, 2026, https://arxiv.org/abs ↩︎