Benefits of Private Networking for Foundry Agent Service

Your security team has one question about the agent you just demoed: where does the traffic go? Foundry Agent Service private networking is Microsoft's answer. It's called Standard Setup with private networking, and it keeps agent traffic and agent data inside your network and your tenant. Here are five concrete things you get, and when the price is too high.

No public egress, and public access off by default

Microsoft's private networking guide says the setup gives you no public egress, without needing trusted service bypass. Accounts and projects ship with public network access disabled, covering REST and WebSocket traffic.

The GA announcement aims this at enterprises whose data classification rules forbid sending query content or retrieved documents outside their environment.

Agent compute runs in your VNet

This is the VNet injection part. You provide a subnet delegated to Microsoft.App/environments, and agents reach your private resources over private endpoints. Because the subnet is yours, your NSGs, route tables, peering and Azure Firewall rules apply to it. If a firewall sits in the path, make sure it isn't doing TLS inspection.

Agent data stays in your tenant

Standard setup makes you bring your own resources:

| Resource | What it holds | | --- | --- | | Azure Storage | Files uploaded by developers and end users | | Azure AI Search | Vector stores the agent creates | | Azure Cosmos DB | Messages, conversation history, agent metadata |

The standard agent setup docs say all data the service processes is stored at rest in these three, so your retention and audit tooling can point straight at them.

The Bicep sample also disables Storage shared key access and Cosmos DB local auth, so agents use managed identities, not keys. One catch: Foundry connects to AI Search with Entra auth, so a key-only search service returns HTTP 403. The README's fix:

az search service update \
  --name <search-name> \
  --resource-group <search-rg> \
  --subscription <search-sub> \
  --auth-options aadOrApiKey \
  --aad-auth-failure-mode http401WithBearerChallenge

Bicep and Terraform samples make it repeatable

The Bicep sample (template 15) deploys the Foundry account and project, a model, Search, Storage, Cosmos DB, Application Insights, private endpoints and the DNS zones. To reuse your platform team's network, point it at the existing VNet:

using './main.bicep'

param location = '<region>'
param existingVnetResourceId = '/subscriptions/<subscription-id>/resourceGroups/<network-rg>/providers/Microsoft.Network/virtualNetworks/<vnet-name>'
param agentSubnetName = 'agent-subnet'
param peSubnetName = 'pe-subnet'
param reuseExistingSubnets = true

reuseExistingSubnets leaves your NSG, route table and policy settings alone on redeploy. Register Microsoft.App and Microsoft.ContainerService first, because the README calls both mandatory:

az provider register --namespace 'Microsoft.App'
az provider register --namespace 'Microsoft.ContainerService'

az group create --name <resource-group> --location <region>
az deployment group create \
  --resource-group <resource-group> \
  --template-file main.bicep \
  --parameters main.bicepparam

The Terraform sample (15b) expects the VNet, a delegated agent subnet and the private DNS zones to exist already, and needs Terraform 1.11.4 or later with the AzureRm and AzApi providers.

resource_group_name_resources = "<resources-rg>"
resource_group_name_dns       = "<dns-rg>"
subnet_id_agent               = "/subscriptions/<subscription-id>/resourceGroups/<network-rg>/providers/Microsoft.Network/virtualNetworks/<vnet-name>/subnets/<agent-subnet>"
subnet_id_private_endpoint    = "/subscriptions/<subscription-id>/resourceGroups/<network-rg>/providers/Microsoft.Network/virtualNetworks/<vnet-name>/subnets/<pe-subnet>"
subscription_id_resources     = "<resources-subscription-id>"
subscription_id_infra         = "<dns-subscription-id>"
location                      = "<same-region-as-vnet>"

You can prove the isolation to a security review

The docs include a verification list: the agent subnet shows delegation to Microsoft.App/environments, and public network access reads Disabled on Foundry, Search, Storage and Cosmos DB. From inside the VNet, confirm each endpoint resolves privately:

nslookup <your-resource>.services.ai.azure.com
nslookup <your-search>.search.windows.net
nslookup <your-cosmos>.documents.azure.com
nslookup <your-storage>.blob.core.windows.net

Every name should return a private IP. Then create and run an agent from inside the network, and you have evidence instead of assurances.

When Foundry Agent Service private networking isn't worth it

• Subnet sizing. Use a /24 for the agent subnet; the networking deep dive says not to use /27 in production even though the portal accepts it. A /24 maps to roughly 250 concurrent hosted agent sessions at best, so stay under 80% utilization. The portal doesn't show IP usage for delegated subnets; exhaustion shows up as 5xx errors from the data proxy or, on hosted agents, HTTP 429 subnet_exhausted.
• One subnet each. Resources can share a VNet, but not an agent subnet.
• DNS work. Foundry alone needs three private DNS zones, plus zones for Search, Cosmos DB and Blob, and the portal doesn't create private endpoints for those three. Broken Cosmos DB resolution looks like Timeout of 60000ms exceeded on the Agents pages.
• Tool gaps. Code Interpreter only works without file uploads or downloads, and Blob Storage files with File Search aren't supported. Both sample READMEs say tools behind the VNet (MCP, OpenAPI, Azure Functions, A2A) aren't covered by those templates. The GA post says private networking reaches MCP servers, so confirm your exact tool before promising it.
• Plumbing. Cosmos DB needs at least 3000 RU/s, and you reach the private project through VPN, ExpressRoute or a Bastion jump box.

For a prototype with no sensitive data, the basic setup with Microsoft-managed resources is faster and nobody will miss the DNS zones.

If your agents touch data your security team cares about, private networking turns 'trust us' into resources you own, a subnet you control and checks you can run yourself.