✨ The Containment Era is here. Secure AI workloads before they breach. →The Containment Era is here. →The Containment Era is here. →Explore ✨
The supply chain attack Kubernetes can't stop.
The blast radius of a compromised MCP server is decided by architecture. By default, a poisoned dependency inside your server inherits its full egress permissions: destination unrestricted. The Cascade in March 2026 proved what this costs: trusted software components moving through five package registries in twelve days, not by breaking defenses but by moving through trust. Communication Governance places enforcement in-path at the network layer, where it cannot be bypassed regardless of what the running code believes it is authorized to do.
Dependency compromise
Poisoned package published to registry. Passes vulnerability scanning — no known CVE at install time.
Server execution
Server starts. Malicious dependency loads. Server has legitimate permission to access private data.
Data access
Agent calls the server. Request fulfilled. Malicious code captures the response payload.
Exfiltration attempt
Malicious code initiates HTTPS to attacker.io. The server has permission for the action — not the destination.
Audit trail
Blocked attempt logged at spoke gateway — pod identity, domain, timestamp, policy rule. Full attribution in CoPilot.
One controller. Two control loops. Zero developer compliance.
Where MCP server existence is governed — and what each server is permitted to reach
Obot deploys MCP servers into an isolated Kubernetes namespace via its controller. Each server is declared with an explicit list of permitted domains (egressDomains). The aviatrix-network-policy-controller watches Obot's MCP server objects and reconciles a FirewallPolicy CRD for each. Platform engineers do not write CRDs directly. Obot handles server lifecycle — including garbage collection when a server is deleted.
Where every outbound packet is evaluated before it leaves the environment
Traffic from each MCP server pod passes through the Aviatrix spoke gateway. The Aviatrix spoke gateway (Policy Enforcement Point) intercepts pod egress at the network layer and enforces FirewallPolicy CRDs pushed by the controller. No kernel modifications, sidecars, or service mesh required. No sidecar. No per-pod overhead. No application team compliance required. The same CRD enforces egress across AKS and EKS without rewrite. Two MCP servers in the same namespace get different egress policies based on pod labels — something Kubernetes NetworkPolicy cannot do.
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.
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.
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 deployment
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
k8s-firewall Helm release installs the FirewallPolicy and WebgroupPolicy CRDs. Obot Helm release (v0.21.0+) includes the aviatrix-network-policy-controller. SmartGroup definitions. Deploy in under 4 hours from the README.
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.