Microsoft AI-103: Private Networking and Managed Identity

Security scenarios in AI-103 frequently combine two separate questions: how traffic reaches Microsoft Foundry and connected data services, and which identity is authorized to use those resources. Private networking answers the first question. Managed or Microsoft Entra identities and Azure RBAC answer the second. A secure architecture needs both where the requirements call for them.

The exam blueprint explicitly mentions managed identity, private networking, keyless credentials, and role policies. Those controls fit naturally into the broader Microsoft exams ecosystem, but candidates should understand the architecture rather than memorizing a deployment wizard.

Private inbound access and private egress are different decisions

A private endpoint can restrict how callers reach a Foundry endpoint, but that does not automatically mean the agent’s outbound traffic is isolated. Foundry networking options separate inbound access from egress behavior. If the requirement is full isolation, the architecture must consider how agents reach storage, search, databases, tools, and other dependencies as well as how users reach Foundry.

Current Foundry options include bring-your-own virtual network and managed virtual network approaches for isolated scenarios. The choice affects who manages address space, routing, private endpoints, and network dependencies. Public networking can still be reasonable for low-risk prototypes or environments protected by other controls; the exam answer depends on the stated isolation requirement.

Do not add private networking merely as a security slogan. It increases deployment and troubleshooting complexity, so the requirement should justify it: regulatory constraints, data-residency rules, private data services, or a policy that forbids public network paths.

Private endpoints keep resource access off the public internet

When a data service such as Azure AI Search, Storage, or Cosmos DB has public access disabled, the Foundry environment needs a private path to it. Private endpoints and private DNS provide that connectivity. Each dependency must be considered; securing the Foundry account while leaving the data store publicly reachable may not meet the intended architecture.

DNS is part of the design. A private endpoint is useful only if workloads resolve the service name to the private address from the relevant network. Many “network failures” are actually name-resolution or route problems. A professional deployment validates connectivity from the runtime environment instead of assuming the resource configuration is sufficient.

Tool connectivity can vary by tool type. Some tools reach Azure resources that support private endpoints, while others depend on managed services or external endpoints. The network design should be based on the actual tools and dependencies used by the agent.

Use identities instead of embedded secrets

Managed identity and Microsoft Entra-based authentication let workloads obtain tokens without storing long-lived credentials in application settings or prompts. That reduces secret rotation work and the risk that a credential is exposed through source code, logs, or model-visible context.

The identity still needs authorization. A project or agent identity should receive the minimum data-plane roles required for the resources it must access. Network reachability does not grant permission, and a valid identity without a private route still cannot reach a network-isolated service. This is why exam scenarios often combine networking and RBAC details.

The terminology is grounded in Microsoft Entra ID. For authorization design, Azure RBAC is the useful mental model: identify the principal, identify the resource, grant the narrow role at the narrowest practical scope, and verify that the runtime is actually using that identity.

Distinguish project identity, agent identity, and user identity

Different Foundry deployment patterns can involve different principals. Project managed identity may access project resources. Hosted agents can receive dedicated Entra identities. End users may also authenticate to the application and, in some designs, their delegated context may matter for downstream authorization. Do not assume one identity should perform every operation.

A dedicated agent identity can improve least privilege because each deployed agent receives only the roles its tools require. A shared project identity can simplify some managed scenarios. Delegated user authorization is appropriate when the downstream system must enforce each user’s own permissions. The correct pattern depends on whether the action represents the application, the agent workload, or the human user.

Whichever identity model is chosen, record it in the architecture and in audit logs. Incident responders should be able to tell which principal accessed a resource and on whose behalf.

Use network and identity controls with agent-level guardrails

Private networking and RBAC do not replace agent safety controls. An agent can be fully private and still misuse a tool it is legitimately authorized to call. Conversely, a well-prompted agent can still expose data if the underlying search service returns documents the current user should not see.

Identity-aware application policy and, where appropriate, Conditional Access protect different layers. Agent guardrails constrain model behavior and tool use. RBAC constrains resource permissions. Network isolation constrains paths. Data filters constrain what a query returns. Defense in depth comes from assigning each control a specific responsibility.

Approval workflows are still appropriate for high-impact actions even when the identity is valid. Authentication proves who is calling; authorization proves what the caller may do; approval can prove that this particular action was intentionally accepted.

Troubleshoot security scenarios in the right order

When a Foundry workload cannot reach a private resource, first check network path and DNS, then identity, then the resource role assignment, then service-specific firewall or policy settings. Mixing these layers can waste time because each one produces a different class of failure.

When access is unexpectedly broad, reverse the process: inspect role scope, data filters, tool exposure, and network reachability. Remove unnecessary privileges before adding more prompt instructions. Security should be enforced by controls the model cannot simply talk around.

For AI-103, the exam-ready mental model is straightforward. Private networking determines where traffic can flow. Entra identity determines who or what is calling. RBAC determines what that principal can do. Keyless authentication avoids embedded secrets. Agent guardrails and approvals constrain how permitted capabilities are used. A correct production design aligns all of those layers with the actual business risk.

Document the security dependency graph

Private architectures can fail because one overlooked dependency still needs public access. Maintain a dependency graph for model endpoints, search, storage, databases, telemetry, container registries, tool endpoints, and external services. For each edge, record whether the path is public, restricted, or private and which identity is used.

That documentation makes reviews and migrations much easier. When a security policy changes, the team can see which dependencies are affected instead of rediscovering the network and identity model through failed deployments.

Test isolation as an end-to-end property

A private architecture should be validated from the runtime that will actually execute the agent. Confirm name resolution, routes, private endpoints, firewall rules, and data-plane authorization from that environment. A resource can look correctly configured in the portal while the agent still resolves a public address or lacks the role required to read data.

Negative testing is equally valuable. Verify that public access is genuinely blocked where the requirement says it should be, that an identity without the required role receives a denial, and that one agent cannot use another agent’s resources merely because they share a project. Security tests should prove the boundaries, not only the success path.

Operational tooling must be considered too. Telemetry, deployment registries, package sources, and administrative endpoints can create hidden public dependencies. Document which services require connectivity and whether they support private access in the chosen deployment model. Network isolation is only as strong as the least-controlled path the workload still depends on.

Keep data-plane permissions explicit

Azure resource roles used to configure a service are not always the same roles the running workload needs to access data. Separate control-plane administration from data-plane access. The identity that deploys an agent may be allowed to create resources, while the agent identity still needs a specific search, storage, or database role to read operational data.

Scope matters as much as role name. Granting a powerful role at subscription scope may make a prototype work, but it creates unnecessary exposure. Prefer the narrowest practical resource or resource-group scope and verify the exact data operation the agent needs. Least privilege is easier to maintain when role assignments are part of infrastructure code and reviewed with the application change.

Keyless authentication also improves incident response. If a workload identity is compromised, operators can remove or narrow its role assignment without rotating a shared secret across multiple applications. That separation of identity from credentials is a core reason managed identities are valuable in production Foundry designs.

Use infrastructure as code for repeatable controls

Private endpoints, DNS zones, subnet delegation, role assignments, and network policies are easy to configure inconsistently by hand. Infrastructure as code makes the intended posture reviewable and repeatable across development, test, and production. Security teams can review the same definitions that deployment automation applies.

Repeatability also improves exam reasoning: the correct architecture is not only secure once, but capable of being recreated and verified. Treat identity and network configuration as versioned parts of the application, with tests that confirm both allowed and denied access paths after each deployment.

Automate network and identity verification

Deployment pipelines should test the controls that make a private architecture private. From an environment that mirrors the agent runtime, verify private DNS resolution, expected routes, denied public access, and the exact data-plane operations permitted to the managed identity. Include at least one negative test for an identity or path that should fail. These checks catch drift that a successful infrastructure deployment alone cannot reveal. They also turn network isolation and least privilege into repeatable acceptance criteria, so a later subnet, DNS, or role-assignment change cannot quietly reopen a path the design intended to close.