Azure OpenAI Content Filters Are Blocking Your Security Research Prompts: Here's the Workaround

Azure OpenAI's content filtering system classifies both prompts and completions across four harm categories, violence, hate, sexual, and self-harm, each scored at one of four severity levels: safe, low, medium, or high. The default configuration on every new deployment filters at the medium threshold for all four categories, on both the prompt and the completion side, meaning anything the classifier scores at medium or high gets blocked outright while low and safe pass through untouched. That threshold is not domain-aware. A classifier tuned to catch a medium level of violent or self-harm content in generic consumer-facing text has no separate calibration for a security analyst's ordinary working vocabulary, kill chain, weaponized, destructive payload, self-propagating, encrypt and exfiltrate, which describes technical behavior but shares surface-level language with the exact categories the filter exists to catch. Microsoft's own documentation on mitigating false results in Azure AI Content Safety acknowledges this directly: conservative default thresholds are a deliberate risk-minimization choice across the full customer base, and specialized domains including security research routinely cross them on entirely safe content as a result.

Azure OpenAI's configurability applies separately to prompts (input) and completions (output), and understanding which one is firing matters because they fail differently. A prompt-side block happens before the model generates anything at all: if your input describing the malware behavior itself scores at or above the configured threshold, the request is rejected immediately with a content_filter result and zero tokens are generated, meaning the model never even attempted an answer. A completion-side block happens after generation: the model produces a response, and the output classifier scores that generated text and discards it if it crosses the threshold, which in streaming mode can mean a response starts arriving and then cuts off mid-stream once the classifier catches up. The same underlying vocabulary can trip either checkpoint depending on whether it appears in what you sent or in what the model generated back, and Azure's per-request content_filter_results object annotates the category and severity score for both the prompt and the completion separately, which is the fastest way to tell the two apart without guessing.

Before touching any configuration, pull the actual API response for a blocked request rather than working from the assumption that "the filter is too strict." The response's content_filter_results object reports a severity score per category (violence, hate, sexual, self_harm) for the prompt, and a separate set for the completion if generation was attempted at all. A response with zero completion tokens and a prompt-side category flagged confirms cause one above at the prompt checkpoint specifically; a response with partial or full completion text followed by a content_filter finish reason confirms the block happened on the output side after the model had already started answering. The Foundry portal's playground exposes a Filters Feedback button once a prompt has been submitted, which is the quickest way to reproduce a specific blocked prompt in a controlled setting and see the exact category and severity score that tripped, rather than inferring it from an API error alone. Also confirm which content filter policy is actually attached to the deployment in question, since a resource can have multiple named policies and it is easy to be testing against a different deployment's configuration than the one your production workload actually uses.

This is the fix that resolves the overwhelming majority of security-research false positives, and it requires no approval process at all. Every Azure OpenAI customer can create a custom content filter configuration in the Foundry portal's Guardrails and controls page, set the severity threshold independently for each of the four harm categories, and set it independently for prompts versus completions, choosing low-medium-high filtered (strictest), medium-high filtered (the default), high-only filtered, or, for approved use cases only, no filtering or annotate-only. Raising the threshold to "filter high severity only" for the categories your security-research workload legitimately trips, most often violence and self-harm, is usually enough to let ordinary malware, exploit, and ransomware descriptions through while still blocking genuinely extreme content. That custom policy is created at the resource level and then associated with one or more specific deployments, and Azure also supports specifying a policy at request time via an x-policy-id header, which lets you scope a loosened threshold to exactly the calls that need it rather than loosening filtering resource-wide. Create a separate deployment scoped specifically to the security-research workload and attach the adjusted policy only to that deployment, so other, non-research workloads sharing the same Azure OpenAI resource keep the default, stricter filtering.

Threshold adjustment does not cover every case. If raising a category to "high severity only" still is not enough, because the workload genuinely needs to process content that would score high even by a reasonable standard, for example ingesting raw malware sample descriptions or actual exploit code for detection engineering, the next step is Microsoft's own governed process: the Azure OpenAI Limited Access Review for Modified Content Filters. That form is the only legitimate path to annotate-only mode, where the classifier still scores content and returns those scores in the API response for your own logging and audit purposes but does not block anything, or to fully disabling filtering on completions. Approval requires clearly explaining the business use case, the risk controls in place, and how misuse will be prevented, and Microsoft's own documentation is explicit that a stronger, more specific justification moves the review faster than a generic one. There is a real eligibility limitation worth knowing before filing: full content filtering control through this form is currently available only to customers managed by a Microsoft account team or an eligible program, and Microsoft's own guidance states that it is not currently possible to become a managed customer solely to gain this access. For an unmanaged, self-serve Azure OpenAI account, severity threshold adjustment is the practical ceiling today, and reaching full modified-filter access means routing the request through your organization's existing Microsoft account relationship, if one exists, rather than filing the form directly as a self-serve customer.

If the false positives look less like your specific prompts and more like a broader miscalibration, the same phrase blocked consistently across many analysts on your team, or ordinary industry-standard terminology (a specific CVE description, a common malware family name) tripping the filter every time, report it through the Filters Feedback button in the playground or through an Azure support ticket rather than only adjusting your own thresholds. Microsoft's support process can review specific reported false positives and escalate internally if the flagged content is determined to be safe and compliant, which is the mechanism by which the underlying classifiers actually improve over time rather than every customer independently discovering and threshold-tuning around the same gap.

After creating and attaching a custom policy, re-run the specific prompts that were previously blocked against the updated deployment and confirm the content_filter_results object now reports the relevant category as not filtered at your new threshold, rather than just confirming a response came back, since a partial completion can still be truncated by a category you did not adjust. If you moved to annotate-only mode under an approved modified-filter policy, confirm the annotations are still present in the API response even though nothing is blocked, since losing that telemetry defeats the audit purpose the approval was granted for in the first place. Separately, check your Azure account's abuse monitoring or Responsible AI dashboard after the change; Microsoft continues to monitor usage even under a loosened threshold, and a spike in flagged-but-unblocked content is worth reviewing internally before it becomes a compliance question raised externally.

Some categories of content have a hard floor that no approval process removes for any customer, most notably content involving the sexual exploitation of minors, and no severity adjustment or Limited Access approval changes that. Separately, if a workload only produces usable results with filtering fully disabled and no threshold in between low and off resolves the false positive, that is a signal worth taking seriously on its own terms: it usually means the workload is asking Azure OpenAI to directly process genuinely hazardous raw material (live exploit payloads, functional malware code) rather than analyzing or summarizing it, and the better architectural fix is usually to keep that raw material in an offline, access-controlled analysis environment and use Azure OpenAI only for the downstream summarization or detection-writing step on sanitized output, rather than pushing for broader and broader filter exceptions on the ingestion step itself. Prompt Shields for jailbreak detection is also a separate control from the four harm categories and can independently false-positive on prompts that legitimately contain injection or phishing payloads you are analyzing (for example, pasting in a real phishing email for a write-up); it is configured and toggled separately from the violence/hate/sexual/self-harm thresholds, so resolving one does not resolve the other.

Escalate to your organization's Microsoft account team, rather than continuing to tune thresholds, once the workload has a genuine, recurring business need for annotate-only or fully disabled filtering that threshold adjustment alone cannot satisfy, and bring a specific, concrete use case description, since Microsoft's own reviewers move faster on well-justified applications than generic ones. Loop in your compliance or legal team before filing a Limited Access Review, not after approval, since accepting modified content filtering means your organization is formally taking on responsibility for a guardrail Microsoft would otherwise be enforcing on your behalf, and that is a decision worth documenting deliberately rather than treating as a pure engineering configuration change. If your organization is not currently a managed Microsoft customer and genuinely needs full filtering control, that gap is a commercial and account-relationship question, not a technical one, and belongs with whoever owns your Azure enterprise agreement rather than with the engineering team running the deployment.