AWS Public Sector Blog
This content has been blocked by our content filters on Amazon Bedrock—Now what?
If you’ve received the message “This content has been blocked by our content filters” while using a foundation model (FM) on Amazon Bedrock, or a model has otherwise refused to perform a task, you’re not alone. This is a question customers sometimes face when building applications to process sensitive or complex content on Amazon Web Services (AWS) when that content triggers safety mechanisms. This post walks you through a practical framework for understanding why this happens and what you can do about it.
Why do models refuse requests?
Model providers train FMs with safety mechanisms that cause them to decline certain types of requests. Providers implement these mechanisms to prevent misuse and protect end users. Content filtering and refusal behavior comes from multiple layers:
- Model-level safety training – Each FM is trained by its provider with built-in refusal behaviors. These vary between model families and even between versions within the same family.
- Provider acceptable use policies (AUPs) – Each model provider on Amazon Bedrock (Amazon, Anthropic, Meta, Mistral, Cohere, AI21 Labs, and others) maintains their own terms of service and AUP that define what the model can and can’t be used for. You can find these on the AI Service Cards for Amazon models and on the Serverless Third-Party Models on Amazon Bedrock End User License Agreement (EULA) and Terms of Service (TOS).
- Amazon Bedrock platform-level protections – Amazon Bedrock includes abuse detection features to prevent misuse that violates the AWS Acceptable Use Policy.
The challenge is that these safety mechanisms can’t distinguish between malicious intent and legitimate business need. Law enforcement analysts reviewing threat communications, healthcare providers processing crisis intervention notes, and content moderation platforms analyzing user reports might all encounter refusals.
How to troubleshoot content filtering challenges
We recommend two steps:
1. Verify the provider’s policies permit your use case.
2. Evaluate the model’s technical performance with representative data and tasks.
These steps are explained in the following sections.
Verify your use case is permitted
Consult your legal and compliance teams when working with sensitive content. Confirm that your intended use case is allowed under the model provider’s AUP. Restrictions vary across models including limitations on:
- Criminal justice and law enforcement applications
- Surveillance and monitoring
- Biometric identification and facial recognition
- Predictive policing
- Automated decision-making and profiling
Some restrictions are absolute. Others can be addressed through an approval or exception process with the provider. Review the relevant policies for models and services in scope:
- AI Service Cards – Transparency resources covering intended use cases, limitations, and design choices for AWS AI services
- Serverless Third-Party Models on Amazon Bedrock
- Responsible use in the Amazon Nova User Guide
- AWS Acceptable Use Policy
- Amazon Bedrock abuse detection
Key takeaway: Don’t invest engineering effort into a model whose provider doesn’t permit your use case.
Evaluate models with your own data
Published benchmarks and general guidance can help you narrow the field, but the only reliable way to know if a model works for your use case is to test it with data that’s representative of your actual workload.
Amazon Bedrock Evaluations provides built-in model evaluation capabilities that you can use to compare models using your own datasets and evaluation criteria. You can assess models on task accuracy, robustness, toxicity detection, and run evaluations across multiple models simultaneously.
With open source evaluation frameworks such as PromptFoo, you can define test cases with assertions to systematically measure how models handle your content. You can create evaluation suites that test whether a model refuses or completes tasks across your specific content categories, using both deterministic checks (for example, detecting refusal patterns in output) and model-graded assessments (for example, scoring output quality against a rubric).
What to measure:
- Task completion rate – How often does the model successfully complete the task and how often does it refuse?
- Refusal patterns – Which content categories trigger refusals? Are they relevant to your workload?
- Output quality – When the model does respond, is the output accurate and useful?
- Consistency – Does the model behave predictably, or do minor prompt variations cause different refusal behavior?
Key takeaway: Narrow your candidate models using these steps, then invest evaluation effort on the resulting list using iterative results as you experiment with prompts across multiple candidate models.
Putting it all together
In summary, here’s the decision flow:
1. Check the policies – Identify models that permit your use case.
2. Evaluate with your data – Test your short-listed models with representative samples from your actual use case.
This isn’t a one-time exercise. As new models become available on Amazon Bedrock and providers update their policies and safety training, it’s worth periodically reevaluating your model selection.