Prompt injection protection

Prompt injection is the most common attack against LLM-backed products. Gateway screens every inbound prompt and outbound completion, surfaces detections in the dashboard, and, when configured to enforce, blocks or redacts the requests that match.

Screening runs on two independent axes, each with its own mode:

The axes are configured separately, so an organization can run direct detection in alert while indirect runs in block, or the reverse.

Modes

PI protection has three modes, set per organization:

How detection works

The direct axis

Two layers run on every inbound prompt.

The enforcement layer is a curated set of lexical patterns for known injection phrasings, each carrying its own confidence. A prompt that matches one of them at or above the axis’s sensitivity triggers the configured input action, and that is the only path to a block on the direct axis.

Alongside it, a fine-tuned DeBERTa v3 classifier hosted as a sidecar scores each prompt from 0.0 (clean) to 1.0 (almost certainly injection). The score is recorded on the request as pi_score and drives the alerts feed and any analysis you run over it, but it does not decide whether a request is rejected. Calibration against a labelled probe set found the two classes not separable at any threshold, so enforcement sits with the lexical layer instead, where a false-positive rate of zero is measurable.

pi_pass_threshold must always be less than or equal to pi_block_threshold. Raising or lowering either one changes what the alerts feed reports, not what gets blocked, so tune the allowlist rather than the thresholds when you are chasing false positives on the direct axis.

The indirect axis

Indirect injection arrives in content the model retrieves rather than in the prompt a user typed, so it is screened separately, on two signals:

Both are bounded 0 to 1 and both are enforced when pi_indirect_mode is block. Per-project overrides for either axis are covered in per-project guardrails.

Actions on detection

Two action settings control what happens when a detection crosses the block threshold:

• pi_input_action: applied when the inbound prompt is flagged. Default: block.
• pi_output_action: applied when the model’s response is flagged. Default: redact.

Each accepts one of five values:

Allowlist patterns

Some legitimate workflows look like injection. For example, security researchers querying a model about jailbreak techniques, or a customer-support tool that summarizes spammy emails. To suppress those false positives, configure an allowlist of regex patterns. A prompt segment that matches at least one pattern is skipped before it is screened.

Limits:

• Up to 50 patterns per org
• Each pattern can be up to 200 characters
• Patterns must compile as valid Python regex (re.compile). Invalid patterns are rejected on save.

Anchor each pattern to something specific to your traffic. A pattern broad enough to match ordinary prose, s or .* for example, is dropped when the allowlist is evaluated rather than applied, so it cannot switch an axis off while the mode still reads block. Gateway tests each entry against the empty string and against a neutral sentence containing every letter and digit, and drops the ones that match either; a genuinely specific phrase survives that test. Dropped entries are recorded on the request’s detection record, so an allowlist that is not doing what you expect is visible rather than silent.

Allowlist matches are also logged so you can audit what’s being suppressed.

Configuring PI protection in the dashboard

Open Security → Prompt injection in the Merge Gateway dashboard and configure:

• Mode for each axis (off / alert / block)
• Direct-axis sensitivity, and the classifier’s block and pass thresholds
• Indirect-axis heuristic and similarity thresholds
• Input and output actions
• Allowlist patterns
• A “safer” vendor for the route action, if used

Only org members with the Manage security rules permission can change PI settings. Every change is written to the audit log.

Security alerts

In alert and block modes, every detection generates a security alert visible under Security → Alerts in the dashboard. Each alert includes:

• Timestamp and request ID
• Mode at the time of the event (alert / block)
• Classifier score and the configured thresholds
• The action that was applied (observe, redact, route, block, escalate)
• The triggering segment of the prompt or completion

Alerts are indexed in the same store as the request log, so you can filter by customer, project, or API key when investigating a spike.

What a blocked request looks like

When PI protection blocks an inbound prompt, Gateway returns HTTP 400 with a stable signal you can match on:

{
  "error": {
    "type": "invalid_request_error",
    "message": "Request blocked: prompt injection detected.",
    "code": "pi_blocked"
  }
}

Output blocks return the same shape with a pi_output_blocked code. The stable detection signal is the code field (pi_blocked or pi_output_blocked), which doesn’t change across releases.

FAQ

Next steps