Once your organization decides that Claude traffic on Microsoft Foundry should stay off the public internet, the mechanics are well defined: set public network access (PNA) on the Foundry resource to Disabled and add an Azure Private Link private endpoint, which gives the resource a private IP inside a virtual network (VNet). What the documentation leaves to you is topology — which VNet, and how the applications scattered across your Azure estate reach it. That is a standard Azure networking decision, and the usual patterns apply.
Pattern 1: single VNet, endpoint alongside the app
The simplest arrangement: your application and the private endpoint share one VNet. The app resolves <resource-name>.services.ai.azure.com, gets the private IP from the private DNS zone Azure created with the endpoint, and calls Claude over the private path. This suits a single team with a self-contained workload. Its limitation appears the moment a second VNet needs the same Foundry resource.
Pattern 2: VNet peering
Peering connects two VNets so resources in either can reach the other's private IPs. With a peered setup, the private endpoint lives in one VNet and applications in the peer VNet reach it across the peering link. The endpoint itself has one placement constraint from the Foundry documentation: it must be in the same region and subscription as the VNet it is created in. The recurring failure mode in peered topologies is DNS rather than routing — every VNet whose clients must reach the endpoint needs the private DNS zone linked to it, or those clients will resolve the public address and be refused by the PNA-disabled resource.
Pattern 3: hub-and-spoke
Most enterprises with more than a handful of VNets run hub-and-spoke: a central hub VNet holds shared services (firewalls, DNS, gateways), and workload "spoke" VNets peer to the hub. Private endpoints for shared platform services — and a Foundry resource serving multiple teams' Claude workloads is exactly that — commonly live in the hub or in a dedicated shared-services spoke. Central network teams then manage DNS zone links and firewall rules once, and every spoke inherits the private path. If several business units will call the same Claude deployments, this is usually where you end up; pair it with RBAC so network reachability and permission to call the model remain separate decisions.
Inbound-only restrictions without full isolation
Full VNet isolation is not the only documented option. Foundry resources also support "Enabled from selected IP addresses" — an allowlist on the public endpoint. This is a lighter control: traffic still arrives at the public endpoint, but only from IP ranges you specify, such as your office egress or a NAT gateway. Teams use it as a stepping stone before Private Link, or for low-sensitivity environments where a full private topology is not worth the operational cost. It composes with the same authentication controls either way.
Inbound versus outbound: two different problems
Everything above governs inbound traffic — clients reaching the Foundry resource. Foundry has a separate documented mechanism for outbound isolation when you use its agent capabilities: VNet injection places the Agent client into a customer-managed subnet delegated to Microsoft.App/environments (sized /27 or larger), with bring-your-own Storage, AI Search, and Cosmos DB for Standard agent setups. If your Claude usage is plain Messages API calls through the AnthropicFoundry client, the inbound patterns are the whole story; if you adopt Foundry agents, plan the outbound subnet too.
One honest caveat: this networking guidance is generic to Foundry resources. Neither Microsoft nor Anthropic publishes Claude-specific VNet topology documentation beyond it — Anthropic's page simply notes the resource can optionally join a private network. The patterns here are standard Azure practice applied to a documented capability; validate the current specifics against the official Private Link documentation before committing a design.
Where to go next
For the endpoint mechanics, read setting up private endpoints; for the packet-filtering layer, continue to NSG rules for Foundry traffic, or browse all articles.