Private Networking for Azure AI Foundry

I have never seen an enterprise AI deployment fail because the model endpoint was not clever enough. I have seen several stall because the platform was reachable from the public internet, DNS was improvised, and nobody could explain where prompts, files, embeddings, and logs could flow.

Private networking for Azure AI Foundry is not a final hardening step. It is an architecture decision that shapes how teams build, debug, evaluate, and operate AI systems. If I want a serious enterprise platform, I design private access from the first landing zone conversation.

Start with the data path, not the diagram

The common mistake is to draw Azure AI Foundry as one box and then add a private endpoint to it. In practice, an AI project touches many services:

• Azure AI Foundry hub and project resources
• Azure OpenAI or model deployments in Azure AI services
• Storage accounts for data, artifacts, traces, and evaluation assets
• Azure Key Vault for secrets, keys, and connection metadata
• Azure AI Search for retrieval augmented generation indexes
• Azure Container Registry or compute dependencies in advanced scenarios
• Log Analytics, Application Insights, and monitoring pipelines

Each service has its own network controls, private endpoint behavior, and DNS requirements. A private Foundry experience is only private when the dependent resources are private as well.

The private endpoint baseline I use

My default pattern is simple: put the developer and runtime paths behind private connectivity, resolve all platform names through private DNS, and disable public network access when the operational model can support it.

For most enterprise deployments, that means private endpoints for:

• The AI hub or account surface used by Foundry
• Azure OpenAI or Azure AI services
• Storage account blob and file endpoints
• Key Vault
• Azure AI Search
• Container registry when custom environments are used

Then I link the matching private DNS zones to the spoke virtual networks that host build agents, jump hosts, private workstations, application runtimes, and evaluation pipelines.

The zones I typically plan early include:

• privatelink.openai.azure.com
• privatelink.cognitiveservices.azure.com
• privatelink.vaultcore.azure.net
• privatelink.blob.core.windows.net
• privatelink.file.core.windows.net
• privatelink.search.windows.net
• privatelink.azurecr.io

The exact set varies by service version and region, but the principle does not: DNS is part of the security boundary. If DNS still resolves to public endpoints, the architecture is not finished.

Managed virtual networks are useful, not magic

Azure AI Foundry managed virtual network options help reduce the burden of wiring every compute path manually. I like them because they make it easier to constrain outbound traffic from managed compute and agent tooling. They are especially useful when teams need notebooks, evaluation flows, prompt tooling, or managed compute without building every subnet integration from scratch.

But I do not treat managed networks as a substitute for landing zone design. I still need to answer:

• Which subscriptions and spokes are allowed to resolve private zones
• Which build agents can deploy and test projects
• Which identities can create connections
• Which outbound destinations are approved
• Which data stores can be reached by model workflows

Managed networking helps with enforcement. It does not replace ownership.

Disable public access only after testing the work paths

I aim to disable public network access on production resources, but I do it after proving the private path. Otherwise, teams lose hours to failures that look like authentication problems but are actually DNS or firewall problems.

The deployment sequence I prefer is:

1. Create the resource with least privileged identities and diagnostic settings.
2. Add private endpoints for the resource and dependent services.
3. Link private DNS zones to the correct virtual networks.
4. Validate name resolution from the actual clients and runtimes.
5. Validate application, evaluation, and deployment workflows.
6. Disable public network access.
7. Add Azure Policy assignments to prevent drift.

Here is a compact Bicep example showing the shape of the controls for a storage account used by an AI project:

param location string = resourceGroup().location
param vnetId string
param subnetId string

resource storage 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'stfoundryprod001'
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    publicNetworkAccess: 'Disabled'
    allowBlobPublicAccess: false
    minimumTlsVersion: 'TLS1_2'
    networkAcls: {
      defaultAction: 'Deny'
      bypass: 'AzureServices'
    }
  }
}

resource blobEndpoint 'Microsoft.Network/privateEndpoints@2023-11-01' = {
  name: 'pe-stfoundryprod001-blob'
  location: location
  properties: {
    subnet: {
      id: subnetId
    }
    privateLinkServiceConnections: [
      {
        name: 'blob'
        properties: {
          privateLinkServiceId: storage.id
          groupIds: [
            'blob'
          ]
        }
      }
    ]
  }
}

I would pair this with private DNS zone records, role assignments for managed identities, and policy that denies public storage accounts in the AI platform subscription.

Data exfiltration controls need layers

Private endpoints reduce exposure, but they do not automatically prevent data from leaving through approved channels. An AI workflow can still send sensitive context to a model deployment, write outputs to storage, call a tool, or index content in search.

The controls I want are layered:

• Network isolation for platform services
• Private DNS for deterministic resolution
• Managed identities instead of shared secrets
• Key Vault references for sensitive configuration
• Azure Policy to deny public access and unsupported regions
• Defender for Cloud recommendations for storage, keys, and containers
• Diagnostic logs routed to a security owned workspace
• Approved outbound destinations for agent and tool execution
• Content filtering, abuse monitoring, and evaluation gates for model use

For agentic workloads, I also add explicit tool allow lists. A private network does not help if an agent is allowed to call a broad HTTP tool with sensitive context.

What usually breaks when you go private

The first break is local developer access. A laptop on public Wi-Fi cannot reach private endpoints unless it comes through VPN, ExpressRoute, Azure Bastion, a dev box, or another controlled path. This is not a bug. It is the point. The fix is to provide a supported developer route instead of asking teams to bypass the design.

The second break is DNS split brain. One subnet resolves the private address and another resolves the public name. Build agents pass while application runtimes fail. The fix is to centralize private DNS ownership and test resolution from every execution environment.

The third break is managed identity confusion. Teams lock down Key Vault and Storage, then forget that the Foundry project identity, evaluation pipeline identity, and application runtime identity are different principals. The fix is to document each identity and assign roles such as Storage Blob Data Contributor, Key Vault Secrets User, and Search Index Data Contributor with narrow scopes.

The fourth break is deployment tooling. Some deployment agents run outside the private network. If Terraform, Bicep, or Azure CLI needs to validate data plane settings, the agent must have network access or the pipeline must be split between control plane deployment and private validation.

My production checklist

Before I call an AI Foundry environment production ready, I want evidence for these items:

• Public network access disabled where supported
• Private endpoints approved and documented
• Private DNS zones linked to all required spokes
• Name resolution tested from developer, pipeline, and runtime paths
• Managed identities mapped to least privileged data roles
• Azure Policy preventing public drift
• Logs and metrics flowing to the right workspace
• Break glass access documented and time bound
• Agent tools and outbound paths reviewed

This is not bureaucracy. It is how I avoid building a beautiful AI platform that security cannot approve and operations cannot support.

Key takeaways

• Design private networking before teams build projects on top of Azure AI Foundry.
• Treat dependent services such as Storage, Key Vault, Azure AI Search, and Azure OpenAI as part of the same security boundary.
• Private DNS is a core design artifact, not an implementation detail.
• Disable public access only after the private developer, pipeline, and runtime paths are proven.
• Pair network isolation with identity, policy, monitoring, and tool governance.