AWS handles the AgentCore service infrastructure under the shared-responsibility model. The agent itself — the code running inside the Runtime container — initiates its own outbound traffic. By default, that egress routes to the open internet through AWS-managed infrastructure with no in-line inspection point a customer's security team can reason about. Compromised agent traffic is indistinguishable on the wire from legitimate calls. The VCA is the enforcement point. 

Why Does Agentcore Need A Network Containment Layer? Doesn't Aws Handle The Network? 

Not for the baseline network controls. The Runtime is created in VPC mode with a flag at creation time. AgentCore drops the per-session microVM's ENI in subnets you control; egress follows the subnet's route table from there. The agent code does not change. Selective TLS decryption on supply-chain hosts is the one optional dependency that requires the Aviatrix MITM CA in the container's trust store — a five-line addition to the Dockerfile, with a fetch script provided in the repo. 

Does the VCA Require Changes to My Agent Code?

25 to 30 minutes on a fresh AWS account with one terraform apply. That includes the Aviatrix transit, the AgentCore spoke, the client spoke, the two interface VPC endpoints, the Distributed Cloud Firewall SmartGroups, WebGroups, and policies, the IAM guardrail, the ECR repo with the sample agent image, and a sample AgentCore Runtime you can invoke immediately for smoke tests. Destroy is one command and leaves zero orphans. 

How Long Does It Take to Deploy?

IAM condition keys on bedrock-agentcore:subnets and bedrock-agentcore:securityGroups. The VCA's IAM managed policy denies CreateAgentRuntime, CreateAgentRuntimeEndpoint, and UpdateAgentRuntime unless the request's subnets and security groups come from the approved set. A PUBLIC mode Runtime or a foreign-subnet attachment fails at the AWS API with an explicit deny — the call never reaches AgentCore. The drift scenario in the blueprint UI demonstrates this end-to-end. 

What Stops a Developer From Creating an AgentCore Runtime That Escapes the Landing Zone?

This release covers AgentCore Runtime. Browser, Code Interpreter, and Gateway are deferred to a follow-on. The architecture accommodates them — the MITM CA is already provisioned to Secrets Manager so Browser and Code Interpreter sessions can pull it on session start via the platform's first-class certificates parameter — but they are not in the current deployable scope. 

Does the VCA Cover AgentCore Browser, Code Interpreter, and Gateway?

The architecture is one repository, one Terraform module, one set of validated controls. Everything required to deploy on a fresh AWS account is in the box. You’ll receive an insertion pattern, SmartGroup model, Baseline Distributed Cloud Firewall policy pack, Bill of Materials, and GitHub repository. 

What Ships With Aviatrix Validated Containment Architecture for AWS Bedrock AgentCore on Day One?

Validated Containment Architecture for Enterprise MCP Infrastructure with Obot


Learn how Obot and Aviatrix secure MCP servers with default-deny egress controls, inline enforcement, Kubernetes CRDs, and audit logs. Read more.

How to Enterprise Secure MCP Servers with Obot + Aviatrix VCA

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.

What is the "Lethal Trifecta" and why does it matter for AI agents?

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.

What is an MCP server, and why is it a security concern?

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.

How does the Aviatrix-Obot partnership actually work?

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.

How does this partnership help with compliance requirements?

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.

What makes this approach different from existing network security tools?

Aviatrix-Obot Partnership: Securing MCP Servers with Containment Architecture Resource Card

The Aviatrix-Obot partnership offers customers enterprise-grade security for MCP servers, empowering safe agentic AI use.  

Nick Davitashvili

Author Biography

Published Articles by Nick Davitashvili

Validated Containment Architecture for Enterprise MCP Infrastructure with Obot

Announcing the Aviatrix-Obot Partnership: Securing MCP Servers

Products

By Role

Customer Stories

Security & Legal

Solutions

Resources

Industry

Company

Tools