Disabling public network access (PNA) on a Microsoft Foundry resource seals it off from everything that isn't coming through an approved private endpoint. That is the point — but it also blocks Azure's own platform services that legitimately need to call the resource on your behalf. A retrieval pipeline where Azure AI Search enriches an index, or an Azure Machine Learning job that calls a deployed model, arrives from Microsoft-operated infrastructure, not from inside your VNet, so the network rules reject it.
Azure's answer is the trusted services bypass: a documented mechanism that lets a short list of Microsoft services through the network perimeter — provided they can prove who they are.
Which services qualify
Microsoft's Foundry networking documentation names the trusted services that can bypass network rules on a Foundry resource: Foundry Tools (the Microsoft.CognitiveServices platform itself), Azure AI Search, and Azure Machine Learning. This is a fixed, Microsoft-curated list — you cannot nominate your own services into it. Anything not on the list reaches a locked-down resource the ordinary ways: through a private endpoint in your VNet, or from an allowlisted IP if you run in the "selected IP addresses" mode instead.
How the bypass actually authenticates
The crucial design decision is that the bypass is not a network hole. A trusted service does not get waved through anonymously; it must present a managed identity — an Entra ID identity that Azure operates for the service instance, with no credentials for you to store or rotate — and that identity must hold a role assignment on the Foundry resource. Two checks, both mandatory:
- Service check: the caller is one of the trusted services, so the network rules step aside.
- Identity check: the service's managed identity carries an RBAC role on your resource, so authorization still applies per instance.
This matters for your threat model. "Azure AI Search is trusted" does not mean every AI Search instance in every Azure tenant can reach your Foundry resource — only the specific instances whose managed identities you have explicitly granted a role. The perimeter softens for a category of services; access is still granted one identity at a time, and it shows up in your role assignments where reviews and audits can see it.
Setting it up, in outline
The recipe has three parts. First, enable the managed identity on the calling service (for example, the system-assigned identity on your AI Search instance). Second, assign that identity an appropriate role on the Foundry resource — the same role logic as human callers, covered in our Foundry RBAC role guide; least privilege applies to robots too. Third, ensure the calling service authenticates with its managed identity rather than an API key: key-based calls from a trusted service are still network-blocked, because the bypass is keyed to identity, not to source. Exact toggles vary by service and portal blade, so follow the current official documentation for the service you are connecting.
Where it fits in the lockdown
Trusted-services bypass is the third leg of a fully private Foundry deployment: private endpoints handle your workloads (see how the DNS routing works), the PNA setting closes the public door (see the three PNA modes), and the bypass readmits the handful of Azure platform services your architecture depends on — with identity checks intact. Note that Standard agent setups may also involve private endpoints to adjacent services like Azure AI Search itself; lock down the whole chain, not just the Foundry resource.