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
- An Aviatrix Enterprise Transit Gateway deployed in the same Azure region as the Microsoft Foundry VNet
- 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 (hosted agent Micro VMs and the single-tenant data proxy) 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 Microsoft Foundry VNet is peered to your Aviatrix Enterprise Transit. This
gives you two enforcement surfaces: internet egress is controlled at the spoke
gateway boundary, and East-West traffic between the Microsoft Foundry spoke and
adjacent workload spokes is controlled by SmartGroup policy. A compromised agent
cannot pivot to adjacent internal workloads any more than it can reach arbitrary
internet destinations.
Internal resource traffic (the data proxy connecting 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.
Aviatrix only enforces policy on external egress and cross-spoke traffic.
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
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
Attach the spoke gateway to your Enterprise Transit
- In CoPilot, navigate to Cloud Fabric > Gateways > Spoke Gateways and select the gateway you just deployed.
- Select Actions > Attach to Transit and choose your Enterprise Transit Gateway.
- Confirm the attachment completes and the spoke shows as Up in the transit topology.
4
Configure the UDR on the agent subnet
Create a UDR that routes all outbound traffic from the agent subnet 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.
5
Create SmartGroups
SmartGroups identify the agent workload as a policy source, define Azure
platform traffic that must bypass decryption, and set the East-West boundaries
between the Microsoft Foundry spoke and adjacent workload spokes.
- 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
adjacent-spokes: other workload VNets in the transit fabric the agent must not reach- Match type: CIDR
- Add a CIDR entry for each adjacent spoke VNet CIDR that requires East-West deny protection
6
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 operationIn 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
7
Create DCF policies
DCF policies enforce the ACA runtime requirements, permit declared tool
destinations with inspection, and block all other egress and East-West traffic.
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:
8
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 FlowIQ.
-
Invoke a tool call from the agent and confirm the destination appears in
CoPilot FlowIQ 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. -
Attempt a connection from the agent subnet to an adjacent spoke VNet CIDR and
confirm it is denied by the
deny-east-westrule. - Navigate to Security > Distributed Cloud Firewall in CoPilot and confirm all six rules are active with the correct source and destination groups.