Skip to main content
When complete, all outbound traffic from the Microsoft Foundry delegated agent subnet will route through a standalone Aviatrix spoke gateway before leaving the VNet. Default-deny DCF policy permits only the Azure Container Apps runtime requirements and declared tool destinations, with selective optional TLS decryption on tool-call traffic and explicit bypass for Azure control-plane paths. This guide covers the standalone topology: a single Aviatrix spoke gateway deployed directly inside the Microsoft Foundry VNet, with no Aviatrix Enterprise Transit required. It is the minimum viable Aviatrix AgentGuard footprint for Microsoft Foundry egress security and a natural on-ramp — the standalone spoke gateway can be attached to an Enterprise Transit later as your network footprint grows, at which point you can add East-West containment across the transit fabric. If you already have Enterprise Transit in place, see Microsoft Foundry: With Transit. For the business case and architecture overview, see AI Agent Workload Containment.

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 to Microsoft.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.
The subnet delegation to Microsoft.App/environments must be in place before the Microsoft Foundry project is deployed. The Microsoft Foundry capability host binds to the subnet at creation time and cannot be changed afterward. However, the UDR applied to that subnet can be updated at any time, including by the Aviatrix controller during spoke gateway HA failover.

Procedure

1

Prepare the agent subnet

Before deploying the Microsoft Foundry project, ensure the delegated agent subnet exists in the target VNet.
  1. In the Azure Portal, navigate to your VNet and select Subnets.
  2. Create a subnet with the following configuration:
  3. Confirm the subnet shows delegation to Microsoft.App/environments before 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.
  1. In CoPilot, navigate to Cloud Fabric > Gateways > Spoke Gateways and click + Spoke Gateway.
  2. Provide the following details:
  3. In the Instances section, select a subnet in the cluster VPC for the gateway instance.
  4. Click Save.
Wait for the gateway status to show Up before continuing. You can monitor progress at CoPilot > Monitor > Notifications > Tasks.
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.
  1. In the Azure Portal, navigate to Route Tables and click + Create.
  2. Provide a name (for example, foundry-agent-udr) and select the same region and resource group as your Microsoft Foundry VNet.
  3. After creation, open the route table and select Routes > + Add:
  4. Select Subnets > + Associate and associate the route table with the foundry-agent-subnet.
Enable Single IP NAT on the spoke gateway, navigate to Cloud Fabric > Gateways > Spoke Gateways in CoPilot and select the gateway. Navigate to Settings > Network Address Translation (NAT) to change the setting.
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.
  1. Navigate to Security > Distributed Cloud Firewall > Groups and select the SmartGroups tab.
  2. 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.
  1. Navigate to Security > Distributed Cloud Firewall > Groups and select the WebGroups tab.
  2. 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:
The ACA platform rules (priorities 2–3) must sit above the tool-call and default-deny rules. ACA platform traffic is evaluated before any agent-level policy. If these rules are missing or ordered below the default deny, the agent container will fail to start.
7

Verify containment

  1. 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.
  2. Invoke a tool call from the agent and confirm the destination appears in CoPilot DCF logs with action PERMIT and rule allow-tool-calls.
  3. Attempt a connection from the agent to a destination not in foundry-tool-calls and confirm it is denied. The denied connection appears in CoPilot per-connection logs with the rule name that matched.
  4. Navigate to Security > Distributed Cloud Firewall in CoPilot and confirm all five rules are active with the correct source and destination groups.