Azure AI Foundry · FedRAMP Moderate engineering

Configure Azure AI Foundry private endpoints and identity

A private AI architecture needs verified DNS, a reachable private service path, restricted public access, authorized identities, and controlled egress. Configure those independently and test both allowed and denied traffic.

By Flat Spell Technologies · Technical review: October 7, 2026

1. Establish the cloud and resource inventory

Start with an approved Foundry resource, a model deployment, client runtime, VNet, private endpoint subnet, and private DNS design. Inventory Search, Storage, Cosmos DB, Key Vault, telemetry, and every tool backend that the application or agent will use. Confirm that each service and feature is in the approved provider package and system boundary.

Choose the Azure CLI cloud deliberately. AzureCloud and AzureUSGovernment have different management endpoints, token audiences, service names, and available models. Use approved operator or workload authentication; do not put client secrets or keys in templates.

az cloud set --name AzureUSGovernment
# Authenticate with your approved operator/workload method.
az account set --subscription "$APPROVED_SUBSCRIPTION_ID"
az network private-link-resource list --id "$FOUNDRY_RESOURCE_ID"

The last command discovers the resource’s Private Link groups and required zones. Use those results and the selected-cloud documentation instead of copying commercial DNS suffixes into Government. Record account kind and API generation; classic hub projects and current Foundry projects have different setup paths.

2. Create an account private endpoint and DNS zone group

The downloadable Bicep module attaches to an existing Cognitive Services account, uses the documented account group, and accepts pre-created private DNS zone resource IDs. Deploy it into the private endpoint subnet, not the dedicated agent runtime subnet. It does not create the account, model, DNS links, role assignments, or an agent project.

param accountResourceId string
param privateEndpointSubnetId string
param privateDnsZoneIds array

// Private Link service connection excerpt:
privateLinkServiceId: accountResourceId
groupIds: ['account']
// DNS zone group references the approved zones by resource ID.

View the private endpoint Bicep module on GitHub. Compile and review it before deployment. Use az deployment group what-if with your approved parameters to inspect the planned change. The module is an attachment component, not a complete Foundry provisioning template.

Microsoft’s commercial-cloud documentation lists privatelink.cognitiveservices.azure.com, privatelink.openai.azure.com, and privatelink.services.ai.azure.com for Foundry. Select only the zones required for your resource and endpoints. Government zones must be verified from the Government resource metadata and documentation.

Link the relevant zones to the client VNet. For custom or on-premises DNS, configure conditional forwarding through an appropriate Azure DNS Private Resolver or other approved DNS architecture. Verify the full endpoint hostname resolves to the private endpoint NIC address from the real client runtime.

3. Disable public and key-based access where supported

After verifying private connectivity, set public network access to Disabled on each supported resource through reviewed infrastructure configuration. A private endpoint existing alongside an enabled public endpoint is not public-path isolation. Use deny-by-default network rules; review any trusted-service bypass as an explicit exception.

For a supported account that uses only Entra-based access, disable local authentication. This may break existing key-based connections, so migrate and verify all callers first. Export the account settings as evidence:

az resource show --ids "$FOUNDRY_RESOURCE_ID"   --query '{publicNetworkAccess:properties.publicNetworkAccess,disableLocalAuth:properties.disableLocalAuth}'

Run TLS and application-level inference tests using the approved identity. TCP reachability alone does not validate TLS, access, model permissions, or the application. A cryptographic control review must also verify the service’s documented cryptographic implementation and applicable requirements; HTTPS alone is not a FIPS attestation.

4. Assign deterministic runtime identities

Use a specific managed identity or an approved workload identity in production. Broad credential chains can unexpectedly fall back to developer credentials. Grant inference access at the intended resource or project scope; administrator access does not automatically grant data-plane inference access.

Current Foundry model documentation uses Cognitive Services User for the relevant inference path. Azure OpenAI-specific and project/agent APIs can require different roles. Verify the exact role for the API being called. Search retrieval, blob ingestion, Cosmos DB state, and tool execution need their own roles; do not solve denied access by granting subscription Owner.

The documented Government project client uses https://ai.azure.us/.default. Do not reuse that scope for Azure Search or a classic OpenAI endpoint. Match token audience, issuer, resource host, API generation, and cloud.

5. Configure agent outbound networking separately

For a managed agent, inbound Private Link does not secure the outbound path from agent compute to tools and stores. Microsoft documents Standard setup with customer-managed Storage, Search, and Cosmos DB, plus a delegated agent subnet for private networking. Create the required private endpoints for those dependencies separately.

The current Standard-networking flow specifies delegation to Microsoft.App/environments, a supported private address range, and a dedicated agent subnet. Documentation describes a /27 minimum in the portal flow and recommends /24 sizing; choose capacity with the current networking guide and expected concurrency. Do not share the delegated subnet among Foundry resources.

Plan outbound networking at creation time: current documentation says existing resources cannot simply be retrofitted with VNet injection. Government documentation lists hosted agents as unavailable; commercial hosted-agent examples should not be transplanted into a Government design.

Use route tables, firewall rules, and documented platform dependencies to restrict egress. A NAT gateway provides outbound connectivity, not an allowlist. Record cloud-specific identity and platform destinations rather than enabling arbitrary Internet access.

6. Run positive and negative acceptance tests

View the read-only DNS and TCP diagnostic script on GitHub. Supply the endpoint hostname and expected NIC IP, then execute from the actual client network. It checks exact DNS resolution and TCP reachability; it does not certify TLS or model access.

Private caller: resolve the endpoint to approved private IPs, validate TLS, acquire the correct token, and complete a synthetic inference request.
Public caller: with a valid scoped identity, verify the public network path is denied. An authentication failure alone does not prove a network control.
Unauthorized identity: from the allowed network, verify an identity without inference permissions cannot use the model.
Tool egress: verify an approved backend works and an unapproved destination fails.
Dependencies: repeat access and public-path tests for each store and telemetry service.

Keep evidence of endpoint approvals, DNS answers, account settings, role scopes, firewall decisions, and test results. Continue with permission-aware RAG or controlled agent tools.

Sources and technical review

Technical review: October 7, 2026. Microsoft documentation changes over time; recheck feature availability and your authorization package before deployment.

Confirm the offering and applicable authorization status in the FedRAMP Marketplace and review the provider package and your system security plan. Service availability is not an authorization determination.