Guardrails in depth: both directions, every policy
Lesson 1 of 3 in Guarding Inputs and Outputs.
The MLA security module taught the shape of Amazon Bedrock Guardrails: one versioned policy set screening the prompt on the way in and the response on the way out, attached to models, agents, and knowledge bases. The professional exam assumes that and asks harder questions: which policy sees which direction, what happens mechanically at an intervention, and how the same guardrail runs outside the invocation path.
The mechanics first, because three exam distinctions live there. During an invocation (InvokeModel, Converse, and their streaming forms), the input is evaluated against every configured policy in parallel — a latency decision, not a logical one. If an input policy intervenes, the configured blocked message returns and the foundation model is never invoked: no generation happens, and no inference is billed for the call the guardrail prevented. If the input passes, the model generates, and the response is then evaluated against the output-side policies — an intervention there overrides the draft with the blocked message, or masks the offending entities and lets the rest through. A clean turn passes unmodified. Guardrails apply to text and chat FMs (not embedding, reranking, or image-generation models), and a guardrail is edited as a working draft until you cut an immutable numbered version — the unit you attach, test, and roll back.
| Policy | Screens | On violation | The professional detail |
|---|---|---|---|
Content filters | prompts + responses | block | Six categories — hate, insults, sexual, violence, misconduct, prompt attack — each with its own strength setting per direction. The Standard tier extends detection into code: comments, variable and function names, string literals. |
Prompt attack (content-filter category) | inputs | block | The injection and jailbreak detector. Input-side by nature — a response cannot inject itself. Reports confidence NONE → HIGH against your configured strength. |
Denied topics | prompts + responses | block | Topics defined in natural language with sample phrases — "investment advice" for the bank bot. Policy enforcement, not prompt engineering. |
Word filters | prompts + responses | block | Case-insensitive whole-word and whole-phrase matching: a managed profanity list plus custom entries like competitor names. |
Sensitive information | prompts + responses | block or mask | Probabilistic PII entity detection plus custom regex. Masking replaces the entity with a typed placeholder and lets the turn continue — the exam tell for "summaries must not contain account numbers". |
Contextual grounding checks | responses only | block | Scores the draft 0–1 twice — GROUNDING and RELEVANCE — against your thresholds. Needs the retrieved source passages to compare against. |
Automated Reasoning checks | responses only | findings, not just a gate | Formal-logic validation against a policy built from your documents — explains why a statement is valid or invalid and flags unstated assumptions. |
The professional move is realizing the guardrail is not welded to the invocation. The ApplyGuardrail API evaluates any text against a guardrail version — source: INPUT for user-side content, source: OUTPUT for model-side — without invoking any model. That unlocks three patterns the exam loves: moderate the user's message before the app spends money on retrieval and generation; screen responses from a model hosted outside Bedrock (a SageMaker endpoint, a third-party API) with the same audited policy; and drive adversarial test suites in CI, where the response's action field (NONE or GUARDRAIL_INTERVENED) and per-policy assessments become assertions.
One more SDK-only control: input tags. A RAG turn bundles system instructions, few-shot examples, conversation history, and retrieved passages around one new user message — and by default the guardrail evaluates all of it, so your own scaffolding can trigger false blocks turn after turn. Tagging scopes input evaluation to just the untrusted section. It is available through the AWS SDK, not the console.
A stack of four mounting points for the same Amazon Bedrock guardrail. Bottom: model invocation — InvokeModel and Converse calls name the guardrail id and version, and both input and output are evaluated. Second: agents — the guardrail attaches to a Bedrock agent and also screens its generated reasoning and answers. Third: knowledge bases — RetrieveAndGenerate applies the guardrail around grounded generation. Top, emphasized: the ApplyGuardrail API — any text from any model, including models hosted outside Bedrock, evaluated with no model invocation at all.
Key terms: Amazon Bedrock Guardrails, ApplyGuardrail API, Guardrail input tags (selective evaluation), Contextual grounding check, Automated Reasoning checks
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.