Prompt injection, jailbreaks, and defense in depth
Lesson 3 of 3 in Guarding Inputs and Outputs.
Two attack classes, one lesson in humility. Prompt injection smuggles instructions into text the model reads — directly in the user turn ("ignore all previous instructions…") or indirectly inside content the app fetches: a PDF in the knowledge base, a web page, an email an agent opens. Jailbreaks attack the model itself — role-play, hypotheticals, encodings that talk it out of its own safety behavior. Bedrock's first-line answer is the prompt-attack filter, an input-side content-filter category tuned for both classes, reporting confidence against your configured strength.
The professional posture is assuming it will sometimes miss. Injections are usually polite — a toxicity screen scores them clean, and a pattern filter trained yesterday meets a technique invented today. So the defence is a stack, not a filter: Defense in depth — Comprehend pre-processing filters, model-based guardrails at the invocation, Lambda post-processing validation, and API Gateway response filtering, with Step Functions orchestrating custom moderation workflows (confidence thresholds, human-review branches) where the built-ins end. Watch one prompt walk that gauntlet.
Two refinements separate a professional setup from a default one. First, scope what the guardrail reads: a RAG turn re-sends system instructions, history, and retrieved passages every time, and any of it can false-trigger input policies — input tags confine evaluation to the new user turn. The mirror problem is indirect injection, where the attack hides in the retrieved content itself; there, run ApplyGuardrail over retrieved documents before they enter the context window. Same API, opposite trust boundary.
Second, test like an attacker. Adversarial testing is a regression discipline: a corpus of known injections and jailbreaks (public collections, red-team finds, production escapes), replayed by automation on every change — and because input-side suites run through ApplyGuardrail, they cost guardrail evaluation, not model inference. AWS updates the filter models underneath you automatically; your suite is how you know behavior still clears your bar afterwards.
Comprehend as the pre-filter
DetectToxicContent scores text 0–1 overall and across seven categories (hate speech, graphic, harassment/abuse, sexual, violence/threat, insult, profanity) — a cheap, model-free gate before the invocation. Comprehend also shipped a binary prompt-safety classifier via ClassifyDocument, but that feature is closed to new customers — new builds lean on the guardrail prompt-attack filter for intent detection and keep Comprehend for toxicity and PII.
Lambda as the post-filter
Code that knows your response contract: validate against the schema, enforce tool-call allow-lists, cap lengths, strip URLs and markup you never emit, and swap any failure for a safe fallback. Model-based filters know harm; only your code knows what your application is allowed to say.
API Gateway as the outer shell
Authentication and throttling on the way in (an unauthenticated jailbreak is a jailbreak that never ran), and response filtering on the way out — mapping templates and response validation so nothing reaches the client unshaped. The exam names it as the final response-filtering layer.
Step Functions as the moderation bench
The custom moderation workflow the AIP-C01 exam guide names: branch on filter confidence — auto-allow, auto-block, or route the gray zone to a human-review queue with a timeout; fan out pre-filters in parallel; retry transient failures. State machines make the moderation policy visible, versionable, and auditable.
Key terms: Prompt injection, Jailbreak, Prompt-attack filter (PROMPT_ATTACK), Defense in depth, Adversarial testing (red teaming)
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.