Are provider-side safety controls enough?

For consumer use cases with tight prompt surfaces, sometimes. For enterprise deployments with retrieval, tool calling, and multi-turn agents, no. The attack surface expands with each of those features, and provider safety training addresses only the payload the provider sees, not the authorization context the deployer owns.

What is the difference between jailbreak and prompt injection?

Jailbreak targets the model's safety training. The attacker persuades the model to produce output the training would refuse. Prompt injection targets the application's use of the model. The attacker persuades the model to follow instructions embedded in untrusted input (retrieved documents, tool outputs, prior turns) instead of the developer's instructions. The two overlap heavily and share defense layers, so production deployments usually treat them together.

Which classifier vendor should we use?

Classifier options change quickly enough to require a release-level evaluation. Evaluate a vendor against the attacks and traffic patterns in your own route inventory, then retain false-positive and false-negative results for each release.

How often should we update the classifiers?

Review input and output classifiers on a defined cadence, and add a test when a new attack pattern is disclosed against a framework in your route inventory. The release record should identify the test corpus, threshold, and policy version.

Does the layered pattern hurt user experience?

Adds tens of milliseconds to the request path when classifiers run in parallel with the model call. The dominant latency is still the model itself. False-positive management (prompts blocked that should have passed) is the primary UX cost, addressed through classifier tuning and an appeal path in the user interface.

What is the failure mode when the classifier is down?

The deployment's availability policy controls the result. A fail-closed route denies requests when the classifier is unavailable. A fail-open route permits an unscored request, and its audit record needs to mark the missing control explicitly.

LLM Jailbreak Defense Patterns: The Layered Controls That Survive Real Production Traffic

An LLM jailbreak is a prompt or sequence of prompts that induces the model to produce output the model's safety training would otherwise refuse. Provider-side safety training reduces the success rate of common jailbreak patterns, but adversarial research demonstrates a steady flow of new patterns that succeed on the current-generation models. In production, treating provider-side safety as the only layer is a design that assumes the attacker never reads the safety research. The layered defense pattern that survives real production traffic runs three controls around the model. Each layer catches attacks the others miss. Each layer produces an audit signal. I want to walk through the pattern, the residual failure modes, and where each layer sits in the request path.

Provider safety catches the majority. The other layers catch the remainder that reaches production traffic anyway.

TL;DR

Production jailbreak defense combines input and output classification with identity-bound authorization on each routed model request. The retained decision record makes a failed classifier visible during investigation.

Layer one: input-side classifiers

The first layer sits between the calling application and the model. It scores incoming prompts against known jailbreak patterns and injection carried by application-specific untrusted content.

The classifier produces a score, and that score feeds a policy decision. A high score blocks the request at the boundary before it reaches the model. A lower review threshold permits the request while recording a flag for investigators. Background-rate scores pass without a flag.

Two classifier families show up in production deployments. Model-based classifiers, smaller models trained for prompt-attack detection, can catch novel patterns at a latency and cost penalty. Rule-based classifiers use pattern matching; they process more traffic but miss more paraphrased attacks. Many teams use the rule-based screen to decide when a model-based review is worth the extra work.

Input classifiers need a test corpus that reflects the application's untrusted content and multi-turn conversations.

Layer two: output-side classifiers

The second layer sits between the model response and the calling application. It scores the model output against classifiers for policy violations that the input side could not predict: leaked system prompt content, leaked training data, unsafe code (SQL injection, XSS payloads, prompt injection intended for downstream systems), regulated data types (PII, PHI, PCI), competitor mentions, brand-off-message content.

The output-side classifier is the defense that catches successful jailbreaks the input side missed. A prompt that scored under the input threshold, either because the pattern was novel or because the attack was distributed across a conversation, still produces an output the output-side classifier can flag. The classifier's response options are the same as the input side: block, transform (redact, rewrite), or pass with flag.

The llm response content filter piece covers the transformation patterns.

Layer three: identity-aware policy at the request boundary

The third layer limits what a successful jailbreak can accomplish. Payload content drives the first two layers. At the request boundary, the policy evaluates the calling identity, selected model, tool set, and data classifications allowed in the response.

The distinction matters when the jailbreak succeeds against the first two layers. A support agent that gets jailbroken into calling a refund tool with an out-of-scope amount still hits the tool-scoping policy the ai agent tool scoping piece covers. A customer service agent jailbroken into revealing another customer's data still hits the data-classification-to-identity policy that denies cross-customer PII in the response.

The layer produces the audit evidence regulators and incident-response teams need. When a jailbreak succeeds and produces impact, the incident review has to reconstruct which identity, which model, which policy version, and which classification. The ai audit logs format spec covers the fields.

The residual failure modes

The layered pattern does not eliminate jailbreak risk. Three residual modes persist after the three layers have executed.

Novel attack patterns. A jailbreak pattern that no classifier has seen scores below both input and output thresholds. The identity-aware policy layer is the only remaining defense, and it catches the pattern only if the impact of the jailbreak crosses an authorization boundary. A jailbreak that produces text (a policy violation but not a boundary crossing) reaches the calling application undetected.

Distributed attacks. A jailbreak can span a conversation, with each message scoring below an individual-message threshold. A session-aware classifier evaluates the sequence and can catch some of these attacks.

Attacks on the classifier itself. Adversarial attacks on the classifier (prompts designed to fool the classifier into producing a low score for a jailbreak) are documented. The counter is classifier ensembles and adversarial training on classifier-specific patterns.

The residual risk is why identity-aware policy at the request boundary is the layer that limits blast radius, not just the detection layer. When the first two layers fail, the third contains the impact.

Regulatory framing

The EU AI Act's Article 15 sets three technical properties high-risk AI systems must achieve: accuracy, resilience, and cybersecurity, appropriate to the system's intended purpose. The AI Office's guidance on Article 15 lists resistance to prompt injection and jailbreaking as a specific resilience property.

The OWASP AISVS 1.0 standard maps prompt-injection input handling, output filtering, and per-request logging to the three layers above.

Layered-defense review

The OWASP Top 10 for LLM Applications treats prompt injection as a distinct application risk. The NIST Generative AI Profile asks organizations to identify, measure, and manage the risks introduced by generative AI. A useful production review traces one representative request through all three layers: the original prompt, the classifier scores and threshold used, the authorization context, the output decision, and the audit record retained for that decision.

That review exposes a failure mode that dashboard-level totals hide. A team can see a low block rate while a privileged support-agent route still permits a successful jailbreak to access data outside its intended scope. The request-level evidence must include the caller identity, model endpoint, policy version, classification result, and final outcome.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits at the AI request boundary as an external enforcement layer that runs all three defense layers on every request. Input-side and output-side classifiers evaluate payload content. Identity-aware policy evaluates the request against the calling identity's authorization scope. The audit record includes the scores from each classifier, the policy decision, and the identity claim.

DeepInspect evaluates routed HTTP AI traffic inline. Classifier and policy changes require versioned release records, so an investigation can identify the exact policy state used for a decision. The policy-as-code piece covers that deployment pattern.

Book a technical deep dive at deepinspect.ai.