Content filters police harm. Denied topics police scope. A retail bank's Claude-powered chatbot answering "should I put my savings into crypto?" is not producing harmful content by any general standard — but the bank's compliance team may regard unlicensed investment advice as a serious problem. Amazon Bedrock Guardrails' denied-topics policy exists for exactly this: you define subject areas the application must not engage with, and the guardrail blocks matching prompts and responses.
Why "regardless of wording" is the whole point
The naive way to keep a chatbot off a subject is a blocklist of keywords. It fails immediately: users rephrase, misspell, use synonyms, or approach the subject sideways ("hypothetically, if someone wanted to move their pension into…"). Denied topics work at the level of meaning — the guardrail evaluates whether the prompt or the model's completion falls into the defined subject area, not whether it contains particular strings. Bedrock Guardrails keeps exact-string matching as a separate policy type, word filters (which also include a managed profanity list); the two are complementary. Word filters catch specific terms you can enumerate — competitor names, project code names, slurs. Denied topics catch subjects you cannot enumerate.
| Denied topics | Word filters | |
|---|---|---|
| Matches on | Meaning of the text | Exact words and phrases |
| Survives rephrasing | Yes — that is its job | No |
| Best for | "No investment advice," "no medical diagnosis" | Product code names, profanity, specific banned terms |
Writing topics that actually work
A denied topic is only as good as its definition — the guardrail classifies against what you wrote, not what you meant. The AWS documentation covers the exact configuration fields; whatever the mechanics, the drafting discipline is the same:
Be specific about the boundary, not just the subject. "Finance" is a terrible denied topic for a bank — the whole application is finance. "Recommendations to buy, sell, or hold specific investment products" is a boundary. The narrower and more concrete the definition, the fewer legitimate requests you swallow.
Write one topic per rule, not an omnibus. Separate "investment advice," "pending litigation," and "employee compensation" into distinct topics. You can then tune, test, and — importantly — remove them independently, and your block metrics tell you which rule is firing.
Decide the user experience deliberately. A blocked turn should return a useful redirection ("I can't advise on investments — here's how to reach a licensed advisor") rather than a bare refusal. Configure the guardrail's intervention messaging accordingly, and align it with the application's tone.
Both directions, and the escape hatches to close
Guardrails evaluate input prompts and model completions, and denied topics should generally apply to both: the input check catches the direct question, while the output check catches the model wandering into the topic from an innocent prompt — a real failure mode in long conversations. Two scope notes from the documentation to design around: guardrails do not evaluate reasoning content blocks, and enforcement only happens on calls that actually reference the guardrail ID and version — so route all production traffic through a wrapper that attaches it (see the setup walkthrough).
Expect adversarial pressure, too. Users probe topic boundaries the way they probe content filters — role-play framings, hypotheticals, "for a school essay." The Prompt Attack content filter targets instruction-override attacks and belongs alongside denied topics in any public-facing deployment (see content filtering policies). And build a regression suite: representative in-scope prompts that must pass, paraphrase families of each denied topic that must block, run through the standalone ApplyGuardrail API on every policy change. Topic definitions drift out of date as the business changes; the suite is what tells you.
Where to go next
Round out the policy bundle with PII detection and redaction, then pressure-test everything using the approach in guardrail testing.