Foundry Agent Service — Cannot access BYO resources with publicNetworkAccess: Disabled (cross-region standard agent setup)

Hello @Shibily Abdul Shukoor

Thank you for the detailed repro steps and for documenting the validations you've already completed.

Based on the information provided, your configuration aligns with many of the documented requirements for Foundry Agent Service private networking. The fact that:

• Private Endpoints are provisioned successfully.

Private DNS zones are linked.

DNS resolves to private IPs from within the Foundry VNet.

Connectivity tests from a VM in the Foundry VNet return HTTP 200.

Required RBAC permissions have been assigned.

Capability hosts show a provisioning state of Succeeded.

suggests that the issue is not a straightforward Private Endpoint, DNS, or RBAC misconfiguration.

Cross-region BYO resources – Is this supported?

According to the current Azure AI Foundry Agent Service private networking documentation, the supported topology is:

The Azure AI Foundry resource and the injected VNet must be deployed in the same region.

Other Azure resources such as Azure Storage, Azure Cosmos DB, and Azure AI Search can be deployed in different regions.

Based on that guidance, your deployment pattern:

Foundry Project: Sweden Central

BYO VNet: Sweden Central

Storage Account: West Europe

Cosmos DB: West Europe

AI Search: West Europe

is expected to be a supported configuration, provided private networking, DNS resolution, authentication, and routing are configured correctly.

Why the error occurs when Public Network Access is disabled

The key error is:

"Request is denied as the source is not allowed by applicable rules. The service is set 'publicNetworkAccess: Disabled'."

Although you've validated connectivity from a VM inside the Foundry VNet, it is important to note that the Foundry Agent runtime and data proxy do not necessarily follow the exact same network path as your validation VM.

The fact that:

Everything works when Public Network Access is enabled.

Everything fails when Public Network Access is disabled.

suggests that the Agent runtime is either:

• Not reaching the target resources through the expected private endpoint path, or
• Encountering a networking limitation specific to the Agent Service runtime.

Additional areas to validate

1. Private DNS and name resolution

The Agent Service troubleshooting guidance specifically calls out DNS configuration as a common cause of private endpoint access failures.

Please verify:

All required Private DNS Zones are linked to the injected VNet.

Any custom DNS infrastructure or conditional forwarders ultimately forward Azure private endpoint requests to Azure DNS (168.63.129.16).

Name resolution for the exact resource FQDNs returns the private endpoint IP addresses.

While you've already validated this from a VM, the goal is to ensure the runtime path used by the Agent Service resolves resources identically.

2. Agent creation timing and topology

The Agent Service self-help documentation notes that modifying networking after agent deployment can lead to unsupported scenarios.

Please confirm:

Private Endpoints existed before the Agent Service and capability hosts were provisioned.

DNS links and network configuration were already in place during initial setup.

The agent was not created prior to network injection or private endpoint configuration.

Even with correct networking today, agents created before private networking was fully configured may continue to experience access failures.

3. Authentication and RBAC

Your RBAC assignments appear appropriate based on the roles listed.

However, please verify that:

• The Agent Service Managed Identity is the identity actually being used for Storage, Cosmos DB, and AI Search access.
• Permissions are assigned directly to the runtime identity rather than only to user accounts.
• AI Search authentication mode remains aligned with the identity configuration.

Regarding the apparent inconsistency between the documentation and the Terraform sample:

The current limitations documentation distinguishes between:

Foundry resource + VNet region requirements

BYO resource placement

Specifically, it states that the Foundry resource and VNet must be co-located, while Storage, Cosmos DB, and AI Search may reside in different regions.

The sample repository wording appears broader and can be interpreted as requiring all resources to be in the same region.

Please refer this

Foundry troubleshooting guide (private networking): https://learn.microsoft.com/azure/foundry/agents/how-to/virtual-networks#troubleshooting-guide

“Set up private networking for Foundry Agent Service” (same Learn page content surfaced in the provided excerpt): https://learn.microsoft.com/azure/foundry/agents/how-to/virtual-networks?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#limitations

Repository sample referenced by the customer (for the conflicting wording): https://github.com/microsoft-foundry/foundry-samples (repo path as provided in the customer text)

I Hope this helps. Do let me know if you have any further queries.

Thank you!

Hello Shibily Abdul Shukoor,

Welcome to Microsoft Q&A,

Cross-region BYO resources are officially supported. The official limitations page is clear:

"The Foundry resource must be deployed in the same region as the virtual network (VNet). Other Azure resources, such as Azure Cosmos DB, Azure AI Search, and Azure Storage, can be deployed in different regions."

The Terraform sample comment ("All Foundry workspace resources should be in the same region as the VNet") is outdated and contradicts the official docs. Your Sweden Central Foundry + West Europe BYO resources architecture is a valid configuration.

Why DNS resolves from a VM, but the agent runtime still gets "publicNetworkAccess: Disabled"

This is the key issue. Understanding the data proxy architecture explains the gap.

The Foundry Agent Service uses a single-tenant data proxy (running as Azure Container Apps in your delegated subnet) that handles all outbound calls to your BYO resources. The data proxy is what generates the actual requests to Storage, Cosmos DB, and AI Search, not your agent code directly.

The error publicNetworkAccess: Disabled means the request IS reaching your West Europe resources, but it is arriving from a public IP rather than your private endpoint. Your VM resolves correctly because it uses the VNet's DNS (168.63.129.16). But the Container Apps environment hosting the data proxy may not be following the same DNS path if your VNet has a custom DNS server configured.

Check this first: VNet DNS settings

In the Azure Portal, navigate to your Sweden Central VNet > DNS servers. If you have a custom DNS server set (not the default "Azure-provided"):

• That custom DNS server must have conditional forwarders configured for every privatelink.* zone pointing to the Azure DNS virtual server IP: 168.63.129.16
• Required zones for your setup:
  • privatelink.blob.core.windows.net
    • privatelink.documents.azure.com
      • privatelink.search.windows.net

If conditional forwarders are missing, the data proxy resolves to the public FQDN instead of the private IP, which is exactly what produces the "publicNetworkAccess: Disabled" response.

Additional checks if DNS is correct

1. Verify the Private DNS Zones have A records for your cross-region endpoints. Go to each Private DNS Zone linked to your Foundry VNet and confirm there is an A record for your specific storage/cosmos/search resource names. A missing A record falls back to public DNS.
2. Check that the private endpoint subnet has no NSG blocking traffic from the delegated subnet. The data proxy (delegated subnet) must be able to reach the private endpoint NICs (private endpoint subnet). Add an inbound allow rule if needed.
3. Confirm the capability host is referencing the correct connection names for all 3 resources. A mismatch between the connection name in the capability host and the project connection can cause the data proxy to resolve incorrectly.
4. Cross-region private endpoint A record registration. When creating private endpoints for West Europe resources in a Sweden Central VNet, verify the auto-registration correctly wrote the A record into the Private DNS Zone. In some cases with cross-region private endpoints, you may need to manually add the A record to the zone.

bash

# Verify DNS resolution from inside the VNet
nslookup <storageaccount>.blob.core.windows.net 168.63.129.16
nslookup <cosmosaccount>.documents.azure.com 168.63.129.16
nslookup <searchaccount>.search.windows.net 168.63.129.16

All three should return a private IP (10.x, 172.16-31.x, or 192.168.x), not a public Azure IP.

Please Upvote and accept the answer if it helps!!