Network isolation for the agents in the Hub based project

[gukoff]

Do the agents in the Hub based project utilize the managed VNet of the hub?

The agents belong to the project, and the documentation suggests that projects reside within the managed VNet.

I am seeing the following error on by Hub based project UI when the linked AI Foundry aifxbvaw has public network access disabled:

This is despite the fact that I did create a private endpoint connection to this Foundry in the Hub settings:

[leestott]

In Azure AI Foundry Hub-based architecture, projects are indeed bound to the hub’s managed VNet, and by default, agents and tools execute within the project’s context, meaning they should inherit that VNet isolation including routing through any private endpoints defined in the Hub.

However, the error you're seeing (even with the Foundry’s public access disabled and a private endpoint configured) suggests a couple of things might be at play:

Please check the following
Private Endpoint not fully provisioned or approved: Even if the private endpoint shows as connected in Hub settings, double-check that the Foundry resource accepted the private endpoint connection and that DNS resolution to the Foundry's private link subdomain is working from the VNet.
Agent Execution Environment not using the expected DNS configuration: If agents are not resolving *.privatelink.openai.azure.com or equivalent domains correctly, they may fall back and fail when public access is disabled.
Project still referencing public endpoint in tool scaffold: If you’ve scaffolded tools before enabling private connectivity, the tool spec or OpenAPI connection might still point to the public endpoint. Try re-importing the Foundry into the project to refresh endpoint references.
Hub VNet not delegated correctly or missing subnet links: Make sure the hub's managed VNet has proper delegation for the AI Foundry and that the subnet used for private endpoints is accessible from the managed VNet range.

Some tips
Validate DNS resolution from the agent: Try testing with a small HTTP call tool from an agent to https://<your-foundry>.openai.azure.com — see if it resolves to the private IP.
Check the agent execution logs (if accessible) to see what endpoint it's trying to reach.
Re-import the Foundry into your project* after confirming the private endpoint and disabling public access.
Confirm that your private DNS zone for privatelink.openai.azure.com is linked to the hub’s VNet.

Useful Resources

• Configure a managed network for Azure AI Foundry hubs https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/configure-managed-network explains how hubs and projects inherit managed VNet settings and how private endpoints are used.
• Troubleshoot private endpoint connection - Azure AI Foundry https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/troubleshoot-secure-connection-project offers guidance on diagnosing connectivity issues when public access is disabled.
• Configure a private link for Azure AI Foundry https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/configure-private-link step-by-step instructions for setting up private endpoints for both hubs and projects.
• Azure OpenAI Private Endpoints: Connecting Across VNets https://techcommunity.microsoft.com/blog/azurearchitectureblog/azure-openai-private-endpoints-connecting-across-vnet%E2%80%99s/3913325 useful if your Foundry is backed by Azure OpenAI and you’re working across VNets.

These should help you validate whether the agent execution environment is correctly resolving and routing through the private endpoint.

[gukoff]

Thank you @leestott!

For context, I am using a reference architecture from CAIRA. On top of it, I made a few changes:

• created a private endpoint from Hub project to AI Foundry (it is auto-approved by the target resource)
• gave role Azure AI Developer for the Hub project to AI Foundry
• provisioned managed VNet for the Hub using az ml workspace provision-network

Then in the Management Center, I manually added AI Foundry as a connected resource:

1. First, there was no connection:
   
2. Then I added it
   
3. Then I picked this connection on the "agents" tab:
   
4. Then I got the error from the original post

Project still referencing public endpoint in tool scaffold: If you’ve scaffolded tools before enabling private connectivity, the tool spec or OpenAPI connection might still point to the public endpoint. Try re-importing the Foundry into the project to refresh endpoint references.

What do you mean by the tools?

Hub VNet not delegated correctly or missing subnet links: Make sure the hub's managed VNet has proper delegation for the AI Foundry and that the subnet used for private endpoints is accessible from the managed VNet range.
Confirm that your private DNS zone for privatelink.openai.azure.com is linked to the hub’s VNet.

Can I control or even see subnets, their delegation, and DNS zones in a managed VNet?

Validate DNS resolution from the agent

I don't get to even have an agent, there's an error screen on the agents tab 😄

I'll try to test DNS resolution from a compute (e.g. a notebook). So far creating a compute instance failed to create with the following error, which I didn't have time to troubleshoot. Maybe it rings a bell for you?

[gukoff]

I run a compute instance and a prompt flow on this instance. This required giving my user broad contributor roles to both file and blob parts of the storage account.

In the prompt flow, I checked DNS resolution of some domain names using socket.getaddrinfo("xxx", 443):

• Blob endpoint stcmaud.blob.core.windows.net resolved to a private IP
• OpenAI endpoint aifcmaud.openai.azure.com resolved to a private IP
• Cognitive services endpoint aifcmaud.cognitiveservices.azure.com resolved to a private IP
• AI Services endpoint aifcmaud.services.ai.azure.com resolved to a public IP

I will troubleshoot further; the AI Services endpoint is a main culprit for me at the moment.

[gukoff]

DNS resolution seems in line with the Hub's private endpoints. If there's a private endpoint, there is DNS resolution to a private IP address.

The domain name aifcmaud.services.ai.azure.com is the exception, it doesn't get a private IP from a private endpoint to AI Foundry. Maybe it's by design, and it's a red herring in my troubleshooting efforts - I don't know.

{
  "stcmaud.blob.core.windows.net": "10.1.0.9",
  "stcmaud.file.core.windows.net": "10.1.0.12",
  "stcmaud.queue.core.windows.net": "52.239.155.197",
  "stcmaud.table.core.windows.net": "52.239.155.198",
  "acrcmaud.azurecr.io": "10.1.0.11",
  "aifcmaud.services.ai.azure.com": "20.232.91.134",
  "aifcmaud.openai.azure.com": "10.1.0.14",
  "aifcmaud.cognitiveservices.azure.com": "10.1.0.13"
}

[gukoff]

Yesterday the error disappeared on my Hub based project, and I don't know why.

I removed all extra roles that I added following this advice: https://github.com/orgs/azure-ai-foundry/discussions/60#discussioncomment-13578182
The project still works.

The thing I did just before the error disappeared was to remove and re-add the AI Foundry as a connected resource in the Management Center. I have another hub where I still get this error; the same action does not help there.

For more context, on the now-working Hub based project, the DNS resolution works exactly as before (see the previous message). Suggesting that DNS was not to blame.

The capability hosts on the working and the broken Hub&projects are identical. So far I can not pinpoint the difference.

[AnjaneyalnDatla]

Hi @gukoff

We've been working through similar challenges getting AI Foundry Hub to function correctly in a fully private setup (private inbound, with only approved networks allowed). Despite following the documentation, we still ran into several issues and haven’t been able to get everything working exactly as described.

That said, I did encounter the same issue you're facing. After several trials and comparisons between public and private setups, what ultimately worked for me was assigning the Azure AI User role to the Azure AI services resource(No mention of this in the documentation, atleast i couldn't find it). I’d recommend adding it directly on the resource, and optionally at the resource group level as well—won’t hurt to have it there.

This role includes permissions to read private endpoint connections, which appears to be critical for the service to function properly in a restricted network environment.

A couple of things to note:

Role propagation can take a little while—you might need to log out and back in.

If it still doesn’t work, try toggling the "Allow trusted Microsoft services to access this resource" setting on the Azure AI service: disable it, then re-enable it.

Hope this helps.

[AnjaneyalnDatla]

Not yet. I have gotten to the point of getting the agent created with knowledge base added (ai search). When i try to test the agent using playground, it starts failing again with tool_error.

[gukoff]

I found out that the "standard setup" and the "standard setup with bring-your-own-network" also relate to the Hub based projects.

Perhaps if you bring your own network, you'll have better luck: https://github.com/Azure-Samples/azureai-samples/tree/main/scenarios/Agents/setup/network-secured-agent-thread-storage

I still don't understand whether the basic/standard setups will use the Hub's managed VNet.

[AnjaneyalnDatla]

I just got this link from one of our MS techs https://techcommunity.microsoft.com/blog/AIPlatformBlog/build-recap-new-azure-ai-foundry-resource-developer-apis-and-tools/4427241.

Now, i am contemplating switching directions to go foundry (non-hub) setup. Have you had tried the non hub full private setup ?

[gukoff]

I trued the non-hub setup, and it worked well. The reason I considered the hub at all was to work around this limitation :)

These resources will help you set up the Foundry Project:

• https://github.com/azure-ai-foundry/foundry-samples/tree/main/samples/microsoft
• https://github.com/msft-mfg-ai/ai-foundry-config-testing

[gukoff]

By the way, in case you have a working hub-based setup where the the agents can access the private AI Foundry - could you check if it's even supposed to work according to this explanation?

If somehow the connectivity to the private AI Foundry is there, you could open a support ticket to let the product group investigate how this happened.

[meerakurup]

To clarify some details here: In the Foundry hubs/project set-up, managed VNET is NOT used to secured outbound for the Agent service (preview). Similar to how the Agent service (GA) works in the new Foundry project resource, a virtual network and subnet injection is done to secured the Agent service (preview). Please refer to this Bicep template for the secure deployment of Agents with hubs/projects as there is not way in the UX to secure Agent client outbound and managed VNET does not apply in this case. Managed VNET in Foundry hubs/projects only applies to managed compute used in features such as PromptFlow.

I would recommend moving to the new Foundry project set-up, instead of hubs/projects. We will continue building new features for the new Foundry project, such as the Agent service.

[gukoff]

Thanks a lot, this clears it out. Then this error makes total sense.

What is very surprising is that agents accessing a private Foundry from the basic setup did eventually work for me after manual tinkering, seemingly at random. And a similar thing happened to @AnjaneyalnDatla. Unfortunately, I don't have that environment anymore in order to inspect the undesired network connectivity.

[skillbuilderzone]

Exactly what we struggled with and now moving to Foundry Project based setup with Vnet Injection (subnet)
Still an uphill battle with conflict errors and caphost issues on the account failures