Skip to main content

Jailbreak Prevention: How the Gateway Blocks LLM Manipulation Attempts

Jailbreak Prevention: How the Gateway Blocks LLM Manipulation Attempts

A jailbreak is prompt injection with a specific goal: force the model to ignore policy, drop refusals, adopt a new persona, or generate content the application never intended to allow. If your defense begins after the model has already processed the request, you are reacting to the outcome instead of controlling the boundary. Keeptrusts blocks jailbreak attempts at the gateway by treating them as request manipulation, not user creativity.

Use this page when​

  • You need to stop jailbreak prompts before they reach an upstream model.
  • You want to distinguish manipulation attempts from ordinary unsafe content and configure both layers correctly.
  • You need a practical policy chain that blocks override attempts and still contains high-risk prompts that are not classic jailbreak strings.

Primary audience​

  • Primary: Technical Engineers
  • Secondary: Technical Leaders, AI Agents

The problem​

Jailbreaks rarely arrive as a single obvious sentence anymore. Attackers mix several methods together.

One method is persona replacement. The prompt tells the model to become an unrestricted version of itself, a developer-mode assistant, or a role that ignores previous instructions. Another is refusal suppression, where the attacker insists the model must answer directly, never refuse, or continue even if the request is harmful. A third is contextual camouflage, where the attacker wraps the jailbreak inside a story, a quoted passage, a translation request, a prompt-evaluation exercise, or a "for research only" disclaimer.

The goal is not always to produce obviously violent or abusive output. Many jailbreaks aim to lower the model's defenses so later requests can extract secrets, generate phishing copy, or bypass application-specific rules. That is why jailbreak prevention should not be framed as content moderation alone. It is also request-integrity enforcement.

This distinction matters because different controls solve different problems. A keyword safety control may catch some harmful prompts, but it will not reliably detect fake system boundaries, delimiter tricks, or encoded override strings. A DLP rule may catch leaked credentials, but it will not tell you whether the user is trying to rewrite the hidden instructions that govern the session. If you collapse all of these into a single generic filter, you get blind spots.

The solution​

The first line of defense is Prompt Injection Detection. In Keeptrusts, that policy checks regex patterns, decodes Base64-like content, normalizes Unicode, folds homoglyphs, evaluates fake boundaries, and can force embedding-based similarity checks. Those mechanics map directly to how real jailbreaks try to hide or reshape instructions.

The second line is Safety Filter. This is not a replacement for prompt-injection defense. It is the control you use when a request is still clearly unsafe even if it is not a textbook override attempt. For example, a prompt might ask for doxxing, targeting, or credential-harvesting instructions without explicitly trying to reveal the system prompt. Safety-filter gives you a separate decision path for that case.

The third line is DLP Filter, which prevents the same manipulated interaction from exposing secrets, codenames, or internal infrastructure references. Together, these three policies implement the security posture described in Block Prompt Injection Attacks Before They Reach Your Models, Prevent Sensitive Data Leaks in AI Requests, and Implement Zero-Trust AI with Defense-in-Depth Policies.

Implementation​

Use a chain that gives each control a clean job:

pack:
  name: jailbreak-blocking-lane
  version: "1.0.0"
  enabled: true

policies:
  chain:
    - prompt-injection
    - safety-filter
    - dlp-filter

policy:
  prompt-injection:
    use_embedding: true
    detection:
      embedding_threshold: 0.8
      attack_patterns:
        - "ignore.*previous.*instructions"
        - "you are now.*DAN"
        - "developer mode"
    encoding:
      decode_base64: true
      normalize_unicode: true
      detect_homoglyphs: true
    boundaries:
      enforce_delimiters: true
      reject_fake_boundaries: true

  safety-filter:
    mode: law_enforcement
    block_if:
      - "impersonate the help desk"
      - "harvest credentials"
      - "doxx this employee"
    action: block
    fuzzy_matching: true
    max_distance: 1
    max_age: 0

  dlp-filter:
    blocked_terms:
      - payroll export
      - vpn break-glass account
      - internal incident roster
    action: block
    fuzzy_matching: true
    max_distance: 1
    sensitivity_level: high

This ordering is deliberate. prompt-injection blocks the request if the user is trying to rewrite the model's instructions. safety-filter then covers obviously dangerous asks that are not necessarily boundary attacks. dlp-filter protects against follow-on leakage of internal data. If you reverse the order, you make it harder to understand why the request was denied and easier to miss the actual root cause.

For validation, do not settle for a YAML parse and move on. You need both configuration validation and runtime evidence:

kt policy lint --file jailbreak-blocking-lane.yaml
kt gateway run --policy-config jailbreak-blocking-lane.yaml --listen 0.0.0.0:41002
kt events tail --json --limit 20 --event-type decision --verdict blocked

Watch the blocked events for a week of realistic traffic. If legitimate prompts are being denied, narrow the local block_if phrases or the DLP terms that are too broad. If obvious jailbreak attempts still pass, strengthen the prompt-injection pattern set or turn on embedding checks for that lane. The right response is almost never "remove the guardrail." It is "fix the specific condition that is too weak or too noisy."

Results and impact​

The most visible result of gateway-based jailbreak prevention is fewer policy surprises in application logs. Teams stop discovering jailbreaks only after bad output has already been generated or stored. Instead, they see governed block events at the moment of request evaluation.

The more important result is consistency. Product teams often assume every model family or provider exposes the same refusal behavior. They do not. A gateway control gives you one security policy for many models, which is far easier to reason about than trying to tune each provider's native behavior separately.

Jailbreak prevention also becomes testable. Pattern sets, DLP terms, and safety keywords can be validated, reviewed, and versioned. That is a better security posture than hiding all enforcement inside prompt engineering and hoping downstream behavior remains stable.

Key takeaways​

Next steps​