TL;DR
Aviatrix and Obot are partnering to provide customers with secure MCP server deployment, protecting the connections that AI agents need to operate.
The partnership connects Obot’s MCP server deployment platform to Aviatrix Cloud Native Security Fabric, enforcing a default-deny network policy at the spoke gateway across every cloud.
Every MCP server in your environment is an ungoverned egress path. Your NetworkPolicy doesn’t see it. Your service mesh isn’t catching it. Your audit log doesn’t know it exists.
Simon Willison calls this the Lethal Trifecta: agents with access to private data, exposure to untrusted content, and the ability to communicate externally. When all three are present, you have an exfiltration vector. Break any one, and the chain breaks.
MCP servers stack legs 1 and 2 by design. The Aviatrix-Obot partnership breaks leg 3 (exfiltration). Obot decides what runs; Aviatrix decides where it reaches.
Two-layer control for MCP servers: Obot governs which servers run, Aviatrix governs where they reach.
Two-Layer Control for MCP Servers
In an enterprise running AI agents, every agent calls one or more MCP servers. Obot deploys and governs which MCP servers an agent is allowed to call. Aviatrix governs where those servers can reach over the network. Together, the two decisions are the floor for safe agentic AI.
“Every enterprise running AI agents is running MCP servers, often more than they realize," said Shannon Williams, President of Obot AI. "Without governance at the gateway and the network, a compromised agent’s blast radius extends to everything those servers can reach. Obot governs which MCP servers an agent can call. Aviatrix governs where those servers can reach. That two-layer control is what enterprise agentic AI actually requires.”
“By default, an MCP server can call anything its host can reach," said Aviatrix CEO Doug Merritt. "That is the wrong default for enterprise AI. Aviatrix and Obot make containment the deployment posture, not an aspiration.”
How the Aviatrix-Obot Partnership Works
Obot deploys an MCP server that fields requests for data on behalf of an AI agent. For example, an MCP server permitted to send patient data to your EHR.
Through Aviatrix Cloud Native Security Fabric, security teams set FirewallPolicy CRDs that govern what each server can and cannot reach. Policies are propagated across clouds and environments, inline.
When a request reaches an MCP server destined for an unknown or suspicious location, Aviatrix sees the traffic, applies the policy, and blocks the connection. Customers get detailed logs for every server request, blocked or allowed.
Traffic from each MCP server passes through Aviatrix spoke gateways, where the eBPF dataplane evaluates FirewallPolicy CRDs inline and drops disallowed egress before it leaves the cluster. This is containment at the architecture level: no code changes, no agents, no sidecars.
This partnership offers three advantages that your existing stack does not have:
Granular containment, not blunt IP blocks. Two MCP servers in the same namespace get different egress policies based on pod labels. Kubernetes NetworkPolicy cannot do this.
No policy debt. Delete the MCP server; the Obot controller triggers garbage collection at the Aviatrix spoke gateway. No orphaned permits accumulate in your cluster.
Multicloud portability. The same FirewallPolicy CRD enforces egress at the spoke gateway across AKS, EKS, and GKE. No per-cloud rewrite.
This integration offers network-layer containment, not payload inspection or prompt-level guardrails. Different problem, different control.
Enforcement runs at the spoke gateway’s eBPF dataplane, not via Istio or Envoy sidecars. There’s no per-pod resource overhead or sidecar injection. This setup offers the same benefits a service mesh promises for MCP egress control, without the operational weight.
Example: An MCP server is permitted to send patient data to your EHR. A compromised dependency on the server, a poisoned npm package, or a hijacked SDK attempts to exfiltrate the same data to an attacker-controlled domain. The MCP server has permission for the action, not the destination. Aviatrix sees the destination, applies policy, and blocks the egress.
Supply-chain compromise is a rising threat. The March 2026 wave of supply chain attacks hit Axios (UNC1069/Sapphire Sleet, 70 million weekly downloads), LiteLLM, Trivy, KICS, and Telnyx. A poisoned dependency inside an MCP server inherits the server’s egress permissions for free. Domain-based, not trust-based, is the only control that catches this.
How the Aviatrix-Obot Partnership Helps with Compliance
For regulated industries, the compliance question is not whether you have an AI security policy; it’s whether you can prove enforcement. A policy document does not satisfy an auditor after a breach. Architectural evidence does. For HIPAA, PCI-DSS, and SOC 2 environments, that proof lives in the control plane itself.
FirewallPolicy CRDs are Kubernetes objects. They live in git. They are inspected with kubectl. They are tracked in the Kubernetes audit log. Security policy ships in the same repository as the deployment manifest, reviewed in the same PR, deployed in the same pipeline. That architectural guardrail is your proof.
Recent research shows the median enterprise must patch 6.5 times faster than is physically possible. In the Containment Era, containment decides whether an incident becomes a breach.
Book a 30-minute Architecture Review
Explore the integration through an architecture review: we will walk through the FirewallPolicy CRD model in your environment, identify the MCP servers you have running today, and show you the egress paths you do not currently see.
Discover agentic AI security not as a bolted-on solution, but threat containment at the architectural level.
Learn more about the Aviatrix-Obot partnership.
Explore Zero Trust for AI Workloads and Aviatrix AgentGuard, which detect and stop shadow AI and protect organizations from AI-instigated security incidents.
Frequently Asked Questions
The Lethal Trifecta, a concept from security researcher Simon Willison, describes three conditions that create an exfiltration risk: agents with access to private data, exposure to untrusted content, and the ability to communicate externally. When all three are present, attackers have a path to steal data. MCP servers inherently satisfy the first two conditions by design. The Aviatrix-Obot partnership focuses on breaking the third leg by controlling where MCP servers can send traffic, stopping unauthorized external communication at the network level.
An MCP server handles requests for data on behalf of AI agents. For example, an MCP server might retrieve patient records from a healthcare system when an agent needs that information. The security concern is that by default, an MCP server can reach anything its host can reach. Most enterprises are running more MCP servers than they realize, and each one represents an ungoverned egress path. Traditional tools like Kubernetes NetworkPolicy and service meshes often lack the visibility to catch unauthorized traffic from these servers.
Obot governs which MCP servers an AI agent is allowed to call. Aviatrix governs where those servers can send traffic over the network. Security teams set FirewallPolicy CRDs that define allowed and blocked destinations for each server. Traffic from each MCP server passes through Aviatrix spoke gateways, where an eBPF dataplane evaluates policies inline and drops disallowed egress before it leaves the cluster. This requires no code changes, no sidecars, and no per-pod resource overhead. Policies propagate across clouds and environments automatically.
For regulated industries under frameworks like HIPAA, PCI-DSS, and SOC 2, auditors need architectural proof of enforcement, not just a policy document. FirewallPolicy CRDs are Kubernetes objects that live in git, can be inspected with kubectl, and are tracked in the Kubernetes audit log. Security policy ships in the same repository as the deployment manifest, reviewed in the same pull request, and deployed in the same pipeline. This creates a verifiable, auditable record that enforcement is built into the architecture itself.
This partnership provides three capabilities that standard tools lack. First, it offers granular containment where two MCP servers in the same namespace can receive different egress policies based on pod labels. Second, it eliminates policy debt because deleting an MCP server automatically triggers cleanup of its associated firewall rules. Third, the same FirewallPolicy CRD works across AKS, EKS, and GKE without rewriting policies for each cloud. Enforcement runs at the spoke gateway's eBPF dataplane, delivering service-mesh-level control without the operational overhead of sidecars.
