✨ The Containment Era is here. Secure AI workloads before they breach. →The Containment Era is here. →The Containment Era is here. →Explore ✨
The Microsoft Foundry hosted agent with no enforcement point.
Microsoft Foundry hosted agents in BYOVNet mode gives them access to enterprise data. It does not give them a network enforcement point. All tool calls, MCP server connections, and Code Interpreter potentially egress through a delegated subnet to the open internet with no in-path inspection. closes that gap — Communication Governance at every agent connection, selective TLS decryption on tool calls, East-West lateral movement containment, Service Tags awareness and policy-as-code that deploys in the same pipeline as the agent.
The Microsoft Foundry hosted agent with no enforcement point.
Microsoft Foundry hosted agents in BYOVNet mode get a VNet boundary and dedicated subnet — but no in-path enforcement point. Every tool call, MCP server connection, and Code Interpreter session potentially exits to the open internet with no inspection, no allowlist enforcement, and no audit trail beyond Azure Monitor flow logs. The blast radius of a compromised agent is bounded only by what its identity can reach. closes that gap — Communication Governance at every agent connection before it leaves the spoke VNet.
Prompt injection via MCP
Malicious instruction in an MCP tool response redirects the agent toward data collection and exfiltration. Indistinguishable from a legitimate tool response at the content layer.
Data access
Agent uses legitimate managed identity access to collect documents from SharePoint, Azure Blob Storage, or internal APIs. Valid credentials, authorized channel — invisible to detection.
Exfiltration attempt
Agent calls HTTPS POST to attacker-controlled domain. TCP SYN traverses the Aviatrix Spoke Gateway via the UDR. Destination not in DCF allowlist — connection never completes.
Lateral movement attempt
Agent attempts to reach adjacent spoke private endpoints — databases, internal APIs outside the approved tool-call list. East-West SmartGroup deny fires structurally.
Audit trail
DENY log in CoPilot FlowIQ — workload identity, destination FQDN, rule name, timestamp. Continuous evidence for HIPAA, SOC 2, EU AI Act Article 9, and DORA.
Three enforcement layers. One policy model.
BYOVNet gives you the boundary — Communication Governance starts at the UDR
Microsoft Foundry BYOVNet mode places Hosted Agents in a customer-managed VNet via subnet delegation to Microsoft Foundry hosted agent (Microsoft.App/environments). The delegated agent subnet has a default-allow egress path to the internet. Aviatrix deploys a Spoke Gateway in the same Foundry spoke VNet — same Azure region, required by Microsoft — and programs a User-Defined Route (UDR) on the agent subnet with a 0.0.0.0/0 next-hop pointing to the Spoke Gateway private IP. Every non-private-endpoint egress flow traverses DCF inline. The agent container has no sidecar, no agent, no code change.
Communication Governance at the workload — blast radius bounded by policy, not detection speed
The ruleset is the critical design decision. Azure control-plane traffic — AAD token acquisition, MCR image pulls, ACA infrastructure calls — is explicitly bypassed via DECRYPT_NOT_ALLOWED rules scoped to ACA FQDNs and four Azure Service Tags: AzureActiveDirectory, MicrosoftContainerRegistry, AzureFrontDoorFirstParty, AzureContainerRegistry. Service Tag SmartGroups auto-update as Microsoft changes the underlying IP ranges — no manual maintenance. Tool-call egress is optionally decrypted and inspected. East-West SmartGroup policy denies lateral movement. The agent runtime never sees a certificate it does not trust. Communication Governance defines which destinations the agent can reach, on which protocols, with what certificate posture — and enforces that definition before any connection completes, across both internet-bound tool-call traffic and East-West paths to adjacent spokes. It does not govern prompt content, tool argument validation, or model response filtering; Microsoft Foundry Guardrails govern that layer.
On-premises · Transit VNet · Foundry spoke VNet · UDR enforcement · Selective TLS decryption · East-West containment
Layer 01 — Communication Governance with selective TLS
Every agent connection subject to defined policy before it completes
The Distributed Cloud Firewall evaluates a ruleset first-match at the Spoke Gateway. Microsoft Foundry hosted agents (FQDNs and Service Tags) are explicitly permitted. Approved tool call destinations are allowlisted per agent deployment. An East-West deny rule prevents lateral movement from the Microsoft Foundry spoke to adjacent workload VNets — a distinct rule from the egress ruleset, enforced on the same gateway with no additional hardware. TLS decryption is possible on tool-call traffic with a CA distributed to the agent container trust store via Key Vault. Communication Governance defines which destinations Microsoft Foundry hosted agents can reach, on which protocols.
Layer 02 — East-West containment
Lateral movement from agent subnet is structurally denied
A SmartGroup East-West deny rule prevents traffic from foundry-agents to other-spoke-resources. A compromised agent cannot reach databases, internal APIs, or adjacent spoke workloads — even if those resources are reachable by other transit spokes. Enforced before any packet is forwarded. This layer is only active for Transit-attached deployments; standalone Spoke Gateway deployments do not have adjacent spoke resources in scope.
Layer 03 — Policy as code
Communication Governance policy versions and deploys with the agent
The DCF WebGroup allowlist, SmartGroup definitions, and UDR configuration are Terraform-native — they live in the same repository as the agent configuration and update in the same pipeline run. When an agent adds a new MCP server or tool, the Communication Governance policy updates in the same commit. No out-of-band network team ticket. No pressure to over-permit because the change process is slow.
DCF Ruleset — Rules in Priority Order
First match wins. Deploy all rules in monitor mode first; promote to enforcement rule by rule after validating against production traffic. Every rule logs to CoPilot DCF Monitor.
| Pri | Rule | Destination | Action | TLS / Notes |
|---|---|---|---|---|
| 1 | deny-threat-intel | default-threatgroup | DENY | Highest priority. Blocks known malicious destinations, C2 infrastructure, newly registered domains before any permit rule evaluates. |
| 2 | allow-aca-fqdn | aca-requirements-fqdns | PERMIT | DECRYPT_NOT_ALLOWED — ACA platform FQDNs (MCR, AKS infra, managed identity, AAD). Microsoft certificate pinning requires no decryption. Must precede default-deny. |
| 3 | allow-aca-svctag | aca-requirements-svctag SmartGroups | PERMIT | DECRYPT_NOT_ALLOWED — Service Tags: MicrosoftContainerRegistry, AzureFrontDoorFirstParty, AzureContainerRegistry, AzureActiveDirectory. Auto-updates with Microsoft IP changes. |
| 4 | allow-tool-calls | foundry-tool-calls WebGroup | PERMIT | TLS decryption is optional on the rule that references this object. DECRYPT_ALLOWED — Approved MCP server FQDNs, sanctioned REST APIs, Code Interpreter destinations. Operator-maintained WebGroup. |
| 5 | default-deny-internet | Any unlisted FQDN / IP | DENY | All non-private-endpoint egress not matched above. Every deny logged to CoPilot FlowIQ with rule name and destination. |
| 6 | deny-east-west | other-spoke-resources | DENY | Lateral movement from foundry-agents to adjacent spoke private endpoints and workloads. Transit-attached deployments only. Structurally prevents East-West pivot even if resources are reachable by other spokes. |
SmartGroup and WebGroup Objects
Six objects defined in the Aviatrix Controller, referenced by name in the ruleset. Service Tag SmartGroups auto-update as Microsoft changes IP ranges — no manual maintenance required.
| Object | Type / Scope / Purpose |
|---|---|
| foundry-agents | Subnet SmartGroup — matches the hosted agent subnet CIDR in the Foundry spoke VNet. Source identity for all six DCF egress rules. |
| aca-requirements-fqdns | WebGroup — ACA platform FQDNs required for Hosted Agent runtime. DECRYPT_NOT_ALLOWED. Includes: mcr.microsoft.com, *.data.mcr.microsoft.com, packages.aks.azure.com, acsmirror.azureedge.net, *.identity.azure.net, login.microsoftonline.com, *.login.microsoftonline.com, login.microsoft.com, *.blob.core.windows.net. |
| aca-requirements-svctag | Four SmartGroups on Azure Service Tags using external = "azureips". One per tag: MicrosoftContainerRegistry, AzureFrontDoorFirstParty, AzureContainerRegistry, AzureActiveDirectory. Auto-update as Microsoft changes underlying IP ranges. |
| foundry-tool-calls | WebGroup — approved tool-call destinations: sanctioned MCP server FQDNs, approved external REST API endpoints, Code Interpreter permitted destinations. Operator-maintained. Applied with optional DECRYPT_ALLOWED. |
| other-spoke-resources | SmartGroup — matches private endpoints and resources in adjacent workload spokes connected via Enterprise Transit. Destination identity for the deny-east-west rule. Required only for Transit-attached deployments. |
| default-threatgroup | Aviatrix-managed threat intelligence feed — known malicious destinations, C2 infrastructure, newly registered domains. Priority 1. Managed by Aviatrix, no operator maintenance required. |
What this architecture governs — and what it does not
Communication Governance defines what every Microsoft Foundry hosted agent can communicate with — which destinations, on which protocols, with what certificate posture — and enforces that definition in-path at every connection, including East-West paths to adjacent spoke resources. The following capabilities are explicitly out of scope: not because they are unimportant, but because they operate at a different layer of the stack. A practitioner deploying this VCA should know exactly where the blast radius reduction claim begins and ends.
Inference traffic to Azure OpenAI
Routes via private endpoint (RFC 1918, never leaves the VNet) and never traverses the Spoke Gateway. This is correct by design — private endpoint traffic is not the exfiltration surface. Do not attempt to route private endpoint traffic through the Spoke Gateway.
Internal resource traffic — Cosmos DB, AI Search, Storage
Private endpoint traffic stays inside the VNet and never traverses the Spoke Gateway. The exfiltration surface is external tool-call egress — that is what DCF controls.
Prompt content, tool arguments, model responses
Microsoft Foundry Guardrails for content-layer enforcement. Aviatrix governs network reachability; Guardrails govern content. Both are required. A notable Guardrails gap: tool call and tool response scanning are currently in preview and limited to Microsoft Foundry-hosted Azure tool calls — non-Azure tools, MCP servers, and external REST APIs are not covered. Aviatrix enforces Communication Governance on all of those surfaces regardless of tool type.
Shadow AI discovery — ungoverned Microsoft Foundry hosted agent deployments
AgentGuard Shadow AI Discovery finds every AI workload via cloud telemetry with no gateway insertion required. Deploy discovery before containment — you cannot contain a workload you have not found. Agents on Microsoft-managed VNets (not BYOVNet) are not reachable by this VCA but are discoverable via AgentGuard.
Full payload inspection of Hosted Agent tool-call egress
Requires the Aviatrix MITM CA in the Hosted Agent custom container trust store. v1 enforces FQDN allowlist and selective decryption at the gateway level. Container-level trust store injection is deferred to v2. Do not claim full payload inspection in field conversations until v2 ships.
Microsoft Purview and AI Red Teaming
Purview governs data content across the Microsoft 365 and Entra ecosystem — sensitivity labels, DLP, audit trails over prompt and response content. Red Teaming probes agent reasoning pre-deployment. Neither controls the network connections the agent makes to external endpoints at runtime. Aviatrix governs that surface. All three are part of a complete posture.
Everything your team needs.
Security, architecture, and deployment artifacts for every stakeholder. All assets ship on May 27 alongside the Terraform blueprint and scenario cards.
Requires Aviatrix Enterprise · Controller 8.2+ · 1 managed network per Foundry spoke VNet
New to Aviatrix? Start the Enterprise free trial — VCAs included at no extra cost. Already deployed? Pull the Terraform from GitHub.
Reference Architecture
Prerequisites, SmartGroup and WebGroup design, full DCF ruleset in priority order, ACA platform FQDN list, Azure Service Tag SmartGroup configuration, TLS decryption scope, operational safety properties, and subnet immutability preflight checklist. For platform engineers.
Download PDF →Threat Model & Enforcement
Microsoft Foundry BYOVNet threat model, full kill chain with point of intervention, three enforcement layers, why Azure Firewall is insufficient for this topology, architectural boundaries (inference traffic, Purview, Guardrails), and compliance evidence artifacts for HIPAA, PCI-DSS, SOC 2, EU AI Act, and DORA. For security architects.
Download PDF →Field & Buyer Overview
Threat narrative, three things your current stack can't do — selective TLS without breaking the runtime, East-West containment Azure Firewall can't enforce, and policy-as-code that deploys with the agent — compliance proof points, and discovery questions.
Download PDF →Full Terraform Blueprint
Infrastructure as code: Aviatrix Spoke Gateway in the Foundry VNet, UDR on the delegated agent subnet, DCF ruleset, SmartGroup and WebGroup definitions, ACA FQDN WebGroup, Azure Service Tag SmartGroups. Policy-as-code in the same repo as the agent config.
View repository →Attack simulation
60-second lab recording. The DCF default-deny rule fires. A second scenario shows the East-West lateral movement attempt blocked at the spoke boundary before any packet is forwarded.
Watch →Trusted by enterprise security teams
SOC 2 Type II
Independently audited
ISO 27001
Certified
500+ enterprises
Including 10% of the Fortune 500
Zero data-plane access
Aviatrix never touches your traffic
Documented before you find them in production.
Lab-validated limitations and workarounds for . Published upfront so your POC matches the docs — and so platform engineers can plan around them before the Microsoft Foundry project is deployed. The subnet immutability constraint in particular must be read before any infrastructure is provisioned.
Subnet immutability — the hardest gotcha in this deployment
The Microsoft Foundry capability host — the construct that binds the project to the delegated agent subnet — cannot be updated in place. If the UDR, subnet CIDR, or Spoke Gateway IP changes after deployment, the capability host must be deleted and recreated, requiring a full Microsoft Foundry project teardown. The UDR and subnet configuration must be validated and locked before the Microsoft Foundry resource is deployed. The preflight checklist in the blueprint is not optional.
Controller 8.2+ required for selective TLS decryption
DCF per-rule decryption scope requires Controller 8.2+. Controllers below 8.2 cannot enforce DECRYPT_NOT_ALLOWED and DECRYPT_ALLOWED per rule. This must be a preflight check in every deployment — without it, broad TLS inspection will break ACA control-plane traffic and the agent runtime will fail to start.
Microsoft Foundry-managed VNet deployments have no in-path enforcement point
Agents deployed on Microsoft-managed VNets (not BYOVNet mode) have no customer ENI and no in-path enforcement point available. Migrate to BYOVNet mode before applying this VCA. Agents on managed VNets can use AgentGuard Shadow AI Discovery for inventory but cannot use DCF enforcement.
Full payload inspection of Hosted Agent tool-call egress deferred to v2
Full payload inspection of tool-call egress from the Hosted Agent custom container requires the Aviatrix MITM CA in the container trust store (distributed via Key Vault extension as an example). v1 enforces FQDN allowlist and selective decryption at the gateway level. Container-level trust store injection is deferred to v2. Do not claim full payload inspection capability in field conversations until v2 ships.
Inference traffic to Azure OpenAI is not in scope
Inference traffic from the agent to Azure OpenAI routes via private endpoint (RFC 1918, never leaves the VNet) and never traverses the Spoke Gateway. This is correct by design — private endpoint traffic is not the exfiltration surface. Do not attempt to route private endpoint traffic through the Spoke Gateway.
The Terraform is built. The ruleset is on GitHub.
One terraform apply. Default-deny from minute one on Azure. Read the subnet immutability constraint before provisioning any Microsoft Foundry resources. Pick the path that matches your current Aviatrix footprint.
NEW TO AVIATRIX
Start with Enterprise — VCAs included free
Subscribe on AWS or Azure Marketplace, deploy a standalone Spoke Gateway inside the Foundry VNet — no Transit required, no hub peering. 30-day free trial — VCAs included.
ALREADY ON ENTERPRISE
Pull the Terraform from GitHub
Full blueprint, SmartGroup and WebGroup definitions, ACA FQDN WebGroup, Service Tag SmartGroups, and scenario cards. Deploy in 25–30 minutes. Destroy cleanly with one command.
Get the Terraform →Controller 8.2+ required · 1 managed network per Foundry spoke VNet · 30-day free trial · VCAs included · No code changes · No sidecars