Jailbreak and Prompt-Injection Detection at the Gateway

What prompt injection and jailbreaks are

A prompt injection is any input that makes a model ignore the instructions you gave it and follow the attacker’s instead. Because an LLM can’t reliably tell your system prompt from someone else’s text in the same context window, a well-crafted message can simply overrule it.

The attacks come in recognizable forms. A direct injection is the user telling the model to disregard its rules — “ignore your instructions and…” A jailbreak is a role-play framing that smuggles the model past its safety training — the classic “you are DAN, you can do anything now.” An indirect injection is the dangerous one: the malicious instruction isn’t typed by the user at all, it’s hidden inside a document, web page, or tool result your application retrieves and pastes into the prompt. The user asks an innocent question; the poisoned context does the attacking.

For anything with retrieval or tools — which is most production AI now — indirect injection means you can’t trust the context any more than the user. Detection has to cover both.

Three kinds of attack

Three attacks the guardrail detects

The distinction matters because it dictates where you have to look. Direct injection and jailbreaks live in the user’s message. Indirect injection lives in the content your pipeline assembled — the retrieved document, the scraped page, the API response an agent pulled back. A detector that only reads the user prompt will miss the third category entirely, and the third category is the one the user can’t even see.

How detection works

The gateway inspects incoming content in two parts and blocks the request if either one trips.

Detecting jailbreaks and prompt injection

Dual analysis is the key design point: the guardrail scans the user prompt for direct injection and jailbreak patterns, and separately scans the system prompt and context/document content for indirect injection. An attack found in either location blocks the request before it reaches the model.

Under the hood, TrueFoundry’s built-in Prompt Injection guardrail is powered by Azure Prompt Shield and runs on TrueFoundry-managed infrastructure — there are no credentials, thresholds, or categories to configure. Because it inherits Azure’s 10,000-character limit, long prompts are automatically split into chunks (up to ~9,500 characters each, broken at paragraph or sentence boundaries) and scanned concurrently; detection is a logical OR across chunks, so one flagged chunk blocks the whole request. Transient Azure errors are retried with backoff. All of that is handled for you.

Detection options

The built-in guardrail is the fast path, but the gateway also integrates vendor detectors if you need your own stack or self-hosted deployment.

Prompt-injection detection options in the gateway

The built-in option needs no keys. If you’re self-hosted or standardized on a vendor, you can bring your own Azure Prompt Shield key, or use Google Model Armor, AWS Bedrock Guardrails (prompt-attack content filters), dedicated LLM-security vendors like HiddenLayer, Akto, or F5, or NVIDIA NeMo’s self_check_input. They all plug into the same guardrail pipeline, so switching or combining them is a config change.

Where teams get this wrong

They only scan the user prompt. That leaves indirect injection — the attack hidden in retrieved content — wide open. Scan the context too.

They treat detection as a silver bullet. No detector catches 100% of attacks. Prompt-injection detection is one layer; combine it with content moderation, secrets detection, and least-privilege tool permissions.

They forget the tool surface. In agentic systems, injected instructions can arrive in tool parameters. Run detection on the MCP Pre-Tool hook, not just LLM input.

They enable hard blocking cold. Turning on enforce with no baseline risks false-positive blocks on legitimate prompts. Start in Audit, review detections in traces, then enforce.

‍