Azure AI Foundry: Where can I view all content-filter-blocked prompts and the reason each was blocked?

Vu Thanh Trung 20 Reputation points
2026-06-03T08:31:38.57+00:00

I'm using an Azure OpenAI / AI Foundry model deployment (region: Japan) with a content filter configuration attached, including a custom blocklist. I need to see a complete record of every prompt that was blocked by the content filter, along with the specific reason for each block — i.e. which category triggered it (hate / sexual / self-harm / violence / jailbreak) or which custom blocklist term matched, and the severity level.

What is the supported way to retrieve the full list of blocked prompts and their block reasons? Specifically:

  • Is there an in-portal view that shows blocked prompt text plus the triggering category/blocklist?
  • If not, how do I get this from diagnostic logs (e.g. Log Analytics / requestPayload_s, content_filter_result), and does that capture the prompt content and the blocklist id that matched?
  • Are blocked prompts logged anywhere automatically, or must I enable diagnostic settings first?
  • Does any of this require a specific region or a separate plan (e.g. Defender for Cloud / abuse monitoring)?
Content Safety in Foundry Control Plane
Content Safety in Foundry Control Plane

An Azure service that enables users to identify content that is potentially offensive, risky, or otherwise undesirable. Previously known as Azure Content Moderator.

0 comments No comments

1 answer

Sort by: Newest
  1. Jerald Felix 18,680 Reputation points Volunteer Moderator
    2026-06-03T11:51:22.1+00:00

    Hello Vu Thanh Trung,

    Greetings! Thanks for raising this question in Q&A forum.

    This is a very detailed and well-structured question! The short answer is there is no built-in in-portal view that shows blocked prompt text with block reasons out of the box. You need to enable Diagnostic Settings first, and then query the logs via Log Analytics. Let me walk you through everything step by step.

    Step 1 — Enable Diagnostic Settings (this is mandatory first)

    Blocked prompts are NOT logged automatically. You must turn on diagnostic logging before any data starts flowing.

    1. Go to the Azure Portal and open your Azure OpenAI resource in Japan region.
    2. In the left menu, click on "Diagnostic settings" under Monitoring.
    3. Click "Add diagnostic setting."
    4. Select the log category "RequestResponse" (this captures prompt content and filter results) and also "AuditLogs" if available.
    5. Choose "Send to Log Analytics workspace" as the destination and select or create a workspace.
    6. Save the settings. Note that logs will only start collecting from this point forward — past blocked prompts are not retrievable.

    Step 2 — Query Blocked Prompts in Log Analytics

    Once logs start flowing (usually within a few minutes), do the following:

    1. Open your Log Analytics workspace and click on "Logs."
    2. Use the table AzureDiagnostics to query content filter events. Run a query like this to find blocked requests:
    AzureDiagnostics
    | where ResourceProvider == "MICROSOFT.COGNITIVESERVICES"
    | where statusCode_d == 400
    | where requestPayload_s contains "content_filter"
    | project TimeGenerated, requestPayload_s, responsePayload_s
    

    The responsePayload_s field will contain the content_filter_result object which shows the triggered category (hate, sexual, self-harm, violence, jailbreak) and the severity level (safe, low, medium, high).

    For custom blocklist matches, look inside the content_filter_result for the custom_blocklists field — it will include the blocklist ID that matched the prompt.

    Step 3 — Understanding What Gets Logged

    The actual prompt text is captured in requestPayload_s — but be aware this field may be truncated for very long prompts. The filter category and severity are reliably captured in responsePayload_s.

    Blocklist-triggered blocks will show a filtered: true flag along with the matching blocklist ID, but the specific term that matched is generally not exposed in logs for privacy/security reasons.

    Step 4 — Region and Plan Requirements

    1. This diagnostic logging approach works in the Japan region and does not require Defender for Cloud or any separate plan standard Log Analytics is sufficient.

    However, if you need abuse monitoring with richer insights and human review capabilities, that is a separate feature available under Microsoft's abuse monitoring program and may require specific tier eligibility. For most content filter logging needs, the diagnostic settings approach above is fully supported.

    As a best practice going forward, also consider capturing the content_filter_result directly in your application code from the API response this gives you real-time visibility into every blocked request without depending solely on log queries.

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

    Best Regards,

    Jerald Felix.

    Was this answer helpful?


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.