MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-104.1 Design and implement security for multi-agent solutions
Close each agent network access path
Completed by the knowledge check
Learning objective
Enforce network boundaries using private endpoints, VNet integration, public-access restrictions, and resource policies.
Core idea
For a production agent system, draw the inbound and outbound paths separately. A private endpoint gives clients a private route into a service. Virtual network (VNet) integration gives agent execution a route toward dependencies. Restricting public access closes an alternative entrance. Resource policies govern whether deployments are permitted to keep unsafe settings.
Microsoft Foundry combines these mechanisms, but one does not substitute for the others. A private Foundry endpoint does not make every tool private, and an agent running in a delegated subnet still needs permission to access its target. See 4.1.1 for runtime identities and role assignments; this lesson covers reachability and the configuration controls that preserve it.
How it works
Close the inbound public path
An Azure private endpoint is a network interface with a private IP address in your VNet that connects to a supported service through Azure Private Link. Foundry uses a private endpoint to secure access to its account and projects. Configure public network access as Disabled (publicNetworkAccess: Disabled in the resource configuration) when the requirement is private-only access. Enabled from selected IP addresses is a different requirement: it admits specified public source addresses rather than removing public ingress entirely.
Creating a private endpoint and restricting public access are separate decisions. Foundry documents that enabling public access leaves existing private endpoints intact. Removing a private endpoint likewise does not make a resource with public access disabled publicly reachable. Review both the private endpoint connection and the public-access setting.
For hosted agents deployed through azd, the Agent Service VNet page qualifies the agent endpoint as “No, in this preview” for VNet protection: the endpoint URL stays publicly addressable even when backing resources are private. The page identifies per-user session isolation by identity as the tenant-isolation mechanism for that public endpoint. This limitation is scoped to the documented azd hosted-agent preview; it is not a statement that prompt-agent endpoints lack private ingress.
The connection must be approved. A Pending connection is not a usable private route. DNS is equally important: clients use the same Foundry endpoint name, but clients inside the linked network should resolve it to the private endpoint’s IP address. With custom or on-premises DNS, configure resolution for the service’s privatelink name rather than assuming the public resolver knows your private zone.
Put outbound execution on the intended network
Foundry Agent Service uses virtual network injection into a customer-managed subnet for outbound access to private dependencies. The agent subnet must be delegated to Microsoft.App/environments. The configuration walkthrough requires a subnet of /27 or larger; the Agent Service limitations section recommends /24, which provides 256 addresses. A minimum that permits deployment is not the same as recommended capacity planning.
Deploy the Foundry resource in the same Azure region as its VNet. Treat outbound networking as an initial deployment choice: the Foundry networking page says you cannot add injection to an existing deployment or change its delegated subnet through an outbound networking update. Plan a redeployment when that design changes. The Agent Service page explicitly requires hosted-agent injection to be included when the Foundry account is first created.
Private endpoints for Azure AI Search, Azure Storage, and Azure Cosmos DB are not automatically created by the Foundry deployment. Configure each dependency’s private endpoint and DNS, and restrict its public access according to the design. A private entrance to Foundry cannot compensate for a public data store downstream.
Restrict egress without breaking authentication
Use Azure Firewall or another firewall in the outbound path to inspect and control traffic leaving the VNet. Network security groups (NSGs) also need matching rules for required dependencies. Blocking all outbound traffic without considering identity endpoints can prevent provisioning and runtime authentication.
The Agent Service VNet page names control-{region}.identity.azure.net, {region}.login.microsoft.com, and login.microsoftonline.com for firewall allowlisting, with {region} replaced by the deployment region. It also requires the documented Managed Identity fully qualified domain names or the AzureActiveDirectory service tag. A destination list is part of a functioning private design, not evidence that all egress must disappear.
Inspect each tool’s traffic route. For Responses API agents in the Foundry portal and SDK/CLI experience, the networking support table distinguishes private MCP and A2A traffic through your subnet, Azure AI Search through a private endpoint, and Bing Grounding, Websearch, and SharePoint Grounding through public endpoints. Those public tools can function in a network-isolated deployment while still violating a requirement that every data-bearing call remain private. Exclude them when the requirement disallows that route.
Inbound clients and outbound agent execution therefore take separate network paths.
Workflow Agents have a separate limitation: the Foundry page supports their inbound isolation but does not support outbound virtual network injection. Do not extend a prompt-agent or hosted-agent networking design to workflow agents without checking that distinction.
Preserve resource settings with policy
Azure Policy can govern network configuration across deployments. The built-in Azure AI Services resources should restrict network access supports Audit, Deny, and Disabled. Azure AI Services resources should use Azure Private Link supports Audit and Disabled; it is not a deny policy merely because private connectivity is desirable.
The policy catalog also lists Configure Cognitive Services accounts to disable public network access, with Modify and Disabled, and Configure Cognitive Services accounts with private endpoints, with DeployIfNotExists and Disabled. Match the policy’s target resource type and supported effect to the account you govern. These policies address resource configuration rather than a model’s choice of tool destination.
For Resource Manager requests, the deny effect rejects a noncompliant create or update before it reaches the resource provider, returning HTTP 403. Evaluating an existing resource marks it noncompliant; that evaluation does not itself reconfigure the resource or sever an active connection. Distinguish prevention, detection, and remediation when assessing what a policy assignment actually achieves.
Key distinctions and trade-offs
Private ingress versus private egress: A private endpoint serves incoming clients. Delegated-subnet injection serves agent execution reaching dependencies.
Supported tool versus private traffic: Support in a network-isolated deployment does not guarantee that a tool uses a private endpoint.
Audit versus enforcement: Audit finds noncompliance. Deny rejects matching resource changes. Modification and deployment effects serve different remediation purposes.
Network isolation versus authorization: Reachability limits possible paths. It does not establish the principal’s permission to perform an operation.
Architecture / decision scenario
A claims-processing system requires employee ingress and evidence retrieval to stay private. It uses a prompt-agent entry point and Azure AI Search over claim documents, and proposes a hosted specialist deployed through azd.
Disable Foundry public network access, create and approve its private endpoint, and connect employee networks through the intended private route. Verify that the endpoint name resolves to a private IP and that port 443 is reachable from an authorized client. Test from outside that route as well; successful internal access alone does not prove that public access is closed.
Provision injection when creating the Foundry account, with a correctly delegated subnet sized for demand. Create Search and storage private endpoints separately and configure their DNS and access restrictions. Permit documented identity dependencies through the firewall and NSGs. Exclude public-endpoint grounding tools because the processing requirement covers their data-bearing traffic too.
The proposed hosted specialist’s endpoint remains public in the documented azd preview. Restrict callers by identity with agent-scoped Foundry Agent Consumer and isolate sessions per user; see 4.1.1 and 4.1.3 for endpoint authorization. These controls do not make the endpoint private. If the requirement also demands private ingress to the specialist itself, reject this deployment option rather than claiming that private backing resources satisfy it.
Assign network-access policies at the governance scope with the intended supported effects. Test a prohibited resource change to distinguish a real denial from an audit finding. If someone proposes a Workflow Agent as a drop-in replacement, revisit outbound isolation: the documented workflow limitation changes the architecture rather than merely its orchestration syntax.
Common exam traps
- Treating a private endpoint as automatic public-access disablement.
- Expecting Foundry to create all downstream private endpoints.
- Using
/27as the recommended size when the page recommends/24. - Blocking Entra dependencies and diagnosing the failure as an RBAC problem.
- Assuming every supported tool sends traffic through a private route.
- Expecting
Auditor evaluation of an existingDenyviolation to remediate it.
What to remember
Validate ingress, agent egress, dependency endpoints, DNS, and public restrictions as separate controls. Preserve required identity connectivity, check tool and agent-type limitations, and select Azure Policy effects for the behavior you need. A private design is an end-to-end set of verified paths.
Knowledge check
A prompt-agent deployment has an approved Foundry private endpoint, and internal clients resolve its name to the private IP. External clients can still reach it through the public endpoint. Which setting closes that path?
You are about to create a Foundry account whose agents must reach Azure AI Search and Azure Storage over private routes. Which plan covers the agents’ outbound path?
Microsoft.App/environments , and injection cannot be added to an existing deployment — it is chosen when the account is created. Foundry does not create the Search and Storage private endpoints, so each needs its own endpoint and DNS. Private ingress to Foundry serves incoming clients, not the agents’ outbound calls.A network-isolated agent can use Bing Grounding, but a requirement says every data-bearing tool call must stay on private routes. Which action meets that requirement?
An Azure Policy assignment uses Deny for a network-access rule. An existing resource already violates the rule. What does policy evaluation alone do to that resource?
Deny rejects a matching noncompliant create or update before it reaches the resource provider, returning HTTP 403. Evaluating an existing resource only records noncompliance; changing settings or adding endpoints is the work of Modify and DeployIfNotExists effects.A specialist uses the documented azd hosted-agent preview with private backing resources. Its own endpoint must also have private ingress. How should this deployment option be assessed?
azd hosted-agent preview, the agent endpoint stays publicly addressable. Identity-based endpoint access and per-user session isolation are useful controls, and private backing stores protect the data, but none gives the endpoint itself a private ingress path.