Introduction
Securing Foundry identities and private connectivity requires two cooperating controls: Microsoft Entra ID and role-based access control (RBAC) authorize an operation, while network configuration provides an allowed path to its destination. Apply both controls to each caller separately. The infrastructure creator, developer, project managed identity, and application principal perform different work; a successful administrator session does not validate all of them.
Design two paths explicitly: callers reaching Foundry, and Foundry workloads reaching dependent services. For each path, identify the principal, operation, destination, permission scope, name resolution, and connectivity evidence. This architecture makes failures diagnosable without granting broad access simply to make a request succeed. It assumes the resource/project foundation described in AI-300: Provisioning Foundry Resources and Projects and stops short of a full Agent Service network-injection deployment.
Architecture Overview
A Foundry resource is an administrative and security boundary; a project is a narrower scope for development and Foundry APIs. Permissions are assigned to principals at explicit scopes. Keep that authorization hierarchy separate from the network topology: a project boundary is not a substitute for validating a caller's route.
Use the following recommended design record before selecting roles or changing network settings:
| Path | Identity to establish | Authorization question | Connectivity question |
|---|---|---|---|
| Provisioning operator to Azure resources | Deployment principal | Which management operations and role assignments are permitted? | Can the deployment environment reach its required services? |
| Developer to Foundry | Signed-in developer | Can this person perform the intended project data actions? | Does this workstation resolve and reach the private service? |
| Application to Foundry | Runtime principal | Can the application perform its precise invocation task? | Does the application host have the required private path? |
| Foundry workload to a dependency | Identity used by that operation | Can that identity read or write the intended data? | Can the workload reach the dependency through the approved path? |
This record should name actual principal identifiers, rather than using one generic label such as “the managed identity.” It is a proposed review aid, not a built-in Foundry object.
Core Components
Current roles and scopes
Current names include Foundry User, Foundry Project Manager, Foundry Account Owner, and Foundry Owner. Foundry User supplies developer data actions; Foundry Account Owner covers administration without developer data actions; Foundry Owner combines broad administration and development. Foundry Project Manager has project-oriented permissions and conditional role-assignment capability. Verify the required operations and data actions at the intended scope rather than inferring every permission from a role name.
Microsoft's enterprise example separates developers with Foundry User at project scope and Reader at resource scope. Azure AI Developer instead applies to Azure Machine Learning workspaces and Foundry hubs; it is not the current Foundry-project developer role. This distinction matters when adapting older infrastructure files or access requests.
Creator, project identity, and runtime caller
Creator permissions do not automatically establish application access. Check the project's managed identity separately from the developer. Microsoft's minimum-start guidance assigns Foundry User on the Foundry resource to both the user principal and project managed identity. Access to external resources needs its own permissions.
For application design, first establish which identity a selected operation actually uses. The runtime principal calling Foundry and the identity used by Foundry to access a tool or data source might be different. Record that selection with the connection configuration and test it; do not grant a storage permission to the developer and assume it has qualified a server-side retrieval path.
RBAC applies with Microsoft Entra ID authentication. Key-based access bypasses those role restrictions. Use an Entra-authenticated request when validating a scoped permission design; a successful key-authenticated call does not demonstrate that the intended principal has the required access.
Private inbound connectivity and DNS
For private inbound access, configure the account's private endpoint and public network access setting deliberately. The endpoint connection must be approved. Clients keep the service connection details; Domain Name System (DNS) resolution from the connected network directs them to the private endpoint address. Custom DNS requires corresponding resolution configuration.
The practical implication is that a copied endpoint value is insufficient evidence. Record where the caller runs and which resolver it uses. Test from the actual application host or a representative host on the same intended path, including any on-premises connection.
Outbound dependencies
An inbound private endpoint does not configure every outbound connection. Foundry documents separate outbound network isolation, including Agent client virtual network injection. Dependency private endpoints for Azure Storage, Azure AI Search, and Azure Cosmos DB are not automatically created with the Foundry resource. Tool traffic also varies: a supported tool can still use a public endpoint.
Build a dependency inventory before promising that an application has exclusively private traffic. For each tool, retrieval source, storage operation, and telemetry destination actually used, record its permitted route and owning team. A connection's existence is configuration evidence; follow it with an operation that demonstrates useful access.
How Components Work Together
Consider an illustrative internal support assistant that retrieves approved documents. The developer creates and tests application assets, a runtime principal invokes the application, and a selected service identity reads the retrieval source. An infrastructure operator maintains network resources. These are responsibilities in the example, not claims that one role or identity serves every Foundry workload.
Start by reviewing the caller-to-Foundry path. Check the private endpoint approval, then name resolution and transport from the caller's network. Microsoft's network guide uses the following diagnostic forms. Replace the placeholders; these examples were not executed for this article:
nslookup <your-foundry-endpoint-hostname> Test-NetConnection <private-endpoint-ip-address> -Port 443
The second command is a PowerShell diagnostic. Private address resolution and a successful port test establish different facts; neither proves authorization or application behavior. Next, use the intended principal to perform the smallest harmless operation that exercises the required Foundry capability.
Then review the assistant-to-data path independently. Confirm the connection's authentication choice, destination permissions, resolver behavior, and allowed route from the workload environment. Read a known non-sensitive test record and check the expected retrieval result. A model response alone is weak evidence: the assistant might answer without ever accessing the intended data source.
Finally, recommend a negative test for a deliberately ungranted operation or out-of-scope test resource. Record why it should fail and retain the result alongside the successful test. Choose a harmless test; do not alter production permissions or expose real documents merely to demonstrate denial.
Design Considerations
Separate diagnosis from remediation
Use the observed failure to select the next check, not to justify broad permission or network changes:
| Observation in the example | Recommended next evidence |
|---|---|
| Endpoint resolves to an unexpected address | Resolver configuration and private DNS linkage from that caller |
| Transport fails after correct resolution | Endpoint approval, route, and network filtering |
| Service returns an authorization failure | Actual authenticated principal, requested action and effective scope |
| Application connects but retrieval fails | Dependency identity, permission and outbound path |
| Administrator succeeds while runtime fails | Differences between the two principals and host environments |
Keep error interpretation provisional until these checks agree. A status code by itself should not collapse identity, networking, and application configuration into one diagnosis.
Plan isolation before rollout
The current networking guide says outbound injection cannot be added to an existing Foundry deployment and the delegated subnet cannot simply be swapped. Decide the required topology before committing to the environment. Feature and tool support must also be checked for the current Foundry experience; classic behavior is not a reliable substitute.
For any access change, recommend preserving a tested administrative path and a recovery procedure before disabling an existing route. Review broader resource-scope grants for their effect on other projects. Keep credentials out of diagnostic notes, and retain only the principal identifiers, operation, scope, destination and result needed to assess the design.
Common Mistakes
- Assigning a familiar Azure Machine Learning role without checking the current Foundry permission surface.
- Treating the creator, project managed identity and runtime caller as one principal.
- Qualifying RBAC with an API-key request that bypasses its restrictions.
- Declaring private access complete after creating an unapproved endpoint or testing only from an administrator's workstation.
- Assuming private inbound access also supplies every dependency's outbound path.
- Approving tools on feature support alone without reviewing their traffic destination.
Certification Relevance
For AI-300 learning, practice explaining one request in both directions: who calls Foundry, and who accesses the downstream data. Identify the authorization action and network evidence at each step. This supports architecture decisions and targeted troubleshooting without requiring a memorized deployment script or an invented universal role assignment.
Conclusion
A secure Foundry design makes identities, scopes, and traffic paths explicit. Validate private resolution and connectivity from the intended callers, then verify authorized operations with the actual principals. Repeat that reasoning for dependent services so successful access demonstrates the complete application path rather than one administrator's session.