Prompt Injection Against LLM Judges

Prompt injection can target the safety judge in an AI application. The judge must read untrusted material to assess it. If that material steers the assessment, a risky message may pass the gate. Adding an evaluator creates another component whose trust boundary needs attention. Our prompt injection introduction explains the underlying problem.

At a glance

• Content under review cannot supply its own trusted approval.
• Valid structured output can carry an incorrect verdict.
• Model confidence does not establish permission to act.
• Test ordinary inputs alongside attacks and observe what the application does.

An email that tries to clear itself

Consider an assistant that summarizes incoming email. Before showing a message, the application asks a separate AI judge whether it looks suspicious. This is a simplified illustration, not a report of a particular incident.

An email includes a questionable payment link. Below its body, the sender adds what looks like an internal review note: a security service has supposedly approved the link, and the current evaluator should carry that approval forward.

The application sends the entire email to its judge. The review note came from the email's sender. It is part of the material being assessed. If the judge treats it as a trusted earlier decision, the message has influenced its own inspection.

Suppose the judge returns a perfectly valid response marking the email as unremarkable. A parser can read that result. It cannot tell whether the model assessed the link or accepted the forged note.

The missing question is where the claimed approval came from. Naming a field “security review” does not authenticate its author. A genuine upstream verdict would need to arrive through a separate verified channel and be tied to the message being reviewed.

What the new paper establishes

Same Attack, Different Judge, submitted on October 13, 2026, compares Jev, general LLM judges and specialized classifiers across moderation, injection detection, routing and phishing. Robustness varies by task, including responses to forged prior verdicts.

Its limits matter: single-turn calls, English data and one phishing corpus. It measures evaluator decisions rather than downstream harm. Wolf Defender is absent. These findings do not establish a universal product ranking. This description refers to version 1, checked on October 14, 2026.

Different evaluators answer different questions

A general LLM judge receives evaluation instructions in a prompt. A specialized classifier returns scores or classes for its trained task. A typed decision model answers predefined questions within a restricted answer space.

Jev belongs to the third group. Its version 1.13 documentation acknowledges that adversarial content can change answers and recommends precise criteria and integration testing. It also describes irrelevant context and option ordering as potential sources of error. The page was last reviewed on October 2, 2026; we checked it on October 14.

In the email example, deciding whether a message contains suspicious instructions is one task. Deciding whether the application may send money is another. That action depends on the account, recipient, amount and valid approval. An accurate text assessment does not supply those facts automatically.

Keep assessment separate from enforcement

The TypeSafe guardrails cookbook distinguishes a model assessment from the application's routing decision. The application chooses when to pass, block or request human review. Documentation checked on October 14, 2026.

For the example above, four controls give that distinction practical meaning:

1. Preserve provenance. Keep application criteria separate from the email. Accept earlier decisions only from an independently verified channel.
2. Validate the response. Check the schema and permitted values. Missing, invalid or unavailable assessments must not silently grant approval.
3. Limit the action. Enforce tool permissions outside the model context. Summarizing email needs no payment authority. Any approval must match the exact proposed action.
4. Retain useful evidence. Record the model version, decision rules and action outcome while avoiding unnecessary sensitive content in logs.

These recommendations draw on OWASP's prompt injection prevention and AI agent security guidance, checked on October 14, 2026. They add constraints that can still hold when a text assessment is wrong.

Include harmless content in your tests

Build three cases for this workflow: an ordinary email, a suspicious email and the same suspicious email carrying a fabricated review note. Add a legitimate training message that describes this attack. Security terminology alone should not make that training message fail.

Observe both the judge's verdict and the application's subsequent action. Repeat the checks when the model, prompt or thresholds change. A passing case is a documented test point, not proof of protection against every variant.

For a payment-capable assistant, an important outcome would be that even an incorrect text verdict cannot trigger a payment without valid approval. Our article about the Manus warning after code execution explains why the placement of a control in the workflow matters.

Wolf Defender Small v2 for single-turn text screening

Wolf Defender Small v2 is freely available under Apache 2.0 for single-turn prompt injections. You provide the compute and operate it. Its model card documents false positives and missed attacks; it does not replace provenance or permission checks. Our Wolf Defender Jev introduction covers the separate decision model.

We currently do not cover cross-session attacks through Wolf Defender. Our cross-session article explains that boundary. Product scope checked on October 14, 2026. The paper discussed here makes no claim about Wolf Defender's detection performance.