TL;DR
Like many AI platforms, Azure AI Foundry Agents have great potential for developer innovation as well as new security risks: Foundry’s Standard Agent in "Bring your Own Virtual Nerwork” (BYOvnet) flavor gives workloads a private network but with unrestricted egress to the internet, creating data exfiltration risk.
Aviatrix Validated Containment Architecture for Azure AI Foundry Agents gives you a customized containment architecture that safeguard against data exfiltration to enforce security policies at the network layer. In other words, it creates guardrails to protect these AI workloads and free developers to focus on building applications.
Azure AI Foundry: Great Potential that Needs Guardrails
Azure AI Foundry is a huge resource for AI as a platform-as-a-service offering with access to over 1,900 models from Microsoft, OpenAI, Anthropic, Mistral, xAI, Meta, DeepSeek, and Hugging Face – but it has a major security gap in its regular Microsoft-managed virtual network implementation. Foundry's Standard Agent in BYOVNet mode places agent workloads inside a customer-managed VNet. They route all tool calls, including external Application Programming Interface (API) invocations, Model Context Protocol (MCP) server connections, and Code Interpreter egress, through a uncontrolled, default-allow, path to the internet.
In other words, Foundry’s agents have an open door to the internet: unrestricted egress.
Ungoverned egress means that threat actors can access valuable workloads over which security teams have little visibility. They can use prompt injection, over-permissioned managed identities, and compromised MCP servers to infiltrate your network and weaponize Azure infrastructure.
Security teams’ options for security enforcement are limited. Either via the Microsoft-managed / non-private VNet with an additional Azure Firewall, or connected to an existing hub, making it more complex in a developer day-to-day activities. Because Aviatrix gives you centralized security policy enforcement whether or not it's connected to a hub in a VNet, understands native Azure Service Tags, and provides decryption of tool-calls, it reenforces the default-deny security posture across all your agent assets.
Introducing Validated Containment Architecture for Azure AI Foundry Agents
Aviatrix Validated Containment Architecture for Azure AI Foundry Agents creates a containment architecture that governs egress with a default-deny, network-layer security policy enforcement specifically designed for AI workloads. This architecture means that you no longer have to rely on your detection tools or security teams to find and flag threats quickly enough; you have already shut down the exfiltration pathways a threat actor could use. No need of a detection engine’s signature update.
The technical details are below, but here’s the big picture: this Validated Containment Architecture defines, determines, and limits the Blast Radius of any incident before any deployment, through architecture. It allows you to deploy AI agents safely without worrying whether your detection tools will find an incident quickly enough.
Notes from the Lab: How this Works
For practitioners, here’s what this Validated Containment Architecture looks like under the hood:
Aviatrix DCF enforcement for Azure AI Foundry agent egress: Aviatrix Spoke Gateway deployed in the Foundry spoke VNet, with a route table on the hosted agent subnet routing all egress through the Spoke Gateway to to the internet. It can optionally be connected to an existing Aviatrix transit for East/West security. DCF only allows traffic needed by the tools. Optionally, it can decrypt tool-call traffic for payload-level visibility while explicitly bypassing decryption for Azure control-plane FQDNs—preserving ACA runtime compatibility without sacrificing inspection coverage where it matters most. SmartGroup East-West policy contains lateral movement between the Foundry spoke and adjacent workload spokes.
The key capability is DCF's per-rule capability enablement: allow specific FQDN, to specificnative Azure Service Tags destinations, decrypted or not. Tool-call egress (external MCP servers, Code Interpreter, REST API calls) is under control. This VCA comes with pre-configured dynamic security groups matching Microsoft’s egress requirements for the control plane so the exclusion set stays correct automatically as Microsoft updates the underlying IP ranges, with no manual maintenance required.
What Aviatrix sees: All egress from the delegated agent subnet to non-private-endpoint destinations—tool call HTTP/S, MCP server connections, Code Interpreter outbound, external API calls. This is the entire tool-call surface, the highest-risk traffic the agent generates.
What Aviatrix does not see by design: Inference traffic from agent to Azure OpenAI (private endpoint, RFC 1918, never leaves the VNet). Cosmos DB, AI Search, and Storage PE traffic (same). If private endpoints live in a different place of your network, aka. East/West traffic, Aviatrix will be able to apply security policy there, too.
What is the DCF Policy Structure?
Deployment topology: Aviatrix Spoke Gateway in the Foundry spoke VNet with A route table applied on the delegated agent subnet. Aviatrix will configure 0.0.0.0/0 next-hop pointing to the Aviatrix Spoke Gateway private IP once deployed.
Conclusion
Aviatrix Validated Containment Architectures limit the risk of non-deterministic, autonomous, unpredictable AI workloads through designs that are customized for each AI platform. They provide containment that limits the Blast Radius of any potential incident by stopping lateral movement and preventing data exfiltration, the greatest risks to your network. If you want to maximize your use of Foundry without maximizing security risks, start here.
Existing Aviatrix customers: you can clone and deploy this Validated Containment Architecture today. Talk to your Aviatrix representative to get started.
Not a customer yet? Start a 30-day free trial.
Explore other Validated Containment Architectures for Enterprise MCP Servers through Obot, AWS Bedrock AgentCore, and more.
Frequently Asked Questions
No. Aviatrix Distributed Cloud Firewall (DCF) uses the Aviatrix Spoke inserted into the virtual network, forcing 0.0.0.0/0 traffic to be sent via the gateway. Tool-call egress is filtered according to security policies while Azure control-plane traffic (Azure Active Directory token acquisition, hosted agent infrastructure calls) is explicitly allowed by rules scoped to Azure Service Tags. The gateway sits in the path; the runtime does not know it is there.
All traffic leaving the delegated agent subnet to non-private-endpoint destinations: tool-call HTTP and HTTPS, Model Context Protocol (MCP) server connections, Code Interpreter outbound, and external REST API calls. All other traffic considered as East/West and sent outside of the virtual network is sent directly or passes via the Aviatrix spoke if connected to a transit.
Yes. Organizations deploying Foundry agents for the first time can start with a standalone Aviatrix Spoke Gateway deployed directly inside the Foundry VNet, with no Transit Gateway, no hub peering, and no connectivity back to corporate infrastructure. The Spoke Gateway enforces DCF Fully Qualified Domain Name (FQDN) allowlist policy on tool-call egress with a single route table on the agent subnet. The standalone Spoke Gateway can connect to an Enterprise Transit later as the network footprint grows.
MCP server connections leave through the delegated agent subnet via the no-control egress path. Aviatrix DCF intercepts, decrypts, and inspects these connections, enforcing an FQDN allowlist. Only approved MCP server FQDNs are permitted. Unapproved destinations, including newly registered domains, attacker-controlled endpoints, or unlisted Software-as-a-Service (SaaS) APIs, are denied and logged with full payload visibility on the blocked attempt.
Azure Firewall on a stick solves egress for agent on one stack. Enterprises end up running Foundry today, AWS Bedrock AgentCore next quarter, and self-hosted LangGraph on Kubernetes alongside both. Each platform has its own insertion model, firewall requirements, and policy syntax. Aviatrix DCF SmartGroups and WebGroups apply consistently across all three with one control plane, one policy model, and one audit log. A security team can answer "what can any of our agents reach, across all platforms?" from a single console rather than maintaining separate firewall rulesets per agent type.
They operate at different layers and are complementary. Microsoft's AI Red Teaming Agent is a pre-deployment testing tool that probes the agent's reasoning in a sandboxed environment using synthetic data and adversarial prompts. It answers: can this agent be tricked? Aviatrix operates at runtime on live traffic and answers a different question: what can a compromised agent actually reach? A prompt injection that passes red teaming is still stopped at the network boundary if the exfiltration destination is not in the DCF allowlist. Red teaming shifts risk left; Aviatrix enforces a Blast Radius ceiling in production.
Foundry Guardrails operate inside the inference pipeline, scanning user input, tool calls, tool responses, and final output for harmful content at the model layer. Aviatrix operates at the network layer, downstream of the model, and enforces which external destinations the agent's tool-call traffic can reach regardless of what the model sent. Guardrail tool-call and tool-response scanning are currently in preview and limited to Foundry-hosted Azure tool calls. Non-Azure tools, MCP servers, and external REST APIs are not covered. Aviatrix enforces egress policy on all of those surfaces. Run both: Guardrails for content, Aviatrix for network containment.
Purview is a data governance, compliance, and Data Loss Prevention (DLP) platform that operates on data content across the Microsoft 365 and Entra ecosystem. Aviatrix operates on network packets at the VNet boundary. Microsoft Foundry is supported in Purview's Data Security Posture Management for AI coverage, so Purview can audit agent interactions and flag sensitive data exposure. However, Purview has no visibility into or control over the network connections the agent makes to external tool endpoints. Run both: Purview for data governance over interaction content, Aviatrix for network containment of where the agent can send that content.
