“Private endpoint enabled” is not a complete architecture
Enterprise teams often treat private networking as a checkbox at the end of an AI proof of concept. By then, the application may already depend on public model endpoints, external package sources, unrestricted web tools, public DNS resolution, or telemetry paths that were never documented.
Microsoft Foundry supports network isolation, including private endpoints and virtual-network patterns. The secure design still begins with a data-flow and dependency map.
Draw three boundaries
Microsoft’s networking guidance separates three concerns:
- Inbound access to the Foundry resource and projects.
- Outbound access from Foundry to Azure services and other dependencies.
- Outbound access from the agent client to private data sources, approved services, or internet destinations.
Treat these as independent questions. Restricting inbound access does not automatically constrain every outbound route.
For each flow, record the source identity, destination, protocol, data classes, name-resolution path, authorization method, logs produced, and failure behavior.
Start with the workload, not the subnet
Identify what the AI system actually touches:
- prompts and uploaded files;
- retrieval stores and source documents;
- business APIs and tool results;
- conversation or agent state;
- evaluation datasets and outputs;
- traces, logs, metrics, and support exports;
- model and package downloads;
- administrator and developer access.
Sensitive information can appear in telemetry and evaluation artifacts even when the primary database remains private. Include operational data in the boundary.
Inbound access and DNS
Public network access can be disabled or restricted, with private endpoints used to reach Foundry from approved networks. DNS is a functional part of this control. From the intended virtual network, the Foundry hostname must resolve to the private endpoint address. Custom or on-premises DNS needs the appropriate delegation or records.
Validate resolution from the same network path used by developers, CI/CD, applications, and operators. A successful portal configuration is not proof that every client follows the private route.
Also test from an unapproved network. The expected failure is part of the acceptance evidence.
Outbound dependencies and agents
An application that cannot reach its retrieval store, identity provider, monitoring service, or tool APIs is not production-ready. An application that can reach everything is not isolated.
Use an allow-list derived from the mission architecture. Private Link and private endpoints can protect supported Azure PaaS dependencies. Agent networking may use a delegated subnet and virtual-network injection to reach customer-defined dependencies.
Decide explicitly whether web access is required. If it is, route it through an inspected, policy-controlled path and treat retrieved internet content as untrusted input. If it is not required, do not leave broad egress available “for later.”
Identity remains the primary authorization boundary
Networks narrow reachability. They do not determine whether a user or agent may read a customer record or execute a business action.
Use Microsoft Entra identities and least-privilege role assignments. Separate deployment, operation, evaluation, and data-access duties. For tool calls, preserve the requesting identity where the workflow requires user-level authorization; otherwise use a dedicated workload identity with a narrow purpose.
Avoid shared keys in application configuration when managed identity is available. Rotate and monitor any credential that cannot be removed.
Validate the negative paths
A private deployment needs tests that prove controls reject the wrong behavior:
- public access fails when disabled;
- private DNS resolves correctly from each approved environment;
- an unauthorized identity cannot access the project or downstream data;
- unapproved outbound destinations are unreachable;
- logs do not capture prohibited content;
- an agent fails safely when a private dependency is unavailable;
- operators retain an approved incident and recovery path.
Repeat these tests after network, DNS, agent-runtime, or dependency changes.
Private is an operating property
Network isolation adds deployment and support complexity. Capture the architecture as code, monitor private endpoint and DNS health, and assign ownership for policy changes. Plan how emergency access works without introducing a permanent bypass.
The credible statement is not “we use private endpoints.” It is: we know every relevant path, enforce the intended routes and identities, and continuously test that unauthorized paths fail.
Official reference
Microsoft documents inbound, outbound, agent-client, Private Link, and DNS considerations in Configure network isolation for Microsoft Foundry.