I’m excited to announce a new framework in Obot that lets you define and enforce network egress policies for the MCP servers running in your Obot environment. We built it as a plugin architecture so any networking company can integrate with it. To make this real in production, we teamed up with Aviatrix, our first plugin partner, to extend these controls beyond MCP servers into the network – ensuring agent activity stays contained end-to-end. More here.
Why we built this
We believe securing MCP servers and agentic systems requires a layered approach.
Obot already enforces several layers. MCP servers run in isolated sandboxes. We provide audit logs, tool call filtering and mutation, role-based access control, and Kubernetes-level network policies to name a few.
But recent attacks such as the Axios supply chain compromise have made one thing clear: once compromised code is running inside your environment, the most common next step is to reach out to a third party site to either exfiltrate data or retrieve instructions to execute as part of a RCE (remote command execution) attack. If that outbound access is not tightly controlled, other safeguards can be bypassed.
To address this, network egress control adds another security layer that strictly defines which external domains each MCP can talk to and blocks everything else by default. It works with the rest of Obot’s controls to limit the blast radius of compromised code and cut off the most common paths for data exfiltration and remote command execution.
How it works
Once you enable this feature, when you configure an MCP server in Obot, you now get a section for network egress policies. You define the external domains the server should be allowed to reach and Obot pushes those policies to your networking infrastructure through a plugin.
The MCP server works exactly like it did before. It just can’t access external sites it shouldn’t.
We deliberately built this as a framework rather than tying it to one networking vendor. Your network team probably already has tools they like and trust. The plugin architecture means you can keep using them, and we can keep adding integrations over time.
Aviatrix as the first plugin
Aviatrix was the right partner to launch with. They’ve been working on network containment for AI workloads for a while, and their platform handles the kind of dynamic, workload-level enforcement we needed. Their plugin translates Obot policies into their enforcement rules automatically, across whatever clouds you’re running in.
What I appreciate about working with their team: they think about this the same way we do. The point isn’t to block things after something goes wrong – it’s to make sure MCP servers can only reach what they’re supposed to reach in the first place.
What’s next
The Aviatrix plugin will be available in the the v0.21.0 release of Obot. We’re already in conversations with other networking companies about additional integrations, so if you’re using a different platform, let us know what you’d like to see supported.
If you want to try it out or learn more, reach out at info@obot.ai.
