> ## Documentation Index > Fetch the complete documentation index at: https://docs.aviatrix.com/llms.txt > Use this file to discover all available pages before exploring further. # MCP Server Security Through Containment Architecture > How Aviatrix containment architecture closes the egress security gap for MCP server workloads: the business case, deployment approaches, compliance impact, and key capabilities. Every MCP server an enterprise deploys starts with unrestricted outbound internet access. The server that only needs to reach `api.github.com` can, by default, communicate with any destination. Containment policy, if it is configured at all, follows on a separate timeline, managed by a different team, in a different tool. When an AI model's decisions become real-world API calls, the gap between those two timelines is the attack surface. ## Business Challenge MCP servers are the execution layer for AI agent tools. They make autonomous outbound API calls on behalf of large language models, connecting to GitHub, Slack, Salesforce, Jira, internal databases, and cloud provider APIs. These are trusted tools executing in trusted pipelines, which is precisely what makes them a high-value target. A compromised dependency, a poisoned tool description, or a supply chain attack against a server image arrives through channels that look legitimate. The security gap is structural: egress containment for Kubernetes workloads sits outside the scope of any MCP gateway or hosting platform, regardless of how capable that platform is at the protocol layer. Protocol-layer controls govern what tool is called and what it returns. They do not govern what the server pod can reach at the OS level, below the application, on connections the protocol layer never sees. A compromised MCP server dependency that opens a direct connection to an exfiltration endpoint bypasses every protocol-layer control in place. This is not a theoretical risk. **September 2025: Postmark-MCP.** A rogue npm package (a near-identical clone of the legitimate Postmark MCP server) was [discovered silently forwarding every email it processed to the attacker's external server](https://thehackernews.com/2025/09/first-malicious-mcp-server-found.html). The MCP gateway saw normal, authenticated email operations. The exfiltration happened on an outbound connection the gateway never saw. Workload-level egress containment would have blocked that connection: the server was not declared to reach any destination other than the Postmark API, so every connection to the attacker's endpoint would have been denied and logged. **March 2026: TeamPCP supply chain attack.** The [TeamPCP cascading supply chain attack](https://www.theregister.com/2026/03/24/trivy_compromise_litellm/) compromised four widely deployed AI and security tooling packages (Trivy, Checkmarx KICS, LiteLLM, and the Telnyx Python SDK) across five package registries in twelve days. LiteLLM operates under the same trust model as MCP servers: trusted code, making real outbound API calls, executed in trusted pipelines. The attack moved through trust, not around defenses. The detection apparatus documented it after the fact. The consequences are concrete. Without egress containment, the blast radius of any MCP server compromise extends to the entire internet. A server handling GitHub integrations, clinical records lookups, or financial data queries has unrestricted access to every destination, not because that access was granted intentionally, but because no one configured a control that denied it. For organizations subject to SOC 2, HIPAA, PCI-DSS, or FedRAMP requirements, an MCP server with unrestricted egress is a documented compliance gap the moment it handles regulated data. ## How Aviatrix Closes the Gap Aviatrix DCF enforces egress containment at the VPC boundary, specifically at the spoke gateway where Kubernetes pod traffic exits the cluster via node NAT gateways. This enforcement point is below the application layer, transparent to the workload, and impossible to bypass from within the pod. Every MCP server starts denied. Only explicitly declared egress destinations are reachable. A server with no declared policy fails closed, not open. Containment policy targets individual MCP server pods by Kubernetes label, not by ephemeral IP address. WebGroups filter outbound connections by FQDN, which is essential for MCP servers communicating with SaaS APIs on CDN-backed or rotating addresses that IP-based controls cannot handle reliably. When a supply chain compromise attempts to open a connection to an attacker-controlled endpoint, there is no route; the attempt is blocked at the gateway and logged in CoPilot. Attack scenario: dependency compromise attempts exfiltration; Aviatrix DCF intercepts and blocks at the VPC boundary For Obot-managed deployments, containment is lifecycle-coupled: Obot declares each server's permitted egress destinations, and the Aviatrix controller picks up that declaration and enforces it at the network boundary. When the server is deleted, the policy is deleted. For self-managed deployments, the same policy model applies via Kubernetes CRDs or Terraform. Either way, the enforcement primitive is the same: a per-server default-deny perimeter with an FQDN-based allow-list, enforced at the VPC boundary, visible in CoPilot across every cluster and cloud. Two-layer enforcement: Obot governs which MCP servers run and their declared egress policy; Aviatrix DCF enforces that declaration at the network boundary ## Why Existing Controls Do Not Close This Gap Several categories of tooling address different parts of the AI agent security problem. Understanding where each operates clarifies why workload-level egress containment requires a dedicated approach. | Approach | What it governs | Why it does not close the containment gap | | --------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | **Kubernetes NetworkPolicy** | IP address and port, intra-cluster | Cannot filter by domain name; no lifecycle coupling to MCP deployments; no multicloud visibility | | **Chokepoint inspection** (SASE, transit firewalls) | Traffic traversing a central inspection point | Kubernetes pod egress exits via node NAT gateways and never reaches the chokepoint | | **Application-layer AI security** (prompt injection, DLP) | Model and prompt layer | Cannot prevent unauthorized egress connections that originate below the application layer | | **MCP gateway platforms** (Obot, Kong, Smithery) | MCP protocol layer: auth, rate limiting, tool-call logging | Do not govern what the MCP server pod can reach on the network | Aviatrix DCF enforces at the VPC boundary via spoke gateways, at the point where Kubernetes egress actually exits the cluster, transparent to the workload and impossible to bypass from within the pod. Domain-based filtering via WebGroups, lifecycle coupling via the Obot integration or DIY CRDs, per-connection logging, and consistent containment policy across EKS, AKS, GKE, and self-managed clusters address each gap in the table above. ## The Business Case for MCP Server Egress Containment ### Risk Mitigation **Compromised dependency exposure.** MCP servers execute in trusted pipelines. A supply chain attack against a server image, a poisoned tool description, or a compromised transitive dependency arrives through channels that look legitimate. The September 2025 `postmark-mcp` incident is the clearest example: a malicious package clone forwarded every email it processed to an external server, undetected at the protocol layer, visible only as a network egress event. With unrestricted egress, the blast radius of any such compromise extends to the entire internet. With containment architecture, the blast radius is bounded by the declared allow-list for that specific server; a compromised server that attempts to reach an unauthorized destination finds no path, because one was never created. **The gap between deployed and secured.** In most environments, an MCP server starts taking traffic the moment it is scheduled. Containment policy follows on a separate timeline, run by a different team, often in a different tool. During that gap, a compromised or malicious MCP server can reach any destination on the internet. Containment architecture closes this gap by coupling the security policy to the deployment object itself: when the server is created, the policy is created; when the server is deleted, the policy is deleted. **Unrestricted egress as the structural problem.** Traditional security configurations permit by default and block by exception. A new MCP server deployed without an explicit containment policy inherits the default-allow posture of the environment. Aviatrix DCF inverts this: every server starts denied, and only declared destinations are reachable. A server that has not yet been given an explicit policy fails closed, not open. **Scoped blast radius, not complete prevention.** Egress containment reduces the attack surface materially without claiming to eliminate all risk. It does not prevent prompt injection through allowed API calls, and it does not prevent exfiltration via an approved SaaS endpoint. What it does is eliminate the arbitrary-destination egress surface: a compromised server that can only reach `api.github.com` cannot also reach an attacker-controlled endpoint on an arbitrary domain. ### Regulatory and Compliance Alignment Aviatrix DCF satisfies the workload-level egress controls that compliance frameworks require for AI agent systems: controls that must prevent unauthorized connections, not merely record them. Per-connection logging in CoPilot then generates the continuous audit evidence that proves those controls are operating. | Framework | Requirement | How Aviatrix DCF satisfies it | | -------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **SOC 2 Type II** | Logical access controls that restrict communication to authorized destinations (CC6.6, CC6.7) | Default-deny-per-server containment enforces allow-lists at the network layer, below the application; unauthorized egress is blocked, not just logged; CoPilot provides the continuous queryable record that the control is operating | | **HIPAA** | Minimum necessary standard: workload isolation for systems that can access PHI pathways | Unauthorized connections from MCP server pods are blocked at the VPC boundary before they can exfiltrate PHI; the containment layer operates below the application and cannot be bypassed by the workload | | **PCI-DSS Req. 1.3** | Restrict outbound traffic to only what is necessary for business operations | Domain-based filtering via WebGroups blocks every destination not on the declared allow-list, with FQDN-level granularity that IP-based controls cannot achieve; the firewall policy is the control, not a record of it | | **FedRAMP** | SC-7 boundary protection: restrict communications to authorized traffic only, with continuous monitoring | Aviatrix DCF enforces boundary protection at the spoke gateway, blocking unauthorized egress, while CoPilot provides the continuous monitoring and per-connection log evidence required for annual review | ### Operational Excellence **Lifecycle-coupled containment eliminates drift.** When containment policy is coupled to the workload, policy drift becomes structurally impossible. The policy is created when the server is created and removed when the server is deleted, automatically, without manual cleanup steps. Environments with frequent MCP server turnover stop accumulating orphaned policies that correspond to no running workload. **Policy as code, in the deployment pipeline.** Allowed egress destinations are declared alongside server configuration and travel with the workload through version control and GitOps pipelines. Containment policy is reviewed as part of the same change as the server definition and rolled back the same way, with no separate workflow and no separate team to coordinate with. **Propagation in seconds.** When a new threat is identified in your MCP server supply chain, updated containment policy reaches every workload before the compromised code can communicate, with no per-device pushes and no propagation delays across clusters. **Multi-persona policy layering.** Security admins, platform teams, and MCP server owners each manage their own containment layer independently. A security admin defines global threat rules without touching per-server policies. A platform team sets namespace-level egress baselines. Server owners declare specific allowed destinations. Each layer operates independently; changes in one layer require no coordination with others, and no team needs access to another team's controls to do their job. **Centralized visibility across the fleet.** Aviatrix CoPilot provides a single dashboard for all MCP server containment policies, real-time traffic flows, and per-connection logs across every cluster and cloud in the environment. Security teams get continuous visibility into what every MCP server can reach, without querying individual clusters or correlating logs manually. **Consistent containment across every cloud.** The same containment policy model and the same CoPilot dashboard govern MCP server egress across EKS, AKS, GKE, and self-managed Kubernetes clusters. Organizations running MCP servers across multiple cloud providers apply a single containment model and audit a single policy inventory, not cloud-specific configurations that diverge over time. ### Competitive Differentiation **The metric that matters changes.** In a detection-era posture, the organizing question is "did we detect the attack?" In a containment posture, it becomes "for every MCP server in our environment, what can it communicate with?" Aviatrix CoPilot answers that question continuously: every allowed and denied connection logged, every server's egress footprint visible, across every cluster and cloud. Security teams shift from reactive investigation after compromise to proactive posture management before it. Organizations that can demonstrate workload-level egress containment for their MCP servers are ahead of both their competitors and their regulators on AI agent security. [Gartner projects that 40% of enterprise applications will embed task-specific AI agents by end of 2026, up from less than 5% in 2025.](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025) The [Arkose Labs 2026 Agentic AI Security Report](https://www.arkoselabs.com/blog/agentic-ai-security-risk-enterprise-readiness/) found that 97% of enterprise security leaders expect a material AI-agent-driven security incident within the next 12 months. Organizations that close the containment gap now will absorb that incident without catastrophic impact; those that treat the protocol layer as sufficient will not. In regulated procurement contexts (healthcare, financial services, insurance), workload-level containment evidence for AI agent workloads is now a vendor qualification requirement in regulated procurement. Aviatrix DCF provides the containment evidence layer that buyers, auditors, and procurement teams are beginning to require alongside protocol-layer audit trails. ## Industry Success Stories **Challenge:** A major healthcare provider deploying Obot to manage clinical AI tools needed to demonstrate workload-level isolation for every MCP server accessing clinical APIs, as a prerequisite for HIPAA compliance review. Obot's protocol-layer audit trail satisfied tool-call logging requirements, but auditors required containment evidence at the workload level. **Solution:** Adding Aviatrix DCF to the Obot deployment meant that every MCP server deployment automatically generated a containment policy alongside its Kubernetes workload objects. Allowed egress destinations (declared per server in the Obot manifest) were pushed to the cluster as a workload-scoped policy. The Aviatrix controller picked up that policy and enforced it at the network boundary, with default-deny egress as the baseline. When a server was removed, its containment policy was removed with it. Per-connection logs in CoPilot provided the egress-layer audit trail alongside Obot's existing protocol-layer record. **Results:** * Workload isolation evidence satisfied for HIPAA compliance review, without restructuring the existing Obot deployment or Kubernetes architecture * Zero orphaned containment policies across the MCP server fleet; policy lifecycle tied directly to the server deployment, not managed separately * Per-connection logs available in CoPilot, covering the egress layer that protocol-layer logging does not reach * Compliance review timelines reduced by eliminating manual egress documentation for each AI tool deployment **Challenge:** An insurance group running self-deployed MCP servers for claims processing and customer workflow automation faced a PCI-DSS audit finding that servers handling payment-adjacent data had unrestricted internet egress. The team managed their own Kubernetes deployments and had no existing MCP gateway in place. **Solution:** The security team authored containment policies directly for each MCP server and committed them alongside server definitions in the existing GitOps repository. Each policy was pushed to the cluster as part of the normal deployment pipeline; the Aviatrix controller picked it up and enforced it at the network boundary, with no changes to the server code or cluster architecture. **Results:** * PCI-DSS Requirement 1.3 satisfied for all MCP workloads, with egress allow-lists scoped to confirmed API destinations * Containment policy committed to version control alongside server definitions, reviewed in the same PR process as application changes * Audit evidence generated automatically from CoPilot, replacing manually produced egress documentation * No changes to the MCP server code, container images, or cluster configuration **Challenge:** A financial services firm's platform engineering team running a mixed environment (some MCP servers deployed via Obot, others self-managed) needed consistent containment policy across both deployment paths, with independent controls for security admins, platform engineers, and individual server owners. **Solution:** Aviatrix DCF's multi-persona policy layering provided consistent enforcement across Obot-managed and self-deployed servers. Security admin global policies, platform-level namespace baselines, and per-server containment policies each pushed to the cluster independently; the Aviatrix controller enforced all layers simultaneously at the network boundary, with no coordination required between teams. **Results:** * Consistent containment posture across Obot-managed and self-deployed MCP servers, visible in a single CoPilot dashboard * Security admin policy changes propagated across all clusters without involving the platform team or requiring deployment windows * Per-server containment scoped to the MCP server owner's responsibility boundary, with separation of duty across personas * Full cross-cluster visibility in CoPilot, without requiring per-team access grants to individual clusters ## ROI and Business Impact **Cost avoidance.** The [IBM Cost of a Data Breach Report 2025](https://www.ibm.com/reports/data-breach) puts the average global breach cost at \$4.44M. A single MCP server compromise that exfiltrates customer data carries the same regulatory and remediation cost as any other breach, plus the reputational cost of an AI-specific incident in a market still establishing trust in enterprise AI. Containment eliminates the open-destination egress attack surface. The cost of adding Aviatrix DCF to an existing Kubernetes deployment is substantially below the cost of a single incident. **Operational efficiency.** Lifecycle-coupled containment eliminates the manual policy management overhead associated with MCP server deployments. For platform teams managing dozens of MCP servers, removing manual policy creation, review, and cleanup from each deployment and deletion cycle reduces operational load meaningfully. **Compliance acceleration.** Organizations subject to SOC 2, HIPAA, PCI-DSS, or FedRAMP that can provide automated containment audit trails for MCP workloads reduce compliance review cycles. Audit preparation time decreases when CoPilot provides continuous, queryable connection history: containment evidence that complements protocol-layer audit trails to cover the full audit requirement for AI agent workloads. **Strategic value.** The [agentic AI market reached \$9B in 2026](https://www.fortunebusinessinsights.com/agentic-ai-market-114233). Organizations that can demonstrate workload-level containment alongside protocol-layer governance have a complete, defensible security posture for AI agent workloads, which is the combination that regulated buyers, auditors, and procurement teams are beginning to require. ## Key Components Enforces workload-scoped containment policy at the VPC boundary, where Kubernetes egress actually exits the cluster. Containment policies are declared alongside server definitions, pushed to the cluster, and picked up by the Aviatrix controller for immediate enforcement. Identity-based workload selectors that target containment policy to specific MCP server pods by Kubernetes labels, not by ephemeral IP addresses. This ensures that policy follows the workload as it scales and reschedules across nodes. Domain-based egress filters that match traffic by FQDN rather than IP address, essential for MCP servers communicating with SaaS APIs on rotating or CDN-backed addresses. WebGroups are the mechanism that makes domain-based allow-lists enforceable. Centralized dashboard for all MCP server containment policies, real-time traffic flows, and per-connection logs. Provides continuous visibility into egress posture across every cluster and cloud, for both Obot-managed and self-deployed MCP servers. ## Implementation Guides * Obot Integration: AKS: lifecycle-coupled containment for Obot-managed MCP servers on Azure Kubernetes Service. * Obot Integration: EKS: lifecycle-coupled containment for Obot-managed MCP servers on Amazon EKS. * Self-Hosted MCP Servers: containment policy for servers deployed directly to Kubernetes via Helm, ArgoCD, Kustomize, or kubectl.