Share via

Does Azure AI Content Safety log and provide visibility into content-filtered prompts from Azure AI Foundry model deployments?

Vu Thanh Trung 20 Reputation points
2026-06-09T01:52:18.5566667+00:00

Microsoft explicitly states it does not store prompts or completions for content filtering purposes. However, I need to audit blocked prompts — specifically the raw prompt text and the filter trigger details (harm category and severity level) — for compliance review. GitHub

I have a question:

  1. The abuse monitoring system may capture flagged prompts in a secure, isolated store for Microsoft's internal moderation review. Is any part of this data accessible to the resource owner? Microsoft Community Hub

Is there a supported first-party mechanism for prompt-level audit logging of filtered content, or is an API Management gateway the only recommended approach?

Azure OpenAI in Foundry Models

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. SRILAKSHMI C 19,090 Reputation points Microsoft External Staff Moderator
    2026-06-09T11:09:02.61+00:00

    Hello @Vu Thanh Trung

    Based on the currently available documentation for Azure AI Content Safety and Azure AI Foundry, there are some important distinctions between content filtering, abuse monitoring, and customer-accessible audit logging.

    1. Can resource owners access Microsoft's abuse-monitoring data?

    Microsoft documentation indicates that:

    • Azure AI services do not store prompts and completions for the purpose of content filtering.
    • For abuse monitoring, prompts and completions that are flagged may be preserved in secure, isolated storage within the customer's Azure geography for a limited retention period (for example, up to 60 days depending on the service and configuration).

    However, the available documentation does not indicate that customers can access this internal abuse-monitoring store.

    Based on the published guidance, there is currently no documented mechanism that allows resource owners to retrieve:

    • Raw prompt text captured by Microsoft's abuse-monitoring systems
    • Raw completions captured by Microsoft's abuse-monitoring systems
    • Internal moderation review records
    • Internal abuse-monitoring decisions

    Therefore, we cannot confirm that any portion of Microsoft's internal abuse-monitoring data is exposed to customers through APIs, Azure Portal, Azure Monitor, Log Analytics, or other first-party interfaces.

    2. Is there a first-party prompt-level audit log for blocked content?

    Based on the available documentation, there does not appear to be a Microsoft-provided audit repository that exposes:

    • Original prompt text
    • Blocked completion text
    • Harm category
    • Severity level
    • Detailed filter trigger information

    as a customer-readable audit log.

    In other words, there is currently no documented first-party feature that allows customers to retrieve historical blocked prompts and associated moderation details for compliance review.

    3. What visibility is available today?

    When content is filtered or blocked, Azure AI services can provide filter-related information as part of the API response.

    Examples include:

    • finish_reason = content_filter
    • content_filter_result or similar filter metadata returned with the request

    These response fields can provide insight into moderation outcomes and should be captured by your application if auditing is required.

    However, the documentation does not guarantee that these response objects will serve as a long-term, customer-accessible audit repository.

    4. Can Azure Monitor help?

    Yes, to some extent.

    Microsoft provides monitoring capabilities through:

    • Azure Monitor
    • Azure AI Foundry Risks & Safety Monitoring
    • Diagnostic settings and monitoring dashboards

    These tools can help organizations:

    • Track content filtering activity
    • Analyze filtering trends
    • Monitor blocked requests
    • Review moderation-related metrics

    However, the available documentation does not state that these tools expose the complete raw prompt content and filter details required for compliance-grade prompt auditing.

    5. What is the recommended approach for compliance auditing?

    Based on the current documentation, the most reliable approach is to implement your own audit logging before requests reach the model.

    This typically involves:

    1. Logging the prompt at the application layer
    2. Capturing API response metadata, including:
      • finish_reason
        • content_filter_result
          • Request identifiers
            • Timestamps
            1. Storing audit records in your own compliant logging solution

    Many customers implement this through:

    • Application-level logging
    • Azure API Management
    • Middleware services
    • Custom compliance and governance pipelines

    This ensures full control over:

    • Prompt retention
    • Audit access
    • Compliance reporting
    • Governance workflows

    6. Is API Management the only supported solution?

    The documentation does not state that Azure API Management is the only supported approach.

    However, based on the currently documented capabilities:

    • There is no documented Microsoft-managed audit store exposing blocked prompts.
    • There is no documented API to retrieve Microsoft's internal abuse-monitoring records.

    As a result, if you require:

    • Raw prompt auditing
    • Historical review of blocked content
    • Compliance evidence
    • Long-term retention of moderation outcomes

    then customer-controlled logging whether through API Management, middleware, or application-level logging is the recommended and most reliable approach.

    Please refer this

    Content filter configurability (severity thresholds; prompts vs completions; approval notes) https://learn.microsoft.com/azure/ai-foundry/openai/concepts/content-filter-configurability

    Use Risks & Safety monitoring in Azure AI Foundry (preview) https://learn.microsoft.com/azure/ai-foundry/openai/how-to/risks-safety-monitor

    I Hope this helps. Do let me know if you have any further queries.

    If this answers your query, please do click Accept Answer and Yes for was this answer helpful.

    Thank you!

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-06-09T01:52:33.48+00:00

    Azure AI Content Safety (Guardrails/content filters) does not provide customer-facing logs of blocked prompts or their classifier details, and the abuse monitoring store used for Microsoft’s internal review is not exposed to resource owners.

    From the documentation:

    • Content filtering runs prompts and completions through classifier models to detect harmful content, but “no prompts or completions are stored for the purposes of content filtering” and they “are not used to train, retrain, or improve the content filtering system without your consent.”
      • This applies to Azure OpenAI in Azure AI Foundry Models and to Models sold by Azure.
    • Abuse monitoring is a separate system that:
      • Uses content classification signals (harm categories and severity) plus usage patterns to detect potential abuse.
      • May sample flagged prompts and completions for automated and/or human review.
      • States that prompts and completions used in this review “are not stored by the abuse monitoring system or used to train the AI model or other systems.”
    • For Models sold by Azure, Guardrails/content filters “occur synchronously as the service processes prompts,” and “no prompts or generated content are stored in the content classifier models.”

    The documentation also describes a capability to turn off data storage for abuse monitoring (via the ContentLogging capability flag), but this is only about whether Microsoft stores data for abuse monitoring; it does not provide any mechanism for customers to read or export that data. The only customer-visible control is verifying that logging for abuse monitoring is off (via Azure portal JSON view or az cognitiveservices account show), not accessing any logged prompts.

    The content-filter configurability section describes how to adjust filtering levels (low/medium/high, annotate-only, no filters) and how to associate content filter configurations with deployments, but it does not describe any first‑party audit log or export of filtered prompts or classifier decisions.

    Based on the provided documentation:

    1. Data captured for abuse monitoring and internal moderation review is not accessible to the resource owner.
    2. There is no documented first‑party feature that provides prompt-level audit logging of filtered content (raw prompt plus harm category and severity) back to the customer.

    Therefore, implementing logging at an integration layer (for example, an API Management gateway or other application-side logging that records prompts and the filter results returned in API responses) is the supported pattern implied by the documentation, rather than relying on a built-in audit log of filtered prompts from the service itself.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    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.