When you call Claude on Microsoft Foundry, your application talks to an endpoint of the form https://<resource-name>.services.ai.azure.com/anthropic. Out of the box that is a public endpoint: reachable from the internet, protected only by API keys or Microsoft Entra ID tokens. Many security teams want a stronger guarantee — that requests to the model never traverse the public internet at all. Azure Private Link provides that: a private endpoint is a network interface with a private IP address inside your virtual network (VNet) that represents the Foundry resource, so traffic flows over Azure's private backbone.
The two settings that work together
Foundry resources support inbound network isolation through two controls. First, public network access (PNA): set it to Disabled to stop the resource answering public traffic, or use "Enabled from selected IP addresses" if you only need IP allowlisting rather than full isolation. Second, the private endpoint itself, which gives clients inside your VNet a private path in. Disabling PNA without adding a private endpoint locks everyone out; adding an endpoint without disabling PNA leaves the public door open alongside the private one. For a genuinely private deployment you do both.
Creating the endpoint
You can attach a private endpoint at two points in the resource lifecycle:
At resource creation: on the Networking tab of the creation flow, choose Disabled for public access and add a private endpoint there.
On an existing resource: go to Resource Management > Networking > Private endpoint connections and add the endpoint. One placement rule to plan around: the private endpoint must be in the same region and subscription as the VNet it joins.
Permissions are the usual stumbling block, because two different scopes are involved. Creating the endpoint requires Network Contributor on the VNet. Approving the connection requires Contributor or Owner on the Foundry resource — without that, connection requests sit in a Pending state and traffic never flows. In organizations where networking and AI platform teams are separate, agree up front who clicks approve.
DNS: same hostname, different answer
The elegant part of Private Link is that your application code does not change. When the endpoint is created, Azure updates the resource's CNAME record to a privatelink subdomain alias and creates a private DNS zone with the A records. The result: clients inside the VNet resolve the exact same connection string — <resource-name>.services.ai.azure.com — to the private IP, while clients outside resolve the public endpoint (which, with PNA disabled, refuses them). Your AnthropicFoundry(api_key=..., resource="...") client keeps working untouched; only the network path underneath changes.
This is also the first thing to test. From a VM or container inside the VNet, resolve the hostname and confirm it returns a private IP; from outside, confirm requests are rejected. If inside clients still resolve a public IP, the private DNS zone is not linked to their VNet.
Scope and limits of this control
Two clarifications keep expectations accurate. First, private endpoints govern inbound traffic to the resource. Outbound isolation — relevant if you use Foundry's agent capabilities — is a separate mechanism using VNet injection of the Agent client into a customer-managed subnet delegated to Microsoft.App/environments (a /27 or larger), with bring-your-own Storage, AI Search, and Cosmos DB for Standard agent setups.
Second, this guidance is generic to Foundry resources: neither Microsoft nor Anthropic documents Claude-specific private-endpoint behavior beyond it. Anthropic's documentation simply notes you can optionally configure the resource to be part of a private network. That genericity is good news — Claude deployments ride the standard Foundry networking model — but verify current details against the official Private Link documentation before a production rollout. Also keep the auth layer on: a private endpoint narrows who can reach the resource, while RBAC and Entra ID authentication still decide who may call it.
Where to go next
Continue to VNet topology options and NSG rules for private endpoint traffic, or start from resource setup if you have no Foundry resource yet.