Azure AI Foundry Security: What Entra ID, Private Endpoints, and RBAC Cover

An Azure AI Foundry deployment leans on three separate controls that get discussed as one "is Foundry secure" question more often than they should. Microsoft Entra ID authenticates the caller. Private endpoints and managed virtual networks isolate the network path. RBAC roles govern who can manage or use the Foundry resource itself. Each one does its job. None of them evaluates a live request against the specific end user behind it and the data classification of what they just typed.

I want to map what each control secures, then the request-level question that sits outside all three.

TL;DR

• Microsoft Entra ID authenticates the calling application or managed identity to Foundry, and access also requires the request to originate from an allowed network path.
• Private endpoints and managed virtual networks isolate Foundry's network path so traffic must come from inside an approved VNet, blocking public internet access when configured.
• RBAC roles (Foundry User, Foundry Owner, Foundry Account Owner, Foundry Project Manager, renamed from their Azure AI equivalents) govern who can manage or use Foundry resources, not what a specific request may contain.
• None of the three evaluates a specific authenticated end user's request against a live policy before it reaches the model.

Entra ID authenticates the caller, not the end user behind it

Every application reaching a Foundry resource authenticates through Microsoft Entra ID, using a workload identity, a managed identity, or an API key. That is solid, standards-based authentication of the calling application. In a multi-tenant deployment, one application typically holds one managed identity and serves many end users through its own separate sign-in flow, which means Entra ID's authentication decision at the Foundry boundary answers "which application is this" and not "which of that application's users triggered this specific call."

Microsoft's own documentation notes a specific enforcement detail worth knowing: access fails if the request does not originate from an allowed network path, even when the caller signs in with a valid Entra ID account. Authentication and network path are both enforced, and both operate above the level of an individual end user's request.

Private endpoints isolate the path, not the payload

Network isolation for Foundry works by adding a private endpoint to the Foundry account and setting public network access to disabled, so traffic has to originate from inside the VNet or a peered VNet. A managed virtual network extends that isolation to the Azure resources an agent uses, including Azure Storage, Cosmos DB, and Azure AI Search.

That closes off public internet exposure, which is a real security improvement. It says nothing about whether the traffic that does arrive, over that private and correctly isolated path, is a request the specific caller should be permitted to make. A misconfigured internal application or an over-permissioned service sends its request over the same private network path as a correctly scoped one.

RBAC governs resource management, not request content

Foundry's RBAC roles determine who can create, configure, or use a Foundry project and its connected resources. Creating a private endpoint connection requires Contributor or Owner on the Foundry project resource; approving a managed private endpoint requires the Azure AI Enterprise Network Connection Approver role at the correct scope. This is coarse, resource-level governance: who is allowed to touch the infrastructure.

RBAC does not evaluate the content of an individual prompt against a role's permitted data classification. A user with legitimate access to call a Foundry-hosted model through an approved application can still submit a prompt containing data their role should never expose to that model, and RBAC has no mechanism to catch it, because RBAC's unit of control is the resource, not the request.

The layer none of the three covers

Stack Entra ID, private endpoints, and RBAC and the result is a well-authenticated, network-isolated, access-governed Foundry deployment. What is still missing is a live decision on the actual request: this authenticated end user, this data classification, this model, this policy, evaluated before the prompt reaches the model. Why AI security must be inline makes the general case for why that decision has to happen before the request completes, not afterward in a log review. The post-authentication gap names the specific shape of the problem: authentication is solved, request-level authorization on behalf of a specific person is not.

DeepInspect

This is the problem DeepInspect was built to solve. DeepInspect sits inline on the HTTP path in front of Azure AI Foundry, or any other HTTP-based model endpoint an organization uses, and evaluates the identity context the calling application supplies for each request against per-role and per-route policy before the prompt reaches the model. The resulting decision, permit, redact, or deny, is written to a signed, tamper-evident audit record tied to the actual end user, independent of the Foundry resource's own configuration.

Entra ID, private endpoints, and RBAC keep doing exactly what they do today. DeepInspect adds the request-level decision that sits below all three: not who can reach the resource, but what a specific caller may send to it right now.

Book a demo today.