I'm trying to understand how Microsoft Foundry communicates with services hosted inside an Azure VNet. Does this require a private endpoint, a service endpoint, or another networking pattern? I'm especially interested in the difference between running an agent with VNet integration and using Microsoft-hosted networking, along with the recommended approach for inbound and outbound connectivity.
3 Answers
A common architecture is to put API Management or an MCP server in the VNet and have the agent call that component. It can then access private APIs, VMs, databases, or other internal services while centralizing authentication and network controls. The exact design depends on whether you need private inbound access to Foundry, private outbound access from the agent, or both.
There are two directions to consider. For inbound access to the Foundry resource, a private endpoint can expose the resource through a VNet. For outbound access from an agent to resources in your tenant, you need to configure the agent’s VNet integration or virtual-network networking option. Without that setup, outbound agent traffic uses Microsoft-hosted networking rather than reaching private services in your VNet.
A private endpoint is primarily for private connectivity from your VNet to a platform service. It does not generally make arbitrary VNet services reachable from the service. Think of it as an inbound path to the Foundry resource, not an outbound route from Foundry into your network. For private backend services, configure the appropriate agent VNet integration or place an intermediary such as API Management or an MCP server inside the VNet.
So would a VM connect to Foundry through a private endpoint, while Foundry reaches the VM through a separate VNet integration or intermediary service?
I’m new to Foundry—what is the practical difference between running an agent with VNet integration and using Microsoft-hosted networking?