Azure Foundry Agent creation over Private Endpoint

Mark Pearson 320 Reputation points
2026-06-17T14:27:54.4366667+00:00

We have a foundry resource with a created project that is using a private endpoint for networking connectivity. We have a hub and spoke topology with the AI resources having there own spoke. We have been trying to create an agent in one of two ways:

  1. Via the portal on an Azure VM within the same Vnet - Fails (I believe) because The Azure AI Foundry portal at Microsoft Foundry uses a server-side proxy architecture. So when you click "Create agent", the portal's own back-end servers make the API call on our behalf. Those servers are in Microsoft's Azure infrastructure — not in our browser, not in our VNet. So without public connectivity being enabled we cannot make this connection. Is this correct? or should we be able to create the agent manually?
  2. Via creating an agent by CreateAgentVersionAsync method of Azure.AI.Project package. With this method we are seeing an error of "5.2 HTTP 502: BadGateway "upstream_dependency_failed" error" (full error below).

HTTP 502: BadGateway

{

"error": {

*"type": "ServiceError",*

*"code": "upstream_dependency_failed",*

*"param": "",*

*"message": "An error occurred while processing your request. You can retry your request, or contact us if the error persists. Please include the request ID a01461538bea44e2aca1d632f9691c3b in your message.\r\n\r\n{\r\n  \u0022code\u0022: \u0022upstream_dependency_failed\u0022,\r\n  \u0022message\u0022: \u0022An error occurred while processing your request. You can retry your request, or contact us if the error persists. Please include the request ID a01461538bea44e2aca1d632f9691c3b in your message.\u0022,\r\n  \u0022type\u0022: \u0022error\u0022,\r\n  \u0022details\u0022: [],\r\n  \u0022additionalInfo\u0022: {\r\n    \u0022request_id\u0022: \u0022a01461538bea44e2aca1d632f9691c3b\u0022\r\n  }\r\n}"*

}

}

at Azure.AI.Projects.Agents.ClientPipelineExtensions.ProcessMessageAsync(ClientPipeline pipeline, PipelineMessage message, RequestOptions options)

at Azure.AI.Projects.Agents.AgentAdministrationClient.CreateAgentVersionAsync(String agentName, BinaryContent content, String foundryFeatures, RequestOptions options)

at Azure.AI.Projects.Agents.AgentAdministrationClient.CreateAgentVersionAsync(String agentName, ProjectsAgentVersionCreationOptions options, String foundryFeatures, CancellationToken cancellationToken)

at ActionCompanion.Web.Filters.RAGAgentService.AskAgenticRAGAsync(String userQuestion, String modelName, String systemPrompt) in C:\Users\rahulgupta\Source\Repos\ActionCompanion\ActionCompanion.Web\Filters\RAGAgentService.cs:line 48

Any and all help appreciated on this matter.

Foundry Agent Service
Foundry Agent Service

A fully managed platform in Microsoft Foundry for hosting, scaling, and securing AI agents built with any supported framework or model

Answer accepted by question author
Alex Burlachenko 25,290 Reputation points MVP Volunteer Moderator
2026-06-22T11:16:01.9433333+00:00

Mark Pearson hi , thx for sharing urs issue here at Q&A portal,

the SDK path should work if the private networking setup is fully wired up.

For the portal part, ur understanding is mostly right. Clicking 'Create agent' in Foundry portal is not the same as running the API call from ur VM. Some portal operations go thru Foundry backend services, so just opening the portal from a VM in the VNet doesn’t automatically mean every downstream call runs from that VM. The SDK error is more useful here. 502 upstream_dependency_failed usually means the request reached Foundry, auth was good enough, but Foundry failed when calling one of its required backend deps.

With private Agent Service, MS docs say u need the Standard setup w/ private networking and BYO resources like Storage, AI Search, and Cosmos DB. Those deps need private endpoints + correct private DNS, not just the main Foundry private endpoint https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/virtual-networks

So I’d look at the agent deps first Storage, AI Search, Cosmos DB, private endpoint approval state, DNS zones, and VNet links. For DNS, make sure zones like privatelink.services.ai.azure.com, privatelink.search.windows.net, privatelink.documents.azure.com, and privatelink.blob.core.windows.net resolve to private IPs from the VM and from the VNet used by the agent runtime.

MS has a good deep dive https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/agents-networking-deep-dive

My bet is not 'SDK creation is unsupported'. More likely one of the downstream resources can’t be reached by the Agent Service runtime, or DNS is resolving public instead of private somewhere.

Since u already have a request id a01461538bea44e2aca1d632f9691c3b, send that to MS Support and ask them which upstream dependency failed. Without that backend trace, 502 is kinda useless from the client side.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

Was this answer helpful?

1 person found this answer helpful.
0 comments
Answer accepted by question author
Karnam Venkata Rajeswari 5,255 Reputation points Microsoft External Staff Moderator
2026-06-17T14:39:00.9+00:00

Hello @Mark Pearson ,

Welcome to Microsoft Q&A .Thank you for reaching out to us.

Thank you for sharing the detailed scenario and the observations across both portal and SDK-based agent creation flows.

AI Foundry Agent Service supports private networking scenarios when the environment is configured according to the documented networking requirements and all required dependencies are accessible through the configured private network path.

The observed error HTTP 502 – upstream_dependency_failed generally indicates that:

  1. The request successfully reached Azure AI Foundry.
  2. Azure AI Foundry attempted to communicate with a required backend dependency.
  3. That dependency communication failed due to connectivity, DNS, networking, authorization, or configuration issues.

Regarding the portal vs SDK behavior

Azure portal operations typically invokes Azure service backend operations rather than performing all actions directly from the browser or VM.

The important point is:

  • The portal flow and SDK flow both ultimately depend on Azure AI Foundry backend services.
  • The success of agent creation depends on whether AI Foundry can successfully complete required backend operations and communicate with required dependencies.

Since both portal and SDK-based creation are failing, this suggests the issue is more likely related to a shared backend dependency, networking configuration, DNS resolution or permissions issue rather than the location from which the portal is accessed.

Regarding manual / SDK-Based agent creation :

Creating agents manually through the SDK/API is expected to work in a correctly configured Azure AI Foundry private networking deployment.

The SDK failure does not indicate that SDK-based creation is unsupported.

The current behavior suggests:

  • The request is reaching Azure AI Foundry.
  • Authentication is working sufficiently for the request to be processed.
  • The failure occurs during downstream processing when Azure AI Foundry attempts to use required resources or dependencies.

Therefore, the focus should be on validating:

  • Dependency connectivity
  • Private Endpoint configuration
  • DNS resolution
  • Network routing
  • Managed Identity permissions
  • RBAC assignments

Please note that there are multiple networking layers involved.

A successful Private Endpoint connection to the Azure AI Foundry resource/project does not automatically guarantee that all Agent Service dependencies are reachable.

The following should be considered separately:

Azure AI Foundry Private Connectivity overs connectivity to the Foundry resource/project.

Agent service dependency connectivity covers access to dependent services such as:

  • Azure Storage
  • Azure Cosmos DB
  • Azure AI Search
  • Azure OpenAI (where applicable)

A Foundry Private Endpoint can be healthy while agent creation still fails because a required dependency cannot be reached.

The error 502 upstream_dependency_failed usually indicates a failure communicating with a downstream dependency.

In private networking environments, common causes include:

  • Private Endpoint configuration issues
  • Incorrect Private DNS configuration
  • Storage connectivity failures
  • Cosmos DB connectivity failures
  • Azure AI Search connectivity failures
  • Firewall or routing restrictions
  • Managed Identity permissions
  • RBAC authorization failures

Please check if the following validation checks help-

  1. Confirming supported deployment configuration Please confirm:
    • Azure AI Foundry Agent Service is being used with a supported private networking configuration
    • The project/resource configuration follows the documented private networking requirements
    • Required dependencies are correctly associated with the environment
  2. Validating Backend Dependencies Please verify that all required dependencies:
    • Exist
    • Are correctly configured
    • Are reachable through private networking
    Typical dependencies include:
    • Azure Storage
    • Azure Cosmos DB
    • Azure AI Search
    • Azure OpenAI (if used)
    These dependencies are required in standard setups where customer-managed resources are used for storing agent data.
  3. Validating private endpoint configuration For each required dependency, please verify if:
    • Private Endpoint exists
    • Connection state is Approved/Connected
    • Endpoint is deployed into the correct VNet/subnet
    • Network policies and routing allow connectivity
    Validate Private Endpoints for:
    • Azure AI Foundry
    • Azure Storage
    • Azure Cosmos DB
    • Azure AI Search
    • Azure OpenAI (where applicable)
    Please note that private endpoints for dependencies are not automatically created and must be configured separately.
  4. Validating DNS resolution Private Endpoint scenarios depend heavily on correct DNS configuration. From a VM inside the spoke VNet, run: 
       nslookup <resource-fqdn>
    Please validate that:
    • Storage resolves to a private IP
    • Cosmos DB resolves to a private IP
    • AI Search resolves to a private IP
    • Other dependent resources resolve correctly
    Incorrect DNS resolution can prevent access to private endpoints even when they are correctly configured.
  5. Validating Cosmos DB connectivity Cosmos DB should be treated as a high-priority validation item. Verify:
    • Cosmos DB Private Endpoint exists
    • DNS resolves correctly
    • Connectivity from the environment is successful
    • Required permissions are assigned
    Connectivity issues with Cosmos DB can directly impact agent creation operations.
  6. Validating storage and search connectivity Azure Storage
    1. Private Endpoint connectivity
    2. DNS resolution
    3. Required permissions
    Azure AI Search
    1. Private Endpoint connectivity
    2. DNS resolution
    3. Authentication/authorization configuration These resources are required in standard deployments for storing files, threads, and vector data.
  7. Validating managed identity and RBAC Although the error pattern suggests connectivity issues, authorization failures can also appear as dependency failures. Please verify:
    • Required managed identities are enabled
    • Azure AI Foundry/Agent Service identities have required permissions
    • RBAC assignments exist for:
    • Storage
    • Cosmos DB
    • Azure AI Search
  8. Validating Firewall, NSG and Routing Please review whether the environment uses:
    • Azure Firewall
    • Network Security Groups
    • User Defined Routes
    • Third-party firewall appliances
    To confirm:
    • Required traffic is allowed
    • Routing is not redirecting traffic incorrectly
    • TLS inspection is not interfering with Azure service communication
    • No outbound dependency access is blocked

As an optional diagnostic test

If permitted by security policy, perform a controlled diagnostic test:

  • Temporarily allow public network access or relax private networking restrictions
  • Retry agent creation

If the operation succeeds, this strongly indicates that the issue is related to:

  • Private Endpoint configuration
  • DNS
  • Routing
  • Firewall rules
  • Network reachability

For further assistance and to narrow down the exact dependency causing the failure, please let us know:

  1. If this is using Standard Agent setup with private networking?
  2. The dependencies which are configured?
    • Storage
    • Cosmos DB
    • AI Search
    • Azure OpenAI
  3. Are private endpoints configured for each dependency?
  4. Are private DNS zones linked to the spoke VNet?
  5. Is Azure Firewall or custom DNS involved?
  6. Was private networking configured during initial deployment or added afterwards?
  7. Does a minimal agent creation attempt also fail?

The following references might be helpful , please check them out

Please let us know if the response was helpful

 

Thank you

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Karnam Venkata Rajeswari 5,255 Reputation points Microsoft External Staff Moderator
    2026-06-23T09:16:07.83+00:00

    Hello @Mark Pearson ,

    Welcome to Microsoft Q&A .Thank you for reaching out to us.

    Thank you for the follow-up and for sharing the results of the testing. The observations provided help clarify how the deployment behaves when operating under private networking constraints and raise an important question regarding the recommended architecture for fully network-isolated deployments.

    Based on the currently published Azure AI Foundry documentation, the Standard Agent setup with customer-managed (BYO) resources remains the documented approach for fully network-isolated Agent Service deployments. This model utilizes customer-managed Azure Storage, Azure AI Search, and Azure Cosmos DB resources, enabling full control over networking and security configurations such as Private Endpoints, Private DNS zones, virtual network integration, routing policies and RBAC permissions.

    Regarding the previously observed 502 (upstream_dependency_failed) error, this response indicates that the request successfully reached Azure AI Foundry, but a required downstream dependency was unable to complete the operation. While this behavior is consistent with dependency connectivity or access issues, the error itself does not identify the specific resource involved and therefore cannot be used to determine the exact root cause without additional validation.

    For future private networking deployments, the following validation steps are recommended to help ensure all required dependencies are reachable and correctly configured:

    1. Validating Private Connectivity
      1. Please confirm all required Private Endpoints are deployed and show an Approved or Connected state.
      2. Verify connectivity for all dependent services, including:
        • Azure AI Foundry
        • Azure Storage
        • Azure Cosmos DB
        • Azure AI Search
        • Azure OpenAI (if applicable)
    2. Validating DNS Resolution
      1. Please confirm that all required Private DNS zones are configured correctly.
      2. Verify that Private DNS zones are linked to the appropriate virtual networks.
      3. Validate that service FQDNs resolve to private IP addresses from within the network.
    3. Validating Identity and Access Configuration
      1. Verifying that the managed identity used by Agent Service has the required permissions on dependent resources.
      2. Confirm RBAC assignments are applied at the correct scope and have propagated successfully.
    4. Reviewing Network Security Controls
      1. Review firewall rules, NSGs, UDRs, custom DNS configurations, and routing settings.
      2. Confirm that communication between Agent Service and dependent resources is permitted.

    While the validation steps above can help assess and troubleshoot current deployments, the broader question relates to long-term support for fully isolated architectures.

    At present, no public roadmap information or product commitments are available regarding additional private networking capabilities for managed-resource deployments. As a result, it is not possible to confirm whether further isolation capabilities may be introduced in future releases.

    Based on the currently available guidance, the BYO deployment model remains the documented approach for environments requiring the highest level of network isolation and customer-managed control of dependent resources.

    The following references might be helpful , please check them out

    Please let us know if the response was helpful

     

    Thank you

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.