Network isolation — private endpoints and VNet injection

Network isolation means putting your AI platform somewhere the public internet cannot reach it. The thing to hold onto is that traffic has two directions, and they are controlled by two entirely different mechanisms. Questions here usually turn on knowing which one applies.

Inbound — who can reach you

This is governed by a public network access setting on the resource.

• Set it to disabled, and only a private endpoint can reach the service. A private endpoint is a network interface with a private address inside your own virtual network.
• Set it to enabled from selected IP addresses, and you get a firewall list instead.

Two details worth remembering: the private endpoint targets the Foundry account, and only an endpoint in the Approved state actually passes traffic. An endpoint that exists but is still pending will look configured and carry nothing.

Outbound — where your agent can reach

This is a different mechanism entirely: virtual network injection. Rather than filtering what comes in, it places the agent client inside your own subnet so its outbound traffic originates there.

Three constraints that come up as questions:

• The subnet must be delegated to Microsoft.App/environments.
• It must be /27 or larger. A smaller subnet does not have room.
• You cannot add or change this later. Getting it wrong means redeploying, not reconfiguring.

That last one is the sort of thing worth catching at design time in real work, not just on an exam.

Bring your own storage

In the standard setup you supply three services yourself: Azure Storage, Azure AI Search and Azure Cosmos DB. The reason is straightforward — it keeps all agent data inside your own tenant rather than a Microsoft-managed one.

The catch: their private endpoints are not created for you. You add them. It is easy to isolate the Foundry account carefully and leave the three data stores reachable, which defeats the exercise.

Why DNS is where this usually breaks

Almost every private endpoint problem is a name resolution problem, and it presents identically every time.

When you create a private endpoint, Azure rewrites the service's canonical name into a privatelink subdomain. The same hostname is then meant to resolve to a private address inside the virtual network and a public one outside it.

If you run your own DNS, it has to cooperate: either delegate the privatelink zone or forward to Azure's resolver at 168.63.129.16. If it does not, the symptom is unmistakable — nslookup from inside the network returns a public address. The endpoint is fine. The name is pointing the wrong way.

Which agent tools survive isolation

Not all of them, and this is the part with real governance consequences.

Work through your subnet: private Model Context Protocol servers, AI Search, OpenAPI tools, Azure Functions, and agent-to-agent calls.

Still go to public endpoints: Bing, web search, and SharePoint grounding.

Not supported at all behind a virtual network: File Search, Logic Apps, Browser Automation and Image Generation. Traces have no virtual network support either.

The two silent failures

Both of these fail quietly, which is what makes them dangerous.

First: Bing, web search and SharePoint grounding still exit to public endpoints even in a network-isolated project. When a requirement says data must never leave the boundary, that is the answer — those groundings break it. Nothing errors; the traffic simply leaves.

Second: an indexer that has to cross private endpoints needs executionEnvironment: "Private". Without it, it does not fail loudly. It fails silently and leaves you with an empty index — which you may not notice until someone asks why the assistant cannot find anything.