Detect attacks at every instruction boundary

Learning objective

Detect direct prompt injection, indirect injection through retrieved data and tool results, and jailbreak attempts.

Core idea

Prompt attacks differ in both their entry point and their intended effect. Direct injection arrives in the user’s request and tries to override application instructions. Indirect injection arrives as data, such as a retrieved document or tool result, and tries to acquire the authority of an instruction. A jailbreak attempts to bypass the model’s safety behavior. One payload can combine these objectives.

For an architect, detection starts with the trust boundary. Ask who controls each piece of text, why the application includes it, and whether it asks the model to change its governing instructions. A topic keyword alone cannot answer those questions. A harmless security-training document can quote an attack; an apparently ordinary product page can contain a takeover instruction.

How it works

Distinguish the attack’s origin from its goal

AWS describes prompt injection as instructions designed to ignore or override developer instructions. It describes jailbreaks as attempts to bypass native safety and moderation capabilities and generate harmful or dangerous content. Its examples include persona takeover and many-shot jailbreaks. The prompt attack documentation also describes prompt leakage, supported in the Standard tier, as an attempt to expose system prompts or confidential configuration.

Direct injection can ask a banking assistant to abandon its assigned role. A jailbreak can frame prohibited content as a fictional exercise. Indirect injection can hide a request to reveal secrets in a document that retrieval presents as evidence. These are useful application categories; they are not three independent Bedrock filter enums. Configure the Bedrock content filter with type: PROMPT_ATTACK, then preserve the attack origin in your own evaluation and incident records.

Do not classify by syntax alone. Role labels, imperative sentences, or XML-like tags are evidence to review, not conclusive proof. Legitimate documents use the same forms. Your detection policy should distinguish quoting an instruction for analysis from adopting it as an instruction, and your execution policy should reject authority changes even when the detector misses them.

Configure the filter and its assessed content

The prompt attack filter uses contentPolicyConfig.filtersConfig, with type: PROMPT_ATTACK and inputStrength set to NONE, LOW, MEDIUM, or HIGH. inputAction: BLOCK blocks detected content; inputAction: NONE returns detection information without taking that blocking action. A configuration that detects attacks but allows processing is an observation setting, not an enforcement gate.

For InvokeModel and InvokeModelWithResponseStream, AWS requires input tags for prompt attack filtering. Without tags, prompt attacks on those inference paths are not filtered. Enclose the intended untrusted input using the amazon-bedrock-guardrails-guardContent tag prefix and a suffix configured through amazon-bedrock-guardrailConfig.tagSuffix.

AWS recommends a random suffix for each request because a predictable static tag can let malicious input close the guarded segment. The suffix must contain 1–20 alphanumeric characters. Generate that value in the application; do not accept it from the user. The suffix reduces a delimiter attack opportunity, but it does not grant the enclosed text permission to change your policy.

For Converse, guardContent provides selective assessment of content blocks. Keep selection under application control and test the actual message assembly. A user request that was assessed before retrieval is not the same input as a later prompt containing a retrieved document. If your assembly adds more untrusted text, the release test must verify coverage of that added text.

Close the indirect-input coverage gap

Inline Converse Guardrails exclude tool results, tool definitions, and generated tool-call arguments; see 3.1.2 for enforcement coverage and 3.1.7 for tool-output trust.

Extracted retrieval passages are also untrusted input: screen their task-relevant text for PROMPT_ATTACK before context admission, even when the user’s original request passed. Use the separate ApplyGuardrail input-assessment path described in 3.1.7 for extracted retrieval and tool-owned text. Pair the assessment with application checks for instruction redirection, and preserve the source, assessed content, and exclusion decision. Those records must distinguish text that was never assessed from text that was assessed but not detected; otherwise, a missing retrieval gate can look like a classifier error.

Inspect ApplyGuardrail.action and assessments rather than treating HTTP success as an approval. GUARDRAIL_INTERVENED reports intervention; NONE reports no intervention. Neither outcome is an authorization grant. A clean assessment must not enable an otherwise forbidden tool call, secret disclosure, or cross-tenant read. See 3.2.2 for independent authorization.

Key distinctions and trade-offs

Use the following classification to select test coverage:

Higher filter strength can increase harmful-content filtering, but a stricter setting still needs evaluation on legitimate requests. Security education, incident reports, and quoted attack strings are useful benign controls. Measure blocked legitimate work and successful attack behavior separately; see 3.1.10.

Detection and containment complement each other. Removing a detected passage preserves the boundary for that request. Restricting tool capabilities limits the consequence of undetected attacks. A model reminder to ignore hostile text is useful instruction design, but it is not the same as a server-side authorization check.

Architecture / decision scenario

A product-support assistant receives three inputs: a user asks it to disregard its role, a retrieved manual contains a forged system message, and a tool returns a persona-based jailbreak inside a valid description field.

The team configures blocking prompt attack detection for user input and tests its selected content boundaries. It assesses retrieved and tool-owned text separately before context admission instead of relying on inline tool-result coverage. A finding excludes the affected source and produces a controlled response; an assessment error produces a distinct unavailable outcome.

The test harness checks the next model request, tool attempts, and final response. It includes a benign manual explaining injection attacks, so the team can see whether useful evidence is rejected. Even an undetected attack cannot authorize an account change because the account adapter enforces its own permissions.

Common exam traps

• Treating indirect injection as an ordinary user-input-only problem.
• Confusing a jailbreak’s safety-bypass goal with its delivery channel.
• Expecting prompt attack filtering without required native-API input tags.
• Letting the attacker select guarded segments or tag suffixes.
• Treating inputAction: NONE as blocking protection.
• Equating no guardrail intervention with permission to execute tools.

What to remember

Detect attacks where untrusted content enters context, including after retrieval and tool execution. Use PROMPT_ATTACK, explicit input selection, and a tested blocking policy. Inline tool-result content is outside Guardrails coverage. Preserve origin labels and enforce capabilities independently so a missed detection does not become an authorized action.

Knowledge check

References

• AWS, Detect prompt attacks with Amazon Bedrock Guardrails
• AWS, Apply tags to user input to filter content
• AWS, Include a guardrail with the Converse API
• AWS, GuardrailContentFilterConfig
• AWS, ApplyGuardrail