Static IPs control the source address of runner traffic. They let you add an IP allowlist on internal firewalls so only your CI system can reach internal services. They do nothing to restrict or log what the runner sends outbound. When using the native egress path, a runner with a static IP can exfiltrate credentials to any attacker-controlled domain just as easily as one without. Source IP and destination policy are completely separate controls. Aviatrix governs the destination: what the runner can reach, enforced and logged at the network layer. 

Why doesn’t using Larger Runners with static IPs prevent data exfiltration?

It depends on the deployment model. On GitHub-hosted agents using the Phase 2b VPN overlay, a compromised action with root access could theoretically terminate the VPN process. Hardening options include restricting the gateway’s security group to accept connections only from known runner IPs and monitoring VPN disconnect events in CoPilot. For zero bypass risk, Phase 1 self-hosted runners on VMs or Phase 2a Actions Runner Controller (ARC) pods on Kubernetes with VPC-level routing provide network-layer enforcement that a compromised action cannot circumvent — the runner physically cannot reach the internet except through the gateway.

Can a compromised GitHub Action bypass the Aviatrix enforcement? 

StepSecurity, Bullfrog, and similar tools enforce egress filtering inside the runner’s trust boundary using DNS hooks or kernel-level techniques. A compromised action with root access can potentially kill or bypass these agents. Aviatrix’s Phase 1 self-hosted and Phase 2a ARC architecture enforces at the VPC boundary, outside the runner entirely. Additionally, Aviatrix integrates CI/CD egress policy with the same Distributed Cloud Firewall fabric governing production workloads, AI agents, and MCP servers, giving a single policy model and unified CoPilot visibility across all automated workloads. 

How is this different from tools like StepSecurity or Bullfrog? 

For Phase 1 self-hosted runners on VMs, enforcement is at the VPC routing level and requires no workflow changes at all — the Spoke Gateway automatically updates the route table on deployment. For Phase 2a ARC on Kubernetes, the Aviatrix Kubernetes Firewall Helm chart handles policy enforcement without application changes. For Phase 2b GitHub-hosted agents, adding egress control requires one line in the workflow file to invoke the VPN overlay agent. All three deployment paths are designed to be transparent to developers. 

Do we need to change our pipeline code to deploy the Aviatrix Validated Containment Architecture for Enterprise GitHub Pipelines? 

Aviatrix Validated Containment Architecture for Enterprise GitHub Pipelines directly supports SOC 2 (least-privilege access and audit logging for CI/CD systems), HIPAA (network segmentation for pipelines handling protected health information), PCI-DSS (restricting outbound traffic from in-scope environments), FedRAMP (continuous monitoring and least-functionality requirements), and the NIST Secure Software Development Framework (SSDF), which explicitly calls for protecting CI/CD infrastructure from unauthorized access and data exfiltration. DCF WebGroup and SmartGroup configurations are Terraform-managed infrastructure-as-code — policy ships in the same repository as deployment manifests, reviewed in the same PR, providing an auditable approval trail. 

What compliance frameworks does the Aviatrix Validated Containment Architecture for Enterprise GitHub Pipelines address? 

Aviatrix Validated Containment Architecture for Enterprise GitHub Pipelines Blog Featured Image

When using the native egress path, GitHub Actions runners have no egress firewall. Learn how Aviatrix Validated Containment Architecture for GitHub Pipelines stops supply chain exfiltration at the network layer — starting with self-hosted runners today. 

Secure GitHub Pipelines: Stop Exfiltration at the Network Layer 

Validated Containment Architecture for Enterprise GitHub Pipelines

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.  

Does inserting Aviatrix affect the Foundry agent runtime? 

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.  

What egress does Aviatrix actually control? 

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. 

Can I use this without Aviatrix Enterprise Transit already in place? 

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.  

What happens to the MCP server connections from the agent? 

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. 

Hosted Agents can be deployed with Azure Firewall on a stick, why should I use Aviatrix instead? 

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. 

How does Aviatrix compare to Microsoft AI Red Teaming? 

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.  

How does Aviatrix compare to Foundry Guardrails? 

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. 

How does Aviatrix compare to Microsoft Purview in a Foundry Hosted Agent deployment? 

Featured Blog Image - Validated Containment Architecture for Azure AI Foundry Agents

Aviatrix Validated Containment Architecture for Azure AI Foundry Agents limits the Blast Radius of potential incidents through network-level egress inspection.

Alex Weiss

Author Biography

Published Articles by Alex Weiss

Validated Containment Architecture for Enterprise GitHub Pipelines

Validated Containment Architecture for Azure AI Foundry Agents

Products

By Role

Customer Stories

Security & Legal

Solutions

Resources

Industry

Company

Tools