Do Azure content filters detect sensitive business data?

They detect harm categories and jailbreak patterns, which is what they are built for. A prompt containing a customer list, an unreleased financial figure or a block of proprietary source code contains nothing harmful under those taxonomies and passes the filter cleanly. Detecting that content requires classifiers written against your organization's data taxonomy, which is a separate capability. Both belong in a deployment, and a security review that checks the filter configuration and stops there has verified the safety control while leaving the data-protection question unasked.

Do Prompt Shields cover indirect prompt injection?

Prompt Shields is designed to detect injected instructions in user input and in documents the model processes, which addresses a meaningful part of that attack class. Treat it as a detection layer rather than a complete answer, for the same reason model guardrails are not a complete answer: it is a classifier making a probabilistic judgement about text, and adversaries iterate against classifiers. The durable control pairs detection with authorization on what the model may do next, so a successful injection reaches a permission boundary rather than an open tool.

How do we handle deployment sprawl across projects?

Start with an enumeration across every subscription rather than every project, because the deployments that matter are usually the ones nobody remembers creating. For each, record the filter configuration, the diagnostic settings, the principals with call access and whether the workload is still live. Then decide which endpoints applications are permitted to call directly and which must route through an enforcement point, and enforce that with network policy rather than documentation. Sprawl is a governance problem before it is a security problem, and the enumeration is what converts it into something actionable.

Does routing through a gateway break managed identity?

No, and the pattern is worth getting right. The application continues to authenticate with its managed identity or Entra token, and the enforcement layer forwards the credential to the Azure endpoint. What changes is that the request also carries the originating user's identity as an explicit assertion, so policy can be written per person or per role while the platform-level authentication stays as Azure expects it. The two identities answer different questions: one authenticates the workload to Azure, the other attributes the prompt to a human.

Is a private endpoint sufficient for regulated data?

A private endpoint keeps traffic off the public internet and is worth configuring wherever it applies. It does not evaluate what is in the request. For regulated data the obligations are typically about what was disclosed, to whom, under which authorization, with what evidence, and a private network path answers none of those. The most common misreading in a security review is presenting a private-endpoint architecture as a data-protection control, when it is a network-exposure control that happens to sit near the same diagram.

How does this compare with governing a single provider's API?

The classification work is the same and the inventory work is larger. A single-provider deployment has one endpoint, one key rotation schedule and one console. A Foundry estate has a deployment per model per project per subscription, each with independent configuration, and the count grows every time someone evaluates a new model. That makes a single enforcement boundary more valuable rather than less, since the alternative is maintaining consistent policy across a set of consoles that expands faster than the security team reviews it. The general practice is covered in AI DLP.

← Blog

August 14, 2026

Azure AI Foundry DLP: Content Filters Answer a Different Question Than Data Classification

Azure AI Foundry content filters evaluate harm categories and jailbreak attempts. Data loss prevention asks whether the prompt contains customer records that should never have left the tenant. Those are different questions with different classifiers, and conflating them is the most common gap in a Foundry security review. This piece walks the per-deployment endpoint surface, the diagnostic-settings problem across a multi-model project, and where prompt classification and per-request authorization belong.

ByParminder Singh· Founder & CEO, DeepInspect Inc.

AI Security Solutionsai-securityllm-securitydata-loss-preventiondlpcloud-securitypolicy-enforcement

Azure AI Foundry DLP: Content Filters Answer a Different Question Than Data Classification

Azure AI Foundry content filters evaluate whether a prompt or completion contains hate, violence, sexual or self-harm content, and whether the input looks like a jailbreak attempt. They do that job well and they are on by default at a configured severity.

Data loss prevention asks something else entirely: whether the prompt contains twelve customer account numbers that should never have left the tenant. A content filter reading that prompt finds nothing harmful, because nothing in it is harmful, only confidential.

Those two questions get conflated in Foundry security reviews more than any other pair, and the conflation produces deployments that pass a safety review while having no data-protection control at all. I want to separate them, then walk through where an Azure AI Foundry DLP control actually sits.

The two classifier families

Content safety classifiers are trained on harm taxonomies. The categories are universal, the thresholds are configurable, and the same policy is sensible for almost any organization. Prompt Shields extends this to detecting injected instructions in user input and in documents the model reads, which is a genuinely useful control against indirect prompt injection.

Data classification runs on a taxonomy your organization wrote. Customer PII, PHI where healthcare data is in scope, NPI and pre-announcement material for financial services, CUI for federal contractors, source code with IP indicators, contract terms, credentials. Nothing about that list is universal, and no vendor default can supply it, because the policy is specific to what your business holds and what its regulators require.

Both families of classifier should run. A deployment with content filters and no data classification is protected against a model producing something offensive and unprotected against an employee pasting a customer database extract into a prompt. The practice of classifying inside the context window rather than at the document level is covered in prompt-level DLP.

The surface: one project, many endpoints

Foundry's model catalog is the feature that creates the governance problem, and it does so by being useful.

Projects accumulate deployments. There is an Azure OpenAI deployment for the production assistant, a second one at a different capacity tier for batch work, then a serverless deployment of a third-party model the data science team wanted to evaluate, and a managed-compute deployment of an open-weights model behind the research workload. Each is an HTTPS endpoint, and each carries its own configuration for filters, its own diagnostic settings, and its own set of principals with access.

Azure OpenAI deployments present as <resource>.openai.azure.com with the deployment name in the path, while Foundry's model inference surface presents as <project>.services.ai.azure.com. Both take an api-version query parameter, and both are ordinary HTTPS endpoints.

A recognizable shape for this problem: a project with nine deployments where two have diagnostic settings configured and the other seven were stood up for an evaluation that quietly became production. Every one of them is reachable by whichever principals hold the keys, and the newest ones are the least governed.

The inventory exercise is unglamorous and it is the first real control: enumerate every deployment across every project and every subscription, and for each one record its filter configuration, its diagnostic settings, and who can call it.

What Azure-native controls give you

The controls here are stronger than in many managed assistant products, and it is worth saying so plainly.

Because the endpoints run inside your subscription, so private endpoints keep traffic off the public internet, network security groups constrain reachability, and managed identity removes long-lived keys from application configuration. Entra ID governs which principal may call which deployment, and role assignments can be scoped per resource. Diagnostic settings can route request metadata to Log Analytics, Event Hubs or storage.

Each of those is real. What none of them evaluate is the content of the prompt against your data taxonomy. Entra ID decides who may call the endpoint, private endpoints determine the network path, and what gets recorded about the call comes down to diagnostic settings. The gap between them is the payload. Related coverage of the platform controls sits in Azure OpenAI security.

Where the enforcement point belongs

Because Foundry deployments are ordinary HTTPS endpoints, routing application traffic through an enforcement layer before it reaches them is straightforward, and the application change is a base URL.

Constructing the AzureOpenAI client with azure_endpoint set to an internal gateway host keeps the Entra token provider and the api-version exactly as they were, and adds one default header, X-Originating-Identity, carrying the acting user's UPN.

That collapses three requirements into one location: prompt content is classified against the organization's taxonomy, policy is evaluated against the identity that originated the request rather than the application's managed identity, and the record is written at the same point. It also covers the endpoints outside Azure, which is the part that matters for organizations whose estate spans providers.

The identity header is the detail that decides whether any of it is useful for attribution. A managed identity is the correct credential for the application to hold and the wrong principal to write policy against, because every user of that application shares it. Propagating the originating user is upstream application work that no downstream control can substitute for, and it is covered in the post-authentication gap for AI agents.

The record

The record needs to survive a question asked six weeks later by someone who was not in the room.

decision_id: d-2f80b6, recorded at 2026-08-13T14:22:09Z
originating_identity: a.lindqvist@example.com
deployment and endpoint: prod-assistant-gpt4o at eastus.openai.azure.com
classifications: customer-pii
policy: tenant-egress-v6
outcome: block, because customer PII was heading to external inference without an approved purpose

Diagnostic settings record that a call occurred against a deployment. A per-decision record records what the call contained by classification, which identity sent it, which policy evaluated it and what happened. The second is what answers a regulator; the first is what tells you the service is running.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline between your users or agents and the model endpoints they call, as a stateless proxy. Prompt content is classified against your data taxonomy, each request is evaluated against the identity the application propagates, and a signed per-decision record is written before the request reaches the Foundry endpoint. Enforcement is per request and fails closed.

The scope is worth stating. DeepInspect does not replace content filters or Prompt Shields, which handle harm categories and injection detection inside the Azure path and should stay configured. It does not manage your private endpoints, your Entra role assignments or your diagnostic settings. What it adds is a single classification and authorization point that covers every Foundry deployment plus every model endpoint outside Azure, so the policy stops being per-console.

If your Foundry projects have more deployments than governed deployments, the inventory above is the place to start. Book a demo today.

Frequently asked questions

Do Azure content filters detect sensitive business data?: They detect harm categories and jailbreak patterns, which is what they are built for. A prompt containing a customer list, an unreleased financial figure or a block of proprietary source code contains nothing harmful under those taxonomies and passes the filter cleanly. Detecting that content requires classifiers written against your organization's data taxonomy, which is a separate capability. Both belong in a deployment, and a security review that checks the filter configuration and stops there has verified the safety control while leaving the data-protection question unasked.
Do Prompt Shields cover indirect prompt injection?: Prompt Shields is designed to detect injected instructions in user input and in documents the model processes, which addresses a meaningful part of that attack class. Treat it as a detection layer rather than a complete answer, for the same reason model guardrails are not a complete answer: it is a classifier making a probabilistic judgement about text, and adversaries iterate against classifiers. The durable control pairs detection with authorization on what the model may do next, so a successful injection reaches a permission boundary rather than an open tool.
How do we handle deployment sprawl across projects?: Start with an enumeration across every subscription rather than every project, because the deployments that matter are usually the ones nobody remembers creating. For each, record the filter configuration, the diagnostic settings, the principals with call access and whether the workload is still live. Then decide which endpoints applications are permitted to call directly and which must route through an enforcement point, and enforce that with network policy rather than documentation. Sprawl is a governance problem before it is a security problem, and the enumeration is what converts it into something actionable.
Does routing through a gateway break managed identity?: No, and the pattern is worth getting right. The application continues to authenticate with its managed identity or Entra token, and the enforcement layer forwards the credential to the Azure endpoint. What changes is that the request also carries the originating user's identity as an explicit assertion, so policy can be written per person or per role while the platform-level authentication stays as Azure expects it. The two identities answer different questions: one authenticates the workload to Azure, the other attributes the prompt to a human.
Is a private endpoint sufficient for regulated data?: A private endpoint keeps traffic off the public internet and is worth configuring wherever it applies. It does not evaluate what is in the request. For regulated data the obligations are typically about what was disclosed, to whom, under which authorization, with what evidence, and a private network path answers none of those. The most common misreading in a security review is presenting a private-endpoint architecture as a data-protection control, when it is a network-exposure control that happens to sit near the same diagram.
How does this compare with governing a single provider's API?: The classification work is the same and the inventory work is larger. A single-provider deployment has one endpoint, one key rotation schedule and one console. A Foundry estate has a deployment per model per project per subscription, each with independent configuration, and the count grows every time someone evaluates a new model. That makes a single enforcement boundary more valuable rather than less, since the alternative is maintaining consistent policy across a set of consoles that expands faster than the security team reviews it. The general practice is covered in AI DLP.

← All posts