Azure OpenAI Content Filters: The Good, The Bad, and The Workarounds

On this page

If you regularly use the Azure OpenAI LLMs, you have probably noticed two odd things. API calls on Azure sometimes take noticeably longer than the exact same model on the regular OpenAI platform. And you occasionally get cryptic content filtering errors, even for harmless business content.

Neither is a bug. Both come from Azure OpenAI's built-in content filtering system. Our short recommendation: set the harm category filters to their most permissive threshold, keep Prompt Shield on, and switch the filters to asynchronous mode. The rest of this post explains why and shows how.

By default, every request to Azure OpenAI passes through several content classification models that check both your input and the model's output for potentially harmful content. These extra safety layers explain both the added latency and the occasional unexpected rejection.

Content filtering has a real purpose in preventing misuse, but its default setup can be frustrating, sometimes outright absurd, in business scenarios. Many developers end up asking:

• Why are perfectly reasonable business prompts getting rejected?

• Why do API calls take longer than with regular OpenAI?

• How can we tune this for production use?

This guide covers what the filters actually do, why they may be too aggressive for your use case, and how their synchronous design hurts performance. Then it walks through the fixes: lower filter thresholds and asynchronous filtering.

What are Azure OpenAI content filters?

Azure OpenAI content filters are a set of AI classification models that run alongside the main language models (like GPT-4.1 or the GPT-5 family). They check both the input (your prompts) and the output (the model's responses) for potentially harmful or inappropriate content.

The filtering system has several components.

Core classification models

• Hate and fairness: detects discriminatory language or attacks based on identity characteristics
• Sexual content: identifies explicit sexual content or inappropriate material
• Violence: detects violent content or threats
• Self-harm: identifies content related to self-injury or suicide

Optional detection models

• Protected material: identifies copyrighted content (like song lyrics) or code from public repositories
• Prompt Shield: detects attempts to bypass the model's safety measures
• Groundedness: checks whether responses are based on the provided source material (only available in specific regions)

Each category has four severity levels: safe, low, medium and high.

By default, these filters run synchronously:

1. Your prompt is first analyzed by the content filters
2. If approved, it's sent to the language model
3. The model's response is then analyzed by the filters again
4. Only after passing all checks is the content returned to you

This sequence is why Azure OpenAI calls often take longer than regular OpenAI calls. Every request involves several AI models, not just the language model.

The safety system helps prevent misuse, but it can be overzealous in business contexts. A prompt about "database killing" in IT operations might get flagged for violence, or a healthcare application discussing medical conditions might trigger the self-harm filter.

How to configure content filtering for your use case

So how should you set up the content filters for your use case?

The official answer: analyze your use case and adjust the severity threshold for each content category, from 'Safe' to 'High'. Then test your application, add logging, and find where the filters are still too restrictive.

The unofficial answer: these filters are a pain to work with and rarely provide any meaningful benefit, with one exception, Prompt Shield. Our suggested strategy for now is to set all filters to the most permissive level (so only the most offensive prompts and answers get blocked), but keep Prompt Shield on.

The filters also slow down the whole inference pipeline, which hurts the performance of your applications. You can tune this too: instead of running the filters synchronously, set them to asynchronous mode. In this mode they run in parallel while the LLM's answer streams back to your application, which usually speeds things up quite a bit. And since the answer arrives while the content filter is still evaluating, you can simply ignore the filter's results, which is another way to reduce its impact.

Why the content filters cause problems in B2B scenarios

Our main objection: the filters block too many legitimate prompts and answers in business contexts, where you often don't need the AI safety/alignment/ethics checks at all. Our prompts about electrical engineering guidelines, for example, got blocked for 'self-harm' (I guess the filter models thought we wanted to electrocute ourselves). This over-blocking is a real problem for building repeatable, testable AI applications, because it adds yet another highly probabilistic variable you have to account for.

The Prompt Shield filter, on the other hand, has been useful in our tests and experience. Detecting prompt injection is hard, and prompt injection does cause problems in business applications. We also never got a false positive from Prompt Shield, so we keep it on. (For a self-hosted alternative to these safety classifiers, see our post on LLM safety with Llama Guard 2.)

---

Before we continue...

Interested in building high-quality AI agent systems?

We prepared a comprehensive guide based on cutting-edge research for how to build robust, reliable AI agent systems that actually work in production. This guide covers:

• Understanding the 14 systematic failure modes in multi-agent systems
• Evidence-based best practices for agent design
• Structured communication protocols and verification mechanisms

---

How to configure the Azure OpenAI content filters

To set the filters to the most permissive threshold and switch them to asynchronous mode, follow these steps:

1. Open Azure OpenAI Studio and select the Azure OpenAI resource you want to configure, or create a new resource.

   Selecting an Azure OpenAI resource in Azure OpenAI Studio

2. In the resource dashboard, select "Safety + security" in the left-hand menu. Click on "Create content filter".

   The "Create content filter" button on the Safety + security page

3. Enter a name and click on "Next".

4. The next screen sets the threshold of the input filters, the filters that run on your prompts. Set all the sliders to "High" ("Allow Low and Medium / Block High"). Leave Prompt Shield for jailbreak attacks at "Annotate and block".

   Input filter thresholds set to High, Prompt Shield set to block

5. Click on "Next". Almost the same screen appears again, this time for the output filters, which run on the model's output. Set all the sliders to "High" again and set the other settings to "Off".

   Output filter thresholds set to High, protected material filters off

6. Don't click on "Next" yet. Scroll down and set "Streaming mode" to "Asynchronous Filter".

   Streaming mode set to Asynchronous Filter

7. Click on "Next". On the final screen, select the model deployments that should use the new filter. If you don't have any deployments yet, skip this step. Click on "Next" and then "Create".

   Assigning the new content filter to model deployments

That's it. Your Azure OpenAI deployments now use the new content filter, which is much faster and blocks far less.

For new deployments, select the filter when you create the deployment.

Selecting the content filter while creating a new deployment

Filter settings are one of many details that decide whether a business application on Azure OpenAI works in daily use. If you are planning such a project, our AI consulting starts with a two-day analysis that ends in a concrete implementation plan.

Further reading

• How to test your RAG pipeline?
• Advanced RAG: Recursive Retrieval with llamaindex
• DSPy: Automatic prompt tuning and creating
• Free and open source ChatGPT alternative: LibreChat
• RAG with Azure AI Search: a step-by-step tutorial
• Enterprise AI agents with the Microsoft Agent Framework

About the author

Andreas Nigg

Co-Founder, Pondhouse Data

Andreas has spent more than eight years building data applications. At Pondhouse Data he designs and ships AI systems and integrates them into complex, real-world environments.

Talk to Andreas about your projectFollow on LinkedIn