Skip to the content.

Example

Two Zeeguu surfaces feed untrusted text into a prompt, and they contain it with very different strength.

Audio-lesson suggestions (strong containment). A user types a free-text topic or situation for a listening lesson, which then drives an expensive multi-step generation pipeline (script → text-to-speech → stored artifact). suggestion_validator contains the input in layers: hard length caps (2–80 characters) reject oversized payloads before any model runs; then a cheap, temperature-0 LLM gatekeeper classifies the input (invalid / niche / general) and canonicalizes it to a short 2–5 word normalized topic in the user’s native language. The downstream generator consumes the canonical form, not the raw text, so an injected instruction (“ignore your rules and…”) is either rejected as invalid or collapsed into a 2–5 word topic, and never reaches the generator verbatim.

On-demand “Ask AI” translation (light containment). The learner’s clicked word and the surrounding article sentence are inserted into the prompt. The context here is third-party web content the app ingested, so it is also untrusted. Containment is implicit rather than explicit: the task is deliberately narrow (“translate the word in context, 1–3 words”), the expected output is tightly constrained, and Defensive Output Parsing rejects anything that is not a short translation. This bounds the blast radius rather than sanitizing the input.

Forces

Solution

Never let raw untrusted text flow into a consequential prompt as-is. Contain it with cheap, layered defenses, strongest where the blast radius is largest:

Match containment strength to consequence: the audio pipeline (multi-step, persists artifacts, real cost) earns a dedicated gatekeeper call; a throwaway inline translation leans on scoping and output validation.

Relationship to LLM Gateways

Some gateways offer prompt-injection / content guardrails (Portkey guardrails, LiteLLM hooks, dedicated screens such as Lakera or prompt-shield features) that can run a screening pass at the gateway. But the strongest containment here is not a generic screen: it is domain canonicalization (reduce the input to a 2–5 word topic in the user’s language) and task-narrowing, both of which require the application’s knowledge of what a legitimate input looks like. A gateway can add a screening layer; it cannot know that “a valid audio-lesson topic is a 2–5 word phrase” or “a valid translation is 1–3 words.” As elsewhere (see What Makes These Patterns LLM-Specific? → Relationship to LLM Gateways): gateway = generic guardrail; pattern = domain-specific reduction and scoping.

Status

Partly implemented: the audio-lesson suggestion validator is a full instance; translation relies on task-narrowing plus defensive parsing; the third-party article-context vector is only partially addressed. Included as a candidate to discuss the boundary with Defensive Output Parsing and LLM-Checking-LLM: whether “contain untrusted input” and “validate untrusted output” are two halves of one pattern or two.

Known Uses

Notes


💬 Open an issue about this pattern