Of the six policy types in Amazon Bedrock Guardrails, content filters are the ones nearly every deployment enables. They are classifier-based: rather than matching specific words, they assess whether text (or images) fall into harmful-content categories, and intervene when confidence crosses the threshold you set. This article covers the categories, the strength dial, and the configuration judgment calls enterprises actually face. For where content filters sit among the other policies, see the Guardrails overview.
The filter categories
AWS documents six content-filter categories, applied to both text and image content:
| Category | Targets |
|---|---|
| Hate | Content attacking people based on identity or group membership |
| Insults | Demeaning, humiliating, or bullying language |
| Sexual | Sexual content and advances |
| Violence | Glorification of, or threats of, physical harm |
| Misconduct | Seeking or providing guidance for criminal or harmful activity |
| Prompt Attack | Attempts to manipulate the model into ignoring its instructions (prompt injection and jailbreaks) |
Prompt Attack deserves a note: it is a security filter rather than a content filter in the everyday sense. It targets inputs crafted to override system instructions — "ignore your previous instructions and…" and its endlessly rephrased cousins. It naturally applies to the input side, and it pairs well with input tagging (available via SDK, not the console), which lets you mark which sections of a composite prompt the guardrail should evaluate — so trusted system text is not mistaken for an attack, and untrusted user text gets full scrutiny. Background on the attack class is in prompt injection basics.
Strength settings: the sensitivity dial
Each category has an adjustable strength setting, configured separately for prompts (input) and model responses (output). Higher strength means the filter intervenes at lower confidence — catching more genuinely harmful content and, inevitably, more borderline-but-legitimate content with it. Lower strength inverts the trade. The exact levels and their semantics are in the AWS Guardrails documentation; the principle to internalize is that strength is a false-positive/false-negative trade-off you should set per category, per direction, based on the application's exposure.
Some practical calibration guidance:
Public-facing beats internal. A chatbot on your public website talking to anonymous users warrants higher strengths than an internal tool used by authenticated employees under acceptable-use policy — the threat model and the reputational blast radius differ.
Domain vocabulary causes false positives. Insurance claims discuss injuries; hospital systems discuss anatomy; security teams discuss attacks; a games company discusses violence constantly. Test filters against a representative sample of legitimate domain traffic before production, and expect to lower strength in categories where your normal business reads as borderline.
Input and output strengths need not match. Many teams run stricter filtering on inputs (where adversarial content originates) and moderately on outputs — Claude's own training already makes egregious output unlikely, so the output filter is a backstop rather than the primary screen.
Tier and scope details that change results
Two documented details materially affect what content filters catch. First, the guardrail tier: Standard tier extends detection to harmful content embedded in code elements — comments, variable and function names, string literals — while Classic does not; if your users paste or generate code, that difference is not academic. Second, a scope limitation: guardrails do not evaluate reasoning content blocks, so extended-thinking output from Claude is not screened by these filters. Design your application so anything user-visible flows through filtered channels.
ApplyGuardrail API, and tune category by category from evidence. Never tune in production first.Where to go next
Content filters catch harmful content; for blocking off-limits subjects that are perfectly benign elsewhere, you want denied topics, and for personal data, PII detection and redaction. Wire it all together via the setup walkthrough.