Azure OpenAI API: content_filter triggered with null/empty category metadata

Hi Yaroslav Saputskyi,

Thank you for raising this — your observation is valid, and this behavior can indeed be confusing at first
What’s happening

In Azure OpenAI, content filtering is not a single-step process. It includes multiple safety layers, and some of these run before the standard category classifiers (Hate, Violence, etc.).

Specifically, features like Prompt Shields (jailbreak / prompt injection detection) can block a request early in the pipeline. When that happens:

• The response returns: finish_reason: content_filter

But category metadata (hate, violence, etc.) may be null or empty

This is expected because the request was filtered before category-level evaluation was executed, so there’s no category result to return.

Microsoft documentation confirms that Prompt Shields analyze inputs for adversarial or jailbreak-style prompts and operate independently of standard category classifiers.
Why Content Safety Studio shows “Safe”

This discrepancy is also expected.

Azure AI Content Safety Studio uses standalone moderation models

Azure OpenAI uses a broader, integrated filtering pipeline (including prompt shields and policy checks)

Because of this, the same prompt can:

Pass in Content Safety Studio

Still be blocked in Azure OpenAI

The filtering system combines multiple classifiers and policies beyond just the four harm categories.

How to investigate

Here are a few practical steps to narrow this down:

1. Check Prompt Shield configuration
   • In Azure AI Foundry → Deployment → Content Filters
   • Verify if Prompt Shields (jailbreak / indirect attack detection) are enabled
2. Review full content filter policy
   • Look beyond Hate/Violence categories
   • Check for:
   • Jailbreak detection
   • Indirect prompt injection
   • Protected content filters
3. Test in the Chat Playground (same deployment)
   • This ensures you're testing against the actual OpenAI pipeline, not the standalone safety service
4. Log full API response
   1. Inspect content_filter_results carefully
   2. Sometimes signals appear under non-standard keys (e.g., jailbreak-related flags)
   3. About recent changes / regression

You mentioned this worked earlier — that’s important.

Microsoft periodically updates filtering behavior and models as part of safety improvements. These changes can affect:

Sensitivity thresholds

Detection behavior

Upstream filtering layers

So a regression without changes on your side is possible.

Conclusion

• This behavior is expected in certain scenarios, especially when pre-classification filters (like Prompt Shields) are triggered
• That’s why you see content_filter with no category metadata
• The issue is likely not a bug in your implementation, but part of the filtering pipeline design

Reference Documentation

• Azure OpenAI Content Filtering Overview https://learn.microsoft.com/azure/ai-services/openai/concepts/content-filter
• Prompt Shields (Jailbreak / Injection Detection) https://learn.microsoft.com/azure/ai-services/openai/concepts/content-filter-prompt-shields
• Configure Content Filters https://learn.microsoft.com/azure/ai-services/openai/how-to/content-filters
• Azure AI Content Safety Overview https://learn.microsoft.com/azure/ai-services/content-safety/overview

Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.
Please do not forget to "Accept Answer" and "up-vote" wherever the information provided helps you, as this can be beneficial to other community members.

Hello Yaroslav Saputskyi,

Greetings!

Thanks for raising this question in Q&A forum.

This is a great observation and you're not alone in seeing this. What's happening here is that Azure OpenAI's content filtering backend occasionally triggers a block at a pre-classification stage (such as prompt shield, jailbreak detection, or an upstream policy check) before the per-category evaluators (Hate, Violence, etc.) even run. That's why your finish_reason shows content_filter but the category metadata comes back as null or empty — there's simply nothing to report at that level because the block happened earlier in the pipeline.

Here's how to investigate and work around this step by step:

Step 1: Check for Prompt Shield or Indirect Attack Detection

Azure OpenAI has a layer called Prompt Shields that detects jailbreak attempts and indirect prompt injection — separately from the standard content categories. This layer doesn't always populate category-level metadata. In the Azure AI Foundry portal, go to your deployment and check if Prompt Shields is enabled under Content Filters.

Step 2: Review Your Full Content Filter Policy

Go to Azure AI Foundry → Your Project → Deployments → Select your deployment → Content Filter. Review each policy applied — especially "Prompt Shields for Jailbreak" and "Indirect Attack Detection." Even if Hate/Violence shows null, these extra policies may be the culprit.

Step 3: Cross-check With the Correct Studio

Azure AI Content Safety Studio tests the standalone content safety API, not the full Azure OpenAI pipeline. So a "Safe" result there doesn't guarantee the OpenAI deployment will pass — they use overlapping but not identical filter stacks. Make sure you test directly through the Azure AI Foundry Chat Playground using your actual deployment.

Step 4: Inspect the Full API Error Response

Log the complete raw API response including all headers and the content_filter_results block. Sometimes the triggering policy appears under a key like "jailbreak" or "indirect_attack" rather than the standard category names. Look for any non-null field in that block.

Step 5: Check for Recent Backend Changes

Microsoft periodically updates the default content filter policies. Check the Azure OpenAI Service changelog at aka.ms/aoai-releasenotes to see if there were recent updates to default filter configurations that may have affected your deployment.

Step 6: Raise a Support Ticket if the Issue Persists

Since you mentioned this was working in production until recently with no changes on your end, this could be a backend regression. Please open an Azure Support Request (Severity B) referencing the specific deployment name, resource region, timestamp of failing requests, and the null metadata response. The engineering team can inspect backend filter logs that are not exposed through the API.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.