10.3 Foundry Network Security and Private Networking

Foundry Network Security and Private Networking

Quick Answer: Disable public network access, attach a private endpoint to the Foundry account, and link private DNS zones (privatelink.services.ai.azure.com, privatelink.openai.azure.com, privatelink.cognitiveservices.azure.com). For agents, inject the Agent client into a BYO subnet delegated to Microsoft.App/environments (/27 or larger) or use a managed virtual network. Private endpoints to Search, Storage, and Cosmos DB are not created for you. Removing a private endpoint does not enable public access.

Domain 3's third platform bullet is implement network security and private networking configurations. Chapter 4 covered Azure Machine Learning isolation (workspace private endpoint plus managed outbound). Foundry reuses Private Link ideas but adds Agent Service virtual-network injection and a different DNS suffix list.

Three isolation surfaces

Microsoft asks you to plan isolation in three places:

1. Inbound to the Foundry resource — data scientists, CI, and apps reaching the account and projects.
2. Outbound from Foundry PaaS — the account talking to Storage, Key Vault, container registry, monitoring, and Search over Private Link.
3. Outbound from the Agent client — the injected Agent runtime reaching private data sources and Azure PaaS without traversing the public internet.

Inbound is the public network access (PNA) flag plus optional private endpoints. PNA values:

• Disabled — only private endpoints (and the trusted-services exception if you enable it).
• Enabled from selected IP addresses — named IPs and virtual networks, a middle setting between public and private.
• All networks — the public endpoint is back. Existing private endpoints keep working; you have added a public path, not removed the private one.

Create the private endpoint while creating the resource (Networking tab → Disabled → Add private endpoint) or later under Resource Management → Networking → Private endpoint connections. In the portal the target is labeled account — select the Foundry resource. The endpoint must sit in the same region as the virtual network. You need Network Contributor on the virtual network and Contributor or Owner on the Foundry resource to approve the connection. Without approval the connection stays Pending and carries no traffic. Only Approved private endpoints send traffic.

Trap: deleting the private endpoint to "open the firewall." Removal disconnects that virtual network; PNA stays Disabled. To allow the public internet you must set All networks (Firewalls and virtual networks tab) and Save.

DNS: same connection string, different IP

Clients inside and outside the virtual network use the same Foundry connection string. Azure updates the public CNAME to a privatelink alias. Inside the linked virtual network, that name resolves to the private IP. Outside, it still resolves to the public endpoint (which is blocked if PNA is Disabled).

A Foundry resource can expose three public suffixes. Configure a private DNS zone for each suffix you actually call:

Link those zones to the virtual network. Custom DNS servers must forward the privatelink subdomains to Azure DNS (168.63.129.16) or host matching A records. Validate from a jump box: nslookup <foundry-hostname> must return the private IP, then Test-NetConnection <private-ip> -Port 443.

If DNS still returns a public IP, the zone is missing or not linked — that is the usual "Private Link is Approved but the SDK times out or 403s" ticket.

On-premises clients reach the private endpoint through VPN Gateway (point-to-site or site-to-site), ExpressRoute, or an Azure Bastion jump VM on the virtual network. Do not use the 172.17.0.0/16 range; Docker bridge networking reserves it.

Trusted Azure services

When PNA is restricted, you can still allow a documented subset of Azure services to reach Foundry if their managed identity has RBAC. Microsoft lists:

• Foundry Tools — Microsoft.CognitiveServices
• Azure AI Search — Microsoft.Search
• Azure Machine Learning — Microsoft.MachineLearningServices

Create the exception with the REST API or Azure portal network rules. This is not "any Azure service." It is also not a substitute for a private endpoint when the caller is your virtual network.

Agent Service: managed VNet versus BYO VNet

PaaS Private Link is not enough once you run prompt agents, hosted agents, or evaluations and your security team wants outbound isolation. Foundry then injects the Agent client into a subnet.

Portal create path: Storage tab (Basic = Microsoft-managed agent data; Standard = BYO Storage, Azure AI Search, Cosmos DB so data stays in your tenant) → Network tab → PNA Disabled plus inbound private endpoint → Virtual network injection dropdown → pick the delegated subnet.

Hard limits from the 2026-08-14 networking article:

• You cannot change the delegated subnet later, and you cannot add outbound injection to an existing Foundry resource. Redeploy.
• Private endpoints to Search, Storage, and Cosmos DB are not auto-created. Create them on those resources yourselves.
• Standard setup is what private-network Agent deployments expect; Basic keeps agent state in Microsoft-managed multi-tenant storage.
• Some agent tools stay on the public internet even in a private Foundry (Bing Grounding, Websearch, SharePoint Grounding). Code Interpreter and Function Calling stay on the Microsoft backbone. MCP, Azure AI Search, OpenAPI, Azure Functions, and A2A can traverse your subnet. Logic Apps, Browser Automation, Computer Use, and Image Generation are not supported in network-isolated environments as of the current article. Do not over-claim tool support on the exam.
• Workflow Agents: inbound isolation yes; outbound VNet injection not currently supported.
• Hosted agents with a private Azure Container Registry (PNA disabled + private endpoint) are supported for Foundry projects created after 25 June 2026; older projects need a publicly reachable registry.

If you front the spoke with Azure Firewall, allowlist documented FQDNs such as *.identity.azure.net and login.microsoftonline.com (Agent Container Apps), *.blob.core.windows.net and settings.sdk.monitor.azure.com (evaluations and traces).

Classic hubs: one private endpoint, managed VNet only

A hub shares one managed virtual network with all hub-based projects. You create one private endpoint on the hub, not one per project. Hub workspaces do not support BYO virtual network; Microsoft's hub matrix says use the managed virtual network instead. Encryption and network flags on the hub flow down. That is a different knob set from Foundry-resource Agent injection — do not mix the two diagrams on one answer.

Exam scenario

A bank disables public network access on a new Foundry resource, approves a private endpoint, and injects Agent Service into snet-foundry-agents (/27, delegated to Microsoft.App/environments). Agents still cannot query Azure AI Search. Search PNA is also Disabled.

Create a Search private endpoint on the same virtual network, link privatelink.search.windows.net, grant the project managed identity a Search data-plane role, and use an Entra ID connection. If ingestion uses a Search indexer, set indexer executionEnvironment to Private or the indexer stays multitenant and silently fails. Do not "fix" this by enabling All networks on Foundry.

Common trap

Assuming the Foundry private endpoint also privatizes Search and Storage. Connected resources have separate governance. A second trap is changing injection after go-live — you cannot; you redeploy. A third is hub BYO VNet: hubs use managed VNets. A fourth is treating Bing Grounding as a private tool; it still uses a public endpoint, so Azure Policy may need to block it if the standard is "no public egress."