Azure Foundry Service: “Error occurred while processing your request”

Hello oya,

Thank you for reaching out to Microsoft Q&A,

Even though:

• Foundry hub and Databricks are in the same VNet
• Private Link is configured
• Public access to Databricks is disabled

The failure happens because Azure AI Foundry agent tool execution does NOT run inside your VNet by default

So when the Genie tool runs:

• It tries to call Databricks APIs over public internet
• Your Databricks blocks it (since only Private Endpoint is allowed)
• Result - Error occurred while processing your request

Clarification

You mentioned “Deploy Foundry agents into VNet”

That would solve the problem if fully supported, but today:

• Foundry workspace/hub can be VNet integrated
• But agent runtime is still Microsoft-managed
• It does not automatically inherit your VNet or Private Endpoints

So even with Private Link configured correctly, the agent itself cannot directly use it.

What a fully private setup would require

If this were fully supported, your setup would look like:

1. VNet-injected runtime

• Agent runs inside your VNet
• All outbound traffic goes through your network

2. Databricks Private Link

Private endpoints for:

• api.azuredatabricks.net (control plane)
• {workspace-id}.privatelink.azuredatabricks.net (data plane)

Private DNS zone:

• privatelink.azuredatabricks.net linked to VNet

3. Network rules

NSG allows Agent subnet --> Databricks private endpoint (port 443)

Databricks allows That subnet/IP range

Proper auth Managed Identity / Service Principal

This architecture is correct in principle, but the missing piece is: agent runtime is not inside that subnet today

Supported solution

Since direct Private Link access from Foundry agents isn’t supported yet, you need a proxy layer inside your VNet.

Use an intermediate service

Deploy one of these inside your VNet:

• Azure Function (best choice)
• Azure Container Apps
• AKS / App Service

Flow:

Foundry Agent → HTTPS call → Your API (public endpoint)

Why this works

Agent can call public HTTPS endpoint

Your service:

• Lives inside VNet
• Uses Private Endpoint to reach Databricks
• Fully respects your network restrictions

What to configure in this model

1. Databricks Private Link

Private endpoints for:

• Control plane (api.azuredatabricks.net)
• Workspace endpoint

Private DNS zone configured and linked

2. Proxy service

Deploy Azure Function in same VNet

Enable VNet integration

Use Managed Identity or PAT token

Call Databricks Genie API internally

3. Networking

NSG Allow Function subnet --> Databricks private endpoint (443)

No need to expose Databricks publicly

Alternative

Enable Databricks public access

Restrict using IP allowlist, Authentication

Not recommended for strict private environments

Even though your VNet + Private Link setup is correct, Azure AI Foundry agents cannot directly use private endpoints today because their execution environment is not VNet-injected, so you must introduce a VNet-based proxy to bridge the connection securely.

Please refer this

Configure Private Link for Foundry: https://dori-uw-1.kuma-moon.com/en-us/azure/foundry/how-to/configure-private-link

Stuck or failed web service call (common REST API errors): https://docs.microsoft.com/azure/machine-learning/studio/web-service-error-codes

Unable to Login to Azure AI Foundry (network connectivity section): https://dori-uw-1.kuma-moon.com/azure/ai-studio/concepts/ai-resources

HTTP 500 / 503 / Service Unavailable (troubleshooting service outages): https://azure.microsoft.com/updates?id=492574

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

Thank you!

For Azure AI Foundry agents to call Databricks Genie over Private Link, the architecture must ensure that:

1. The Foundry project itself is reachable only via a private endpoint.
2. The Foundry Agent Service (agent compute) is injected into a dedicated subnet in the same (or peered) VNet.
3. Private endpoints and DNS are correctly configured so that the agent subnet can resolve and reach Databricks’ private endpoints.

From the described symptoms (tool execution error despite being in the same VNet), the issue is almost certainly in one of these areas:

1. Private endpoint and DNS for Foundry and Databricks
   • Verify that all required private endpoints are created and in an Approved state.
   • For each resource (Foundry project, Databricks workspace, and any backing services like storage, Cosmos DB, etc.), confirm:
     • A corresponding private DNS zone exists for the privatelink FQDN.
     • Each private DNS zone is linked to the VNet that contains the agent subnet.
     • From a VM or Databricks cluster in that VNet, run:
       • nslookup <your-foundry-endpoint-hostname>
       • nslookup <your-databricks-private-endpoint-hostname> and confirm they resolve to private IPs, not public IPs.
   • If using a custom DNS server, ensure it forwards privatelink queries to Azure DNS at 168.63.129.16.
2. Connectivity from the agent subnet (network injection)
   • Ensure the Foundry project is configured with Standard Agent deployment and that network injection is correctly set up so that agents run inside the VNet/subnet that has access to Databricks.
   • Confirm the delegated agent subnet:
     • Uses a valid RFC1918 address range (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16).
     • Has sufficient free IP addresses.
   • From a machine connected to the same VNet, test:
     • nslookup <databricks-private-endpoint-fqdn> → private IP
     • Test-NetConnection -ComputerName <databricks-private-endpoint-fqdn> -Port 443 → TcpTestSucceeded: True
   • If Test-NetConnection fails, check:
     • NSG rules on the agent subnet allow outbound HTTPS (port 443) to the Databricks private endpoint IP.
     • Any firewalls (Azure Firewall, NVA) allow this traffic.
3. DNS resolution failures for private endpoints
   • If the agent error indicates DNS or “host not found” behavior, follow the private endpoint DNS troubleshooting guidance:
     • Verify each private DNS zone is linked to the VNet.
     • Confirm conditional forwarders (if any) point to 168.63.129.16.
     • From a VNet-connected machine, run nslookup <resource-fqdn> and ensure it resolves to a private IP.
4. Databricks network access control and IP restrictions
   • With IP restrictions enabled on Databricks, ensure that:
     • The agent subnet’s outbound IPs (or the private endpoint IPs, depending on the configuration) are allowed in Databricks’ network access control.
     • If a firewall or NAT gateway is used for egress, the NAT public IP or relevant private IPs are whitelisted.
5. Agent-specific issues in network-isolated projects
   • If the agent fails to start or tools fail with generic network errors:
     • Confirm the project uses Standard Agent deployment (Basic does not support network injection).
     • Ensure the subnet has enough IP addresses.
     • Verify that all required private endpoints (Foundry, Databricks, storage, Cosmos DB, etc.) exist and are reachable.
     • If evaluations or tool calls fail with network errors, verify that all required DNS zones are configured and that the agent compute can reach both Foundry and Databricks endpoints via private links.
6. High-level target architecture A correct architecture for this scenario typically looks like:
   • One VNet (or peered VNets) containing:
     • Subnet A: Foundry Agent Service delegated subnet (Standard Agent with network injection).
     • Subnet B: Databricks workspace / clusters.
   • Private endpoints in the VNet for:
     • Foundry project (if using private access).
     • Databricks workspace and any required backing services.
   • Private DNS zones for all privatelink FQDNs, linked to the VNet.
   • NSGs and firewalls configured to allow:
     • Agent subnet → Databricks private endpoint on port 443.
   • Databricks network access control configured to allow traffic from the agent subnet / egress IPs.

If, after validating private endpoints, DNS, NSGs, and Databricks IP allowlists, the agent still fails with a generic “Error occurred while processing your request,” collect:

• Exact error message from the agent run.
• Result of nslookup and Test-NetConnection from a VM in the same VNet.
• Private endpoint and DNS zone configuration.

Then open a support ticket, as generic “capability host” or network errors often require backend investigation.

---

References:

• How to configure network isolation for Microsoft Foundry
• Set up private networking for Foundry Agent Service
• Troubleshoot connection to a project with a private endpoint (classic)