Azure AI Foundry private endpoints are where enterprise AI stops being a demo and becomes something your security team will approve. Microsoft Foundry makes it easy to build agents, deploy models and run evaluations, but once real data is involved, public access, DNS, RBAC and developer connectivity become the hard problems.
This runbook covers what to lock down, what not to break, how private endpoints fit, and how to troubleshoot the classic “it works from my laptop but not from the app.”
Why Azure AI Foundry private endpoints matter
Microsoft’s Foundry network isolation guidance describes three areas: inbound access to the Foundry resource, outbound access from Foundry to other Azure services, and outbound access from the Foundry Agent client to dependencies such as private data sources. Most incidents aren’t “private endpoint yes or no”; they’re “which path is this request taking?”
The three paths to design before you lock the gate
Admins, makers, data scientists, CI jobs and apps reaching the project or account.
Storage, Key Vault, monitoring, model endpoints and other Azure services.
Agent runtime traffic to private data sources, PaaS services or approved internet endpoints.
Foundry isn’t one box; it’s a platform surface plus supporting resources, identities, model deployments, data stores and developer workflows. Isolate the front door and leave the side windows open, and the audit will find them.
| Design area | Recommended starting point | Why it matters |
|---|---|---|
| Public access | Disable it where private access is required, or use selected IPs as a transition. | Removes accidental direct paths while you prove private connectivity. |
| Private endpoints | Create them for Foundry and each required connected service. | One endpoint for the obvious resource is rarely enough. |
| DNS | Use Microsoft’s recommended private DNS zones, linked to the right VNets. | Most “private endpoint is broken” tickets are DNS tickets. |
| Identity | Prefer Microsoft Entra ID and Foundry RBAC over keys. | Microsoft notes key-based authentication grants full access without role restrictions. |
| Rollout | Pilot one project and one application path, then expand in rings. | Isolation is secure right up until every developer is blocked. |
Start with identity: RBAC is part of the network story
Network isolation controls where requests come from; RBAC controls what they can do on arrival. Foundry’s built-in roles include Foundry User, Foundry Owner, Foundry Account Owner and Foundry Project Manager, renamed from the earlier Azure AI role names with the same role IDs and core permissions.
Make sure both the caller and the project’s managed identity have the right roles at the right scope. If an app resolves the private endpoint but still gets authorization errors, stop adding DNS zones and check RBAC, the managed identity and whether the code uses Entra authentication or a key. Private networking plus shared keys is a locked building where everyone has copied the master key.
Design the private endpoint path
A private endpoint gives a resource a private IP in your VNet, and clients rely on DNS to resolve the service name to it. Microsoft’s guidance is blunt: configure DNS so the FQDN resolves to the private IP, and don’t override zones in a way that breaks public resolution without proper forwarding. Before changing anything, map:
- Who connects: browser users, build agents, backend APIs, jump boxes, integration runtimes and automation.
- From where: corporate network, VPN, ExpressRoute, hub-and-spoke VNets, private build agents or app environments.
- To what: the Foundry project or account, model deployments, storage, Key Vault, monitoring, private data and approved outbound endpoints.
- With which identity: user, managed identity, service principal or workload identity federation.
The DNS flow is: the client asks for the Foundry endpoint name, the private DNS zone linked to the workload VNet answers, the private IP of the endpoint NIC comes back, and traffic stays private, with RBAC still applied. For hybrid clients, the Azure DNS Private Resolver runbook covers the forwarding design.
Common breakpoints
| Symptom | Likely cause | First checks |
|---|---|---|
| Works from a VM in one VNet, fails elsewhere | Private DNS zone or VNet link mismatch | Compare DNS resolution from both clients; verify zone links and forwarding. |
| Name resolves to a public IP | Zone not linked or conditional forwarding missing | Check the resolver path, zone records and corporate forwarding. |
| Connection times out | Route, NSG, firewall or endpoint approval | Check endpoint state, effective routes, NSGs and firewall rules. |
| HTTP 401 or 403 | Identity or RBAC, not the network | Confirm token audience, managed identity, Foundry role and dependency permissions. |
| Model call works, data access fails | Connected resource or agent dependency unreachable | Trace the outbound path to storage, Key Vault, search, database or API. |
Runbook: roll out Azure AI Foundry private endpoints
- Create the project intentionally. Decide whether it’s a sandbox, a shared platform project or a production application boundary.
- Define allowed client networks: admin workstations, VPN or ExpressRoute, private build agents, app subnets and jump boxes. Browser users of a private project need private DNS and routing too.
- Create private endpoints for Foundry and its dependencies, including Key Vault, storage, search, databases and internal APIs. The App Service Key Vault reference fixes show how identity plus network rules can fail in non-obvious ways.
- Wire DNS deliberately: link private zones to the VNets hosting clients, agents and apps, and set conditional forwarding for hybrid users.
- Assign least-privilege Foundry roles to users and managed identities; keep broad Contributor roles away from day-to-day AI users.
- Test layer by layer: DNS, TCP, token acquisition, Foundry API, model inference, then data and tool access.
- Disable or restrict public access once private paths are proven. Selected IPs can bridge the transition, but shouldn’t become permanent.
- Monitor and document dependencies, approved egress, endpoint owners, DNS zones and break-glass steps.
Keep developers productive
Publish a documented developer path: VPN or developer VNet access, private DNS, required roles, sample code using Entra authentication, and a small script that checks name resolution and token-based connectivity. For CI/CD, use private build agents or controlled workload identities with the same basics: route, DNS, identity and least privilege.
| Access pattern | Best for | Risk |
|---|---|---|
| Public access | Low-risk sandboxes only | Broad exposure if identity or keys are mishandled. |
| Selected IPs | Transition, admin pilots, known corporate egress | Brittle when locations and agents change. |
| Private endpoint | Production and sensitive data | DNS and dependencies must be designed, not assumed. |
Troubleshooting flow
- Resolve the hostname from the failing client. If it doesn’t return the expected private IP, fix DNS first.
- Confirm the endpoint connection state. Pending, rejected or disconnected endpoints won’t carry traffic.
- Check the route and firewall path, including NSGs, UDRs, Azure Firewall and on-premises firewalls.
- Validate the authentication mode and the token’s target audience.
- Check Foundry RBAC for the caller and the managed identities.
- Test dependencies separately, since a model endpoint can work while storage or search fails.
- Allow for propagation: DNS, endpoint approval, RBAC and network appliance updates can lag.
Governance guardrails to standardize
- Landing zone template: required endpoints, DNS links, tags, diagnostic settings and baseline roles.
- Policy controls: audit or deny public network access for sensitive projects, with Azure Policy remediation tasks to fix drift.
- Approved connectivity patterns: developer VPN, private build agents, app subnets, hub-and-spoke routing and egress controls.
- RBAC matrix: who can create projects, deploy models, manage connections and administer networking.
- Operational runbook: DNS checks, endpoint approval, rollback, monitoring and escalation contacts.
The goal isn’t slower AI development; it’s secure AI development that’s repeatable, so nobody rediscovers private DNS just before a production release.
Last reviewed: October 2026
Sources
- Configure network isolation for Microsoft Foundry (Microsoft Learn)
- Create a Microsoft Foundry project (Microsoft Learn)
- Role-based access control for Microsoft Foundry (Microsoft Learn)
- Azure Private Endpoint private DNS zone values (Microsoft Learn)
- Configure virtual networks for Foundry Tools (Microsoft Learn)
Discover more from Cloud Osprey
Subscribe to get the latest posts sent to your email.
