Prerequisites
- Aviatrix Controller 8.2 or later
- CoPilot 4.31 or later
- DCF enabled with Log Enrichment turned on
- A cloud account onboarded in CoPilot for the Azure subscription hosting the Microsoft Foundry workload
- Microsoft Foundry deployed in BYOVNet mode (Standard Setup with private networking); the managed VNet deployment has no user-accessible enforcement point
How it works
Microsoft Foundry BYOVNet mode places agent compute (Azure Container App compute) into a subnet you provide, delegated toMicrosoft.App/environments.
All outbound tool-call traffic from that subnet routes through Azure’s default
path unless a User Defined Route (UDR) redirects it. Adding a UDR that sends
0.0.0.0/0 to the Aviatrix spoke gateway’s private IP puts all agent egress
in-path for DCF enforcement.
The spoke gateway in this topology is not connected to an Aviatrix Transit. It
enforces internet egress containment directly: the agent can only reach
destinations declared in its DCF allow-list, and everything else is denied and
logged. East-West isolation between the Microsoft Foundry VNet and other
workload VNets is handled by Azure VNet peering policy and is outside the scope
of this guide; connect the spoke to an Enterprise Transit to bring East-West
containment under Aviatrix policy.
Internal resource traffic (connections to Azure Storage, Cosmos DB, AI Search,
and Key Vault) routes through private endpoints inside the VNet and stays on RFC
1918 addresses. This traffic never traverses the spoke gateway.
DCF policy uses two mechanisms to preserve ACA runtime compatibility. Azure
Container Apps platform traffic (container registry pulls, managed identity
token acquisition, ACA infrastructure calls) is permitted with
DECRYPT_NOT_ALLOWED via rules scoped to Azure Service Tag SmartGroups; the
exclusion set stays accurate automatically as Microsoft updates underlying IP
ranges. Tool-call traffic to approved destinations is permitted with optional
DECRYPT_ALLOWED, giving DCF URL-path visibility for supply-chain risk
scenarios.
Procedure
- CoPilot UI
- Terraform
1
Prepare the agent subnet
Before deploying the Microsoft Foundry project, ensure the delegated agent
subnet exists in the target VNet.
- In the Azure Portal, navigate to your VNet and select Subnets.
-
Create a subnet with the following configuration:
-
Confirm the subnet shows delegation to
Microsoft.App/environmentsbefore proceeding.
Use a /24 CIDR for production workloads. A /26 is the minimum for 50
concurrent agent sessions. The recommended size provides headroom for platform
upgrades and scaling events that temporarily increase IP consumption.
2
Deploy an Aviatrix spoke gateway in the cluster VPC
An Aviatrix spoke gateway in the same VPC as your Kubernetes cluster is the
enforcement point where the Aviatrix controller applies containment policy to
MCP server egress traffic.
- In CoPilot, navigate to Cloud Fabric > Gateways > Spoke Gateways and click + Spoke Gateway.
-
Provide the following details:
- In the Instances section, select a subnet in the cluster VPC for the gateway instance.
- Click Save.
3
Configure the UDR on the agent subnet
Create a UDR that blackhole all outbound traffic from the agent subnet. Aviatrix
will program the route later through the Aviatrix spoke gateway, then associate
it with the delegated subnet.
- In the Azure Portal, navigate to Route Tables and click + Create.
-
Provide a name (for example,
foundry-agent-udr) and select the same region and resource group as your Microsoft Foundry VNet. -
After creation, open the route table and select Routes > + Add:
-
Select Subnets > + Associate and associate the route table with the
foundry-agent-subnet.
Do not apply this UDR to the private endpoint subnet. Private endpoint subnets
route directly to their Azure PaaS resources and must not traverse the spoke
gateway.
4
Create SmartGroups
SmartGroups identify the agent workload as a policy source and define Azure
platform traffic that must bypass decryption.
- Navigate to Security > Distributed Cloud Firewall > Groups and select the SmartGroups tab.
-
Create the following SmartGroups:
foundry-agents: the agent workload source- Match type: Subnet
- Account: your Aviatrix Azure account name
- Subnet name: the name of the ACA-delegated agent subnet
aca-platform-svctags: all ACA platform control-plane service tags in a single SmartGroup- Match type: External (Azure)
- Add four entries, one per service tag:
AzureActiveDirectory,MicrosoftContainerRegistry,AzureFrontDoorFirstParty,AzureContainerRegistry - Aviatrix evaluates each entry as a logical OR — traffic matching any tag in the set is covered by the single ACA service tag rule
5
Create WebGroups
WebGroups define the FQDN allow-lists for ACA platform requirements and
permitted agent tool-call destinations.
- Navigate to Security > Distributed Cloud Firewall > Groups and select the WebGroups tab.
-
Create the following WebGroups:
aca-requirements-fqdns: ACA platform FQDNs required for agent startup and operation.
In the list above for Hosted agent container registry, we did not included the
optional *.blob.core.windows.net FQDN as it represents an large data
exfiltration path. Feel free to include it back as needed.
foundry-tool-calls: approved tool call and MCP server destinations- Add the FQDN of each external API, tool endpoint, or MCP server the agent is permitted to reach
- This is the primary allow-list for the agent’s declared tool-call surface
6
Create DCF policies
DCF policies enforce the ACA runtime requirements, permit declared tool
destinations with optional inspection, and block all other egress. Policies are
evaluated top-down; the first matching rule applies.Navigate to Security > Distributed Cloud Firewall > Policy and create the
following rules in priority order:
7
Verify containment
- Deploy a Microsoft Foundry agent and confirm it starts and responds correctly. ACA platform traffic (container registry pulls, managed identity token acquisition) should appear as PERMIT events in CoPilot DCF logs.
-
Invoke a tool call from the agent and confirm the destination appears in
CoPilot DCF logs with action PERMIT and rule
allow-tool-calls. -
Attempt a connection from the agent to a destination not in
foundry-tool-callsand confirm it is denied. The denied connection appears in CoPilot per-connection logs with the rule name that matched. - Navigate to Security > Distributed Cloud Firewall in CoPilot and confirm all five rules are active with the correct source and destination groups.