Moderate Input Text Against a Custom Blocklist in Foundry

The governing capability The scenario uses Azure AI Content Safety text moderation, which Microsoft Foundry exposes as a configurable guardrail on a project. Custom text blocklists let a project owner define domain- or tenant-specific terms that the built-in harm categories cannot catch. The blocklist named ConfidentialTerms already exists in the Foundry project, so the Python code only has to request moderation that references it; it must not recreate or upload the terms in code.

The request-object pattern In the Azure AI Content Safety Python SDK, moderation is performed by building a single request object and handing it to the client method that executes it. The request object is AnalyzeTextOptions, and it is executed with client.analyze_text(options). The client itself is constructed from the Foundry project endpoint plus a credential such as DefaultAzureCredential, so the endpoint is the only project-specific configuration the application needs.

The required arguments Three properties carry the whole answer. First, text is set to input_text, the variable holding the incoming user message. Second, blocklist_names is set to the list value ["ConfidentialTerms"] — this parameter is a list of blocklist names, not a single string, which is the trap most learners fall into. Third, halt_on_blocklist_hit is set to False, which lets the service continue the analysis and return the full result set (including the built-in category scores) instead of stopping the moment a blocked term is found. Setting it to True would short-circuit the response.

Reading the result The completed call is: build AnalyzeTextOptions with text=input_text, blocklist_names=["ConfidentialTerms"], halt_on_blocklist_hit=False, then call client.analyze_text(options). Matches are reported in the response's blocklists_match collection, alongside categories_result, and the application decides whether to block, log, or flag the message before it reaches the language model.