# Detect and block prompt injection

> Detect and block prompt injection in Agent Router, stopping smuggled instructions that make a model ignore its system prompt or leak data.

Enterprise Tier

  Prompt injection is the manipulation of a model's behaviour through instructions smuggled into the text it processes, causing it to ignore its system prompt, leak data, or take actions it should not. It is a distinct threat from the harmful-content categories that guardrails address. A content guardrail asks whether a piece of text is unsafe in itself; prompt-injection detection asks whether a piece of text is trying to subvert the model that reads it. The two concerns overlap rarely and must be handled separately.

The threat arrives by more than one path. A direct jailbreak is an injection in the user's own prompt: the familiar "ignore previous instructions" family of attacks, role-play framings, and encoded instructions intended to escape the system prompt. Indirect injection is more dangerous because it does not require a hostile user. It hides instructions in content the model is given to work with: a passage pulled in by retrieval-augmented generation (RAG), a web page summarised on the user's behalf, or the output of a tool the model called. When a Model Context Protocol (MCP) server returns text and that text is fed back to the model, any instructions buried in it are read with the same authority as the rest of the context. A trusted user, asking an ordinary question, can trigger an attack that was planted in a document or a tool response long before.

Tetrate Agent Router applies injection detection inline in the same filter path as its other guardrails, using check types such as `prompt_injection` and `jailbreak` (often scored by the `tetrate` provider, which can cascade from known patterns to a classifier to NLI). This guide covers turning that detection on for a project, choosing what happens on a detection (block or redact in enforce mode, or monitor mode for a pilot), and wiring the resulting trigger record into an alert.

**Persona:** Platform operator working in the Admin Dashboard, often alongside the security stakeholders who own the threat model.

**Estimated time:** 20 to 40 minutes for an initial configuration, including time spent testing.

## When this guide applies

This guide is the right starting point in any of these situations:

| Situation | What it covers |
| :---- | :---- |
| Defending against direct jailbreak attempts in user prompts | Enabling detection on inbound prompts and the patterns it covers |
| Defending against instructions hidden in retrieved RAG context | Applying detection to retrieved context before it reaches the model |
| Defending against instructions returned by a tool or MCP server | Applying detection to tool and MCP responses when that text re-enters the model path |
| Choosing what should happen when an injection is detected | Comparing block, redact, and monitor mode |
| Alerting when an injection is detected | The trigger record written on a detection and how it reaches an alert |

For the harmful-content side of safety, and for how injection detection composes with it, see [Configure guardrails](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-custom-guardrails) and [Configure guardrail providers](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-vendor-guardrails). Because tool and MCP outputs are a primary injection vector, the way MCP access is governed and aggregated is directly relevant: see [Govern MCP server access](/agent-router-enterprise/guides/operate-and-govern/govern-mcp-server-access) and [Aggregate MCP servers into a profile](/agent-router-service/guides/aggregate-mcp-servers-into-a-profile).

## Outcomes

By the end of this guide:

- Injection detection is enabled and applied to at least inbound prompts and tool or MCP responses on the model path.
- The patterns the detection covers, common jailbreak framings and indirect-injection attempts, are understood, along with its limits.
- The action on a detection (block or redact) and the mode (enforce or monitor) are chosen deliberately for each surface.
- The trigger record written on a detection is understood, including where its content is delivered, and an alert is configured against it.
- The relationship between injection detection, content guardrails, and data-loss prevention (DLP) is clear.

## Prerequisites

- Administrator access to the Admin Dashboard with permission to manage guardrails for the project, typically the `super_admin` role. The read-only `guardrail-reader` role can review detections but cannot configure them.
- At least one provider configured with a healthy connection and at least one model enabled, so detection has live traffic to act on. Provisioning is covered in [Provision models and providers](/agent-router-enterprise/guides/operate-and-govern/provision-models-and-providers).
- For coverage of indirect injection through tools, an understanding of which MCP servers are reachable from Agent Router and which profiles expose them. See [Govern MCP server access](/agent-router-enterprise/guides/operate-and-govern/govern-mcp-server-access) and [Aggregate MCP servers into a profile](/agent-router-service/guides/aggregate-mcp-servers-into-a-profile).
- A few representative injection samples for the testing step: both a direct jailbreak prompt and an indirect attempt embedded in document-like or tool-output-like text.

## Step 1: understand where detection is applied

Injection detection inspects text at the points where untrusted instructions can enter the model's context. Three surfaces matter, and they are not interchangeable.

All three sit on the **input stage**, because all three are text travelling towards the model. What separates them is the kind of content the text arrives as, which the gateway tracks as the evaluation's **content type**.

| Surface | Content type on the evaluation | Threat it addresses |
| :---- | :---- | :---- |
| Inbound prompt | `text` | Direct jailbreaks: instructions the user supplies to escape the system prompt |
| Retrieved context | `context` | Indirect injection planted in documents, knowledge bases, or pages the retrieval step pulls in |
| Tool and MCP response | `tool` | Indirect injection returned by a tool, a primary vector, because tool output is read with the same authority as the rest of the context |

One input-stage rule therefore covers all three surfaces; there is nothing to configure per surface. The content type is not a field on the rule form, it is an attribute of each evaluation, which matters when reading trigger records in Step 6, because that attribute is what says which surface fired. The full list of content-type values is in the [guardrails reference](/reference/guardrails#rule-level-settings).

The inbound prompt is the surface most operators think of first, but it is the least sufficient on its own. A direct jailbreak requires a hostile user; indirect injection does not. The retrieved-context and tool-response surfaces are where a trusted user, asking an ordinary question, can be turned into the delivery mechanism for an attack that was planted elsewhere. Detection that runs only on prompt text leaves the indirect paths open.

Tool and MCP responses warrant particular attention. When Agent Router mediates a model's call to an MCP server, the server's response re-enters the model's context as authoritative text. A compromised or untrusted MCP server, or a legitimate one returning data an attacker controls, can therefore inject instructions without ever touching the user's prompt. Detection on this surface inspects that returning text before the model acts on it, which is to say when the text rides the LLM request path, not when a client calls an MCP profile endpoint (`/mcp/*`) directly. Standalone MCP profile traffic is governed by identity, access control, and audit, not by content guardrails or injection detection. Which MCP servers a given profile may reach is itself a control, covered in [Govern MCP server access](/agent-router-enterprise/guides/operate-and-govern/govern-mcp-server-access).

## Step 2: understand what the detection covers

Injection detection recognises the patterns characteristic of an attempt to subvert the model, rather than the harmful-content categories a guardrail addresses. The patterns fall into two broad families.

- Direct jailbreak framings: instructions that try to override the system prompt or the model's role. Common forms include explicit override phrasing ("ignore previous instructions", "disregard your rules"), role-play and persona framings that ask the model to assume an unrestricted identity, and instructions encoded or obfuscated to slip past naive matching.
- Indirect-injection patterns: imperative instructions appearing where only data is expected. Text retrieved by RAG or returned by a tool is meant to be information for the model to use, not commands for it to follow. Instructions embedded in that text (directing the model to exfiltrate context, call a tool, or change its behaviour) are the signature of an indirect attack.

Two limits are worth stating plainly, because treating detection as absolute leads to misplaced confidence.

- Detection is heuristic and probabilistic. It raises the cost of a successful injection; it does not reduce it to zero. Novel phrasing and adversarial obfuscation will sometimes evade it, and benign text will sometimes resemble an attack.
- Detection is one layer. It is most effective combined with least-privilege tool access, scoped MCP profiles, and the content and DLP controls described in Step 6, so that an injection that evades detection still cannot reach a high-value action or exfiltrate sensitive data.

## Step 3: choose the action and mode on a detection

When an injection is detected, the rule's **action** and **mode** decide what happens. A rule carries one action, applied to every input-stage surface it inspects, so the choice is made once per rule rather than per surface.

| Action / mode | What happens on a detection | When it fits |
| :---- | :---- | :---- |
| Block (enforce) | The request is rejected with HTTP `403`, or the offending content is withheld, and the model does not act on it | The detection is high-confidence, and proceeding is unacceptable: the default for direct jailbreaks on inbound prompts |
| Redact (enforce) | Offending spans are stripped or masked and processing continues with the cleaned content | Indirect injection in a retrieved passage or tool response, where the surrounding data is still wanted but the embedded instruction must not be followed |
| Monitor mode | The content passes unchanged, but the would-be action is recorded | Establishing a baseline rate before enforcing, or observing a low-confidence surface without disrupting traffic |

Block is the safest response where a detection means the interaction itself should not proceed, which is the usual case for a clear jailbreak in a user's prompt. Redact suits the indirect surfaces better: a retrieved document or a tool response often contains legitimate data alongside an injected instruction, and discarding the whole response would break the task, so removing only the instruction preserves the useful content. Because one rule cannot apply block to prompt text and redact to tool output, that tension is resolved either by accepting one action across all surfaces or by splitting the policy across two rules on different check types, for example blocking on `jailbreak` and redacting on `prompt_injection`. Monitor mode is the right starting point in either case; it produces the same trigger record without changing what callers or models experience, which makes it the natural pilot for Step 5. Prefer the `prompt_injection` and `jailbreak` check types on the `tetrate` provider when semantic detection is required; see [Configure guardrail providers](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-vendor-guardrails).

## Step 4: create the rules

There is no separate injection-detection object. Injection detection is a guardrail like any other, distinguished only by its check types, so it is created through the same Guardrails surface. The full creation procedure is in [Configure guardrails](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-custom-guardrails); what follows is the injection-specific reading of it.

1. Sign in to the Admin Dashboard and select the **project** whose traffic the detection should cover.
1. Open **Guardrails → Rules** and choose **Add guardrail**. Name it for its purpose (for example "Prompt injection baseline") so its intent is clear in later review, and set type to Security.
1. Set the guardrail-level failure mode deliberately. Fail-close is the default and the right choice here: if the provider that scores injection checks cannot be reached, an unevaluated prompt should not reach the model by default.
1. Choose **Add rule**, and set the **Provider** first, because it scopes the check types on offer. Semantic detection requires `tetrate`, which cascades from known patterns to a jailbreak classifier to NLI entailment; `regexp` and `builtin` can only match phrasings someone has written down in advance. See [Configure guardrail providers](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-vendor-guardrails).
1. Set the **Check type** to `prompt_injection` for smuggled instructions, or `jailbreak` for the direct "ignore previous instructions" family. Most baselines carry both, since they detect different things.
1. Set **Run on** to **Input**. That one setting covers all three surfaces from Step 1.
1. Set the **Action** and **Mode** as decided in Step 3, which for an initial rollout means monitor on every rule.
1. Save the rule, then add a second rule the same way for the other check type.

Both `prompt_injection` and `jailbreak` are input-stage checks on the ML providers, which matches the threat: injection is something that arrives, not something a model emits. A rule set to run on the output stage will not detect it.

Detection takes effect on subsequent requests in the project. Requests already in flight complete under the configuration active when they were admitted; there is no service restart.

Because indirect injection can arrive through any RAG source or any reachable MCP server, a project-wide baseline is the safest default. Pairing that baseline with tight MCP access limits both the chance of an injection and the damage a successful one could do.

## Step 5: validate with sample injections in monitor mode

Detection that has never been exercised against a real injection is an assumption, not a defence. Validation is monitor mode against representative traffic, and the procedure is in [Configure guardrails](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-custom-guardrails#step-6-validate-in-monitor-mode-before-enforcing). Three samples are specific to injection:

- **A direct jailbreak** in prompt text, for example an instruction to ignore previous instructions. This exercises the `jailbreak` rule against content type `text`.
- **An indirect injection**, shaped like a retrieved passage or a tool response with an embedded instruction directing the model to act. Submit it through the path that actually produces that content, rather than pasting it into a prompt, so the evaluation is recorded against `context` or `tool` and the indirect surface is genuinely exercised.
- **Benign content that resembles an attack**, such as a document legitimately discussing prompt injection. This is the sample that catches an over-eager rule, and injection detection is unusually prone to it: security documentation, incident write-ups, and this guide itself all contain text that looks like the thing being detected.

Resolving false detections and missed detections at this stage is far cheaper than discovering them once the rules are acting on real requests. Monitor mode produces the same trigger records that drive alerting in Step 6.

## Step 6: alert on the trigger record

Every detection writes a **guardrail-trigger** record, whether the mode is enforce or monitor and whether the action is block or redact. That record is what makes injection detection observable and alertable rather than merely active. A monitor-mode rule no one is watching provides no protection.

- One record is written per rule evaluation, carrying the rule and guardrail identifiers, the score, the action and mode, the stage, and the content type. The content type is what identifies the surface: a record with content type `tool` is an indirect attack arriving through a backend rather than a user, which is the case that warrants the promptest alert.
- **The record can carry the offending text, and the data plane's own copy always does.** Where that content goes is controlled in two independent places: **Settings → Guardrails** governs what reaches the management plane (Full, Metadata only, or Off), while a `guardrailtrigger` subscription on a custom observability backend receives full content regardless of that setting. Both are documented in [Custom observability backends](/agent-router-enterprise/guides/observability-and-analytics/configure-custom-observability-backends#guardrail-trigger-destinations). For injection detection this is usually welcome, because the payload is the evidence, but it should be a decision rather than a surprise.
- Trigger records are a different record type from Audit Logs, which capture administrative mutations such as a change *to* this guardrail rather than the guardrail firing. To investigate one specific block, start from the correlation identifier returned with the `403`; that workflow is in [Guardrails best practices and FAQ](/reference/best-practices/guardrails-best-practices-and-faq). The read-only `guardrail-reader` role exists so a security team can review triggers without being able to change them.
- For alerting, subscribe a backend the security team already watches to the `guardrailtrigger` signal and raise an alert on rate or pattern. The general telemetry path is described in [Export telemetry to an observability stack](/agent-router-enterprise/guides/observability-and-analytics/export-telemetry-to-an-observability-stack).

A detection that fires into a record no one watches is indistinguishable from no detection at all. An alert closes that gap.

## Step 7: compose detection with content guardrails and DLP

Injection detection is one control among several, and it is most effective as part of a layered safety posture rather than on its own. Each layer addresses a concern the others cannot.

- Injection detection asks whether incoming text, from a user, a retrieved source, or a tool, is trying to subvert the model. It is the subject of this guide.
- Content guardrails ask whether text is unsafe or disallowed in itself: toxicity, hate speech, banned topics, and similar check types, scored by `regexp`, `builtin`, or `tetrate`. See [Configure guardrail providers](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-vendor-guardrails) and [Configure guardrails](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-custom-guardrails).
- Data-loss prevention asks whether sensitive data is leaving the boundary. PII or secrets detection with a redact or block action is Agent Router's DLP mechanism and limits what a successful injection could exfiltrate even if the injection itself evades detection.

These layers operate in the same inline filter path, and all must permit a request for it to proceed. They are complementary by design: injection detection stops the model being subverted, content guardrails stop unsafe content passing in either direction, and DLP stops sensitive data leaving. Deciding which layer owns a given concern, rather than duplicating intent across all three, keeps the overall policy coherent and auditable. Tightening MCP access so that a subverted model can reach only the tools it genuinely needs, covered in [Govern MCP server access](/agent-router-enterprise/guides/operate-and-govern/govern-mcp-server-access), reduces the blast radius further still.

## What to do next

- **Configure guardrails**: add PII redaction and other rules alongside injection detection, including the DLP controls referenced here. See [Configure guardrails](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-custom-guardrails).
- **Configure guardrail providers**: choose `regexp`, `builtin`, or `tetrate` for each check type. See [Configure guardrail providers](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-vendor-guardrails).
- **Govern MCP server access**: limit which MCP servers a profile can reach, reducing the indirect-injection surface and the blast radius of a successful attack. See [Govern MCP server access](/agent-router-enterprise/guides/operate-and-govern/govern-mcp-server-access).
- **Custom observability backends**: deliver the trigger records written here to the stack the security team watches, and decide where their content goes. See [Custom observability backends](/agent-router-enterprise/guides/observability-and-analytics/configure-custom-observability-backends#guardrail-trigger-destinations).
- **Protect requests with guardrails**: the developer-side view of how safety controls appear in application code. See [Protect requests with guardrails](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/protect-requests-with-guardrails).

Where to go next

  <Link to="/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/detect-and-redact-sensitive-data" className="tare-nav-card">
    Detect and redact sensitive data
    Add the DLP controls that limit what a successful injection could exfiltrate.
  </Link>
  <Link to="/agent-router-enterprise/guides/operate-and-govern/govern-mcp-server-access" className="tare-nav-card">
    Govern MCP server access
    Limit which MCP servers a profile can reach, reducing the indirect-injection surface.
  </Link>