Microsoft Foundry's network isolation story has three parts: inbound access to the Foundry resource, outbound access from the resource, and outbound access from the Agent client via VNet injection. The inbound part — who can reach your Claude endpoint at all — is controlled by a single resource setting called public network access (PNA). It has three modes, and choosing between them is the first real decision in any Foundry network review.
The three modes
| Mode | Who gets in | Typical use |
|---|---|---|
| Public (enabled) | Any network path; authentication is the only gate | Development, low-sensitivity workloads |
| Enabled from selected IP addresses | Public callers from allowlisted IPs only | Fixed egress points: offices, NAT gateways, partner ranges |
| Disabled | Private endpoints only | Regulated or data-sensitive production |
Public is the default posture: the endpoint is reachable from the internet, and your API keys or Entra ID tokens do all the gatekeeping. That is a real security layer, but it means credential leakage equals exposure.
Enabled from selected IP addresses keeps the public endpoint but applies an IP allowlist — a middle ground for organizations whose traffic exits through known addresses. Its weakness is operational: allowlists rot as offices move and NAT ranges change, and they do nothing for callers on dynamic networks.
Disabled closes the public endpoint entirely. The only way in is an approved private endpoint — a network interface with a private IP inside your Azure virtual network, created in the same region and subscription as the VNet. From your applications' perspective nothing changes except DNS resolution, which is its own topic: see how Azure DNS routes Foundry traffic through a private endpoint.
The trap: PNA and private endpoints are independent settings
Teams often assume the private endpoint causes the lockdown, so deleting it should restore public access. It does not. Removing a private endpoint does not re-enable public access — PNA is a separate setting that stays where you put it. Delete the only private endpoint from a PNA-disabled resource and you have built a resource nobody can reach: not your apps, not the portal's data-plane features, not you. The reverse assumption is equally wrong: adding a private endpoint to a PNA-public resource gives your VNet a private path but leaves the public door open until you flip PNA yourself. Treat the two as what they are — one setting that closes the public door, another that opens a private one — and sequence changes so at least one path exists at every step.
Reaching a fully locked-down resource
With PNA disabled, management and debugging traffic must originate from a network with a path to the private endpoint. Microsoft documents three standard routes in:
- VPN Gateway — point-to-site for individual engineers' laptops, site-to-site for a whole office network;
- ExpressRoute — private dedicated connectivity for on-premises estates;
- Azure Bastion jump box — a VM inside the VNet reached through Bastion, from which you administer the resource.
Pick one before flipping PNA to Disabled, not after, and remember that whoever creates and approves endpoints needs Network Contributor on the VNet plus Contributor or Owner on the Foundry resource.
172.17.0.0/16 as the VNet range (Docker's bridge network claims it, and containerized clients will misroute), and outbound VNet-injection settings can't be changed after deployment — if you will ever need agent-client VNet injection, deploy with it, because retrofitting means redeploying.Where to go next
Locked-down resources still need to admit Azure platform services like AI Search — that mechanism is the trusted-services bypass. And network rules only bind the network layer; pair PNA with Entra-ID-only auth via disabling local auth so identity is locked down too. For the endpoint-creation clicks, see Foundry private endpoints.