Intermittent Prompt Injection False Positives with Azure OpenAI GPT-5.1 / GPT-5.4

Question

Intermittent Prompt Injection False Positives with Azure OpenAI GPT-5.1 / GPT-5.4

Dharun Balaji 80

Hi everyone,

We're using Azure OpenAI GPT-5.1 and GPT-5.4 in a production application and have observed an intermittent issue with prompt injection/jailbreak detection.

Occasionally, users submit completely normal inputs (such as dates, short replies, or other benign messages), but instead of receiving the expected response, the model returns a message similar to:

"I can't process that request because it triggered our safety rules (possible prompt injection/jailbreak attempt). Please rephrase your question without asking me to ignore policies or change roles."

This behavior is not consistent. The exact same or similar input usually works correctly, but very occasionally it is flagged as a potential prompt injection attempt.

From our observations:

The issue is rare and intermittent.
The user input is completely normal and does not contain any jailbreak or prompt injection instructions.
It has occurred across different parts of our application rather than in a single workflow.
We are using Azure OpenAI GPT-5.1 and GPT-5.4.

We are using semantic kernel as a AI agent framework.

I have a few questions for the community and Microsoft team:

Is this a known behavior or expected false-positive rate with Azure openai Models or jailbreak detection?
Does the detection evaluate the entire conversation history, causing earlier context to influence later user messages?
Are there any recommended best practices to reduce these intermittent false positives?
Is trimming conversation history or limiting the context sent to the model an effective mitigation?
Are there any configuration changes or deployment settings that can help reduce these false positives while maintaining appropriate safety protections?
Has anyone else experienced similar intermittent behavior with GPT-5.1 or GPT-5.4 in Azure OpenAI?
What can be the exact production grade fix for this issue.

Any guidance or recommendations would be greatly appreciated. We're trying to understand whether this is expected behavior, how to minimize it in production, and what the recommended approach is for handling these occasional false positives.

Thank you!

0 comments

Answer accepted by question author

Christos Panagiotidis 3,551

First confirm the source. A blocked Azure OpenAI input returns HTTP 400 with code content_filter; the raw result can show jailbreak.detected and jailbreak.filtered. An HTTP 200 refusal without annotations is not proof that Prompt Shields blocked it; it can come from the model, Semantic Kernel prompt, or application logic.

For each occurrence, log the request ID, status, finish reason, prompt_filter_results or content_filter_results, and the serialized messages: system instructions, history, tool output, retrieved documents, and input. The full request matters. Trim history only after identifying a triggering segment; blind retries are not a production fix.

Create a custom filter under Guardrails + controls, attach it to the deployment, and test Prompt Shields as annotate-only if permitted. Keep trusted instructions separate from untrusted documents. For reproducible benign cases, submit request IDs, timestamps, and payloads through Filters Feedback or Microsoft Support. Microsoft documents no universal false-positive rate or deployment setting that eliminates detections.

Dharun Balaji 80 Reputation points

2026-07-22T06:16:06.2033333+00:00

Thanks for the detailed suggestions they're very helpful.

In our case, we've already confirmed that the block originates from Azure OpenAI itself. We're using the Semantic Kernel Azure OpenAI connector, and the request fails with a ContentFilterAIException, which maps to an HTTP 400 content_filter response rather than a model-generated refusal.

One interesting observation is that retrying the exact same payload (without any changes and only when no tool has executed) often succeeds. This makes us wonder whether Prompt Shields/jailbreak detection is using a probabilistic threshold rather than a purely deterministic rule, especially for borderline cases.

We're also planning to log the complete filter annotations (jailbreak.detected, jailbreak.filtered, severity, etc.) together with the serialized request payload (system prompt, history, tool outputs, retrieved content, and current user input) to determine whether the trigger is the conversation context or simply an intermittent classifier false positive.

Our main question now is: Has Microsoft provided any guidance or best practices for reducing these intermittent false positives? Apart from logging, reporting request IDs, and using custom content filter configurations, are there any recommended design patterns for production systems using GPT-5.x that help minimize these occasional Prompt Shield detections?
Pavan Kumar Purilla 410 Reputation points Microsoft External Staff Moderator

2026-07-24T05:58:16.8+00:00

Hi Dharun Balaji,
Did you get any chance to review the above response. Do let me know if you have any further queries.
Dharun Balaji 80 Reputation points

2026-07-25T12:59:04.1966667+00:00

Hi @Pavan Kumar Purilla ,

Thank you for your response and for the guidance.

We appreciate the recommendations and will continue to capture the relevant request details, review the filtering results, and share reproducible cases with Microsoft Support if we identify consistent false positives.

Thank you again for your assistance.

1 additional answer

Your answer

Dharun Balaji 80 Reputation points

2026-07-22T06:16:06.2033333+00:00

Thanks for the detailed suggestions they're very helpful.

In our case, we've already confirmed that the block originates from Azure OpenAI itself. We're using the Semantic Kernel Azure OpenAI connector, and the request fails with a ContentFilterAIException, which maps to an HTTP 400 content_filter response rather than a model-generated refusal.

One interesting observation is that retrying the exact same payload (without any changes and only when no tool has executed) often succeeds. This makes us wonder whether Prompt Shields/jailbreak detection is using a probabilistic threshold rather than a purely deterministic rule, especially for borderline cases.

We're also planning to log the complete filter annotations (jailbreak.detected, jailbreak.filtered, severity, etc.) together with the serialized request payload (system prompt, history, tool outputs, retrieved content, and current user input) to determine whether the trigger is the conversation context or simply an intermittent classifier false positive.

Our main question now is: Has Microsoft provided any guidance or best practices for reducing these intermittent false positives? Apart from logging, reporting request IDs, and using custom content filter configurations, are there any recommended design patterns for production systems using GPT-5.x that help minimize these occasional Prompt Shield detections?
Pavan Kumar Purilla 410 Reputation points Microsoft External Staff Moderator

2026-07-24T05:58:16.8+00:00

Hi Dharun Balaji,
Did you get any chance to review the above response. Do let me know if you have any further queries.
Dharun Balaji 80 Reputation points

2026-07-25T12:59:04.1966667+00:00

Hi @Pavan Kumar Purilla ,

Thank you for your response and for the guidance.

We appreciate the recommendations and will continue to capture the relevant request details, review the filtering results, and share reproducible cases with Microsoft Support if we identify consistent false positives.

Thank you again for your assistance.

Answer 1

Hi Dharun Balaji,
Thank you for reaching out to Microsoft Q&A.

At this time, Microsoft has not published any specific configuration or deployment setting that eliminates intermittent Prompt Shield or jailbreak false positives. Since the request is being blocked with an HTTP 400 content_filter response, the recommended approach is to review the complete request context along with the content filtering results returned by the service.

As part of troubleshooting, we recommend capturing the request ID, timestamp, serialized request payload (including the system prompt, conversation history, retrieved content, tool outputs, and user input), and the filter annotations such as jailbreak.detected and jailbreak.filtered. These details can help determine whether the detection is being triggered by the conversation context, retrieved content, or a potential false positive.

If you identify reproducible cases where benign content is consistently flagged, please share the request details with Microsoft Support for further investigation.

I hope this helps. Please let us know if you have any further questions. Thank you!