Default-deny network containment for production AI agents. Deployable in an afternoon. Reversible in seconds.
By default, an Amazon Web Services (AWS) Bedrock AgentCore Runtime can reach any destination on the internet the moment it starts. Its outbound tool calls, model invocations, and remote Model Context Protocol (MCP) connections are indistinguishable on the wire from legitimate work. The honest answer to where does our security team see that traffic? is in VPC (Virtual Private Cloud) flow logs, after the fact.
That is the wrong default for production Artificial Intelligence (AI). Validated Containment Architecture for AWS Bedrock AgentCore changes it.
Validated Containment Architectures are lab-tested deployment blueprints from Aviatrix that compress weeks of per-platform architecture work into a single afternoon — one per AI platform our customers run in production. The Aviatrix-Obot VCA for MCP servers shipped earlier this month. Azure AI Foundry, GitHub Actions AI pipelines, LibreChat, NVIDIA NemoClaw and OpenClaw, Google Vertex AI Agents, and Microsoft MCP Gateway are in flight on a weekly cadence.
This post is about the architecture for AWS Bedrock AgentCore.
Default-Deny Containment at the Spoke Gateway
Here’s how it works: the VCA places every AgentCore Runtime session in a customer VPC. The AgentCore Application Programming Interface (API) is fronted by in-path PrivateLink consumer endpoints in the same VPC. Aviatrix Distributed Cloud Firewall enforces a default-deny policy pack at the spoke gateway, with allowlists scoped to the destinations agents actually need. Identity and Access Management (IAM) condition keys prevent any AgentCore Runtime from being created outside the landing zone.
The architecture is opinionated, lab-tested, and shipped as Terraform. Deploy on a fresh AWS account in 25 to 30 minutes with one terraform apply. Destroy with one command. Idle cost roughly $1.10 per hour.
Three Problems it Solves on Day One
Arbitrary agent egress to the open internet. Every outbound flow from the AgentCore Runtime traverses the Aviatrix Spoke Gateway. Sanctioned model providers, sanctioned tools, sanctioned MCP servers, and approved AWS control-plane endpoints are allowed. Everything else is denied and logged with a human-readable rule name.
Supply-chain compromise of sanctioned hosts. Selective transparent Transport Layer Security (TLS) decryption — scoped tightly to a single destination Fully Qualified Domain Name (FQDN) SmartGroup — gives the gateway Uniform Resource Locator (URL)-path visibility on the hosts where it matters. The Shai-Hulud npm worm's Infrastructure as Code (IoC) pattern on raw.githubusercontent.com is blocked. The legitimate path on the same domain returns HTTP 200. Same TLS handshake, different outcome based on URL path.
Control-plane drift to network mode PUBLIC. An AgentCore Runtime created without VPC mode runs on AWS-managed infrastructure with no customer ENI — invisible to Distributed Cloud Firewall by construction. The VCA's IAM managed policy denies CreateAgentRuntime, CreateAgentRuntimeEndpoint, and UpdateAgentRuntime unless the request's subnets and security groups come from the approved landing-zone set. The bypass is prevented at the AWS API, before any packet flows.
Insertion that No One Notices: The Egress and Ingress Sides of this Validated Containment Architecture
There are two halves to AgentCore traffic, and both land in the same Aviatrix-attached landing-zone spoke.
The egress half. AgentCore VPC mode drops the per-session microVM's Elastic Network Interface (ENI) into a subnet you control. The subnet's default route points at the Aviatrix spoke gateway. Every outbound flow — tool calls, model invocations, MCP egress, Domain Name System (DNS) — traverses the gateway inline. No sidecar on the container, no agent on the runtime, no application change.
The ingress half. Two interface VPC endpoints — bedrock-agentcore (data plane) and bedrock-agentcore-control (control plane) — live in the same spoke. Client workloads invoking agents route through the Aviatrix transit to reach those endpoints. Distributed Cloud Firewall sees the request's source and destination inline and applies an ingress allow rule keyed on the client VPC's SmartGroup. A single spoke. Both halves of AgentCore traffic, in-path. The application does not change, the container does not need an agent, and the existing Network Address Translation (NAT) path stays in place — deploying the VCA does not require replacing it.
Every flow into and out of the AgentCore landing zone reaches the Aviatrix Spoke Gateway in-path. Sanctioned models, sanctioned MCP servers, and approved AWS APIs are explicitly permitted by SmartGroup. Unsanctioned hosts — catbox.moe, unknown model providers, IoC URL paths — fall to the default-deny rule and are logged with a human-readable rule name.
Why This Validated Containment Architecture Doesn’t Break the Agent
The biggest fear most platform teams have when adding a firewall in front of a production AI agent is that the firewall will break the agent. The VCA architecture has four structural properties that make that fear unfounded.
No code changes to the agent container. The Runtime is created in VPC mode with a flag at creation time. The agent's Python or Node code sees the same network it always saw, the same Software Development Kit (SDK) calls, the same response shapes. There is nothing to install in the container for baseline network controls.
AWS-service cert validation is preserved. Selective TLS decryption is scoped to a single destination FQDN SmartGroup — the supply-chain hosts where URL-path enforcement is required. Every other Distributed Cloud Firewall rule sets decrypt_policy = DECRYPT_NOT_ALLOWED explicitly. Amazon Elastic Container Resource (ECR) image pulls by the AgentCore microVM bootstrap layer, Bedrock SigV4 calls, AWS control-plane traffic, and MCP server connections all stay encrypted end-to-end with their original certificate chains intact.
Monitor before enforce — every rule, every time. Every Distributed Cloud Firewall rule in the policy pack is logging-enabled by default. The dataplane never reloads on rule changes; policy propagates to enforcement in roughly 100 milliseconds via a kernel-level eBPF map update. Flip a rule to logged-only by toggling the Watch flag — same rule, same dataplane, different action. There is no scenario in this deployment where rolling back a regression takes more than seconds.
One-action back-out. Disable the Spoke-Gateway insertion on the AgentCore VPC and the AgentCore traffic returns to the AWS-default path. Nothing else is touched. There is no second-order cleanup, no orphaned resource, no maintenance window.
The agent runs the same way it ran before the VCA was deployed. The difference is that the security team can now see and bound what the agent reaches.
Why Containment is Necessary: The Slide Deck That Went to catbox.moe
Earlier this year I watched an AI agent exfiltrate thirty slides of confidential product roadmap to a public file-sharing site — and the entire chain was authorized work, not an attack. A product manager asked the agent to prepare a slide deck for all new features in v10.0 and v10.1. The agent had Confluence access — legitimate, granted by the platform team. It searched, found the launch docs and feature specs, drafted the deck. Then it ran into a tool limitation: it could not return a file to the user directly. The path of least resistance it had was uploading to catbox.moe and returning the URL. Thirty slides of unreleased product detail, on the public internet, in under a minute.
The industry conversation about AI agent security is dominated by advanced anomaly detection and prompt-injection defenses. Those are real problems. They are also the wrong starting point for most organizations.
Agents are like teenagers. They need guardrails, and some of the guardrails are basic. Do not upload our data to random file-sharing sites is a fence that goes around the workload, not a model you train. A single SmartGroup → Internet → DENY rule on the agent's spoke would have stopped the upload before the Transmission Control Protocol (TCP) handshake finished. Suricata on the gateway would have logged the attempt. The Security Operations Center (SOC) would have had an alert with the policy citation, source workload, and destination URL inside of a second.
That is the basic guardrail organizations adopting AgentCore need on day one. Validated Containment Architecture for AWS Bedrock AgentCore is the deployment artifact that puts it in place.
Three Deployment Paths for Aviatrix Validated Containment Architecture for AWS Bedrock AgentCore
The architecture does not assume a fresh AWS account or a green-field network. There are three honest ways to put it in place, ordered by how much existing infrastructure they assume.
Existing Aviatrix Cloud Native Security Fabric customers. The AgentCore landing zone is just another spoke in the fabric you already run. Attach the AgentCore VPC to your existing Aviatrix transit, drop in the SmartGroups and WebGroups from the blueprint, apply the policy pack. No new fabric to deploy, no second console to learn, no migration. License the new landing zone — one base, one advanced visibility, one advanced security — and the architecture is live.
New customers — start with Egress. Aviatrix Secure Egress is valuable on its own. Replace the AgentCore VPC's NAT gateway with an Aviatrix spoke gateway in egress mode. The agent's outbound traffic now traverses Aviatrix Distributed Cloud Firewall; default-deny applies; the blueprint's allowed-model, allowed-tool, and allowed-MCP destination lists seed the egress allowlist. No transit, no peering, no east-west yet. Recover the NAT-gateway line item along the way.
New customers — Inspection for AWS Transit Gateway. Customers who already run AWS Transit Gateway and do not want to re-architect their cloud network can put Aviatrix in-path via Aviatrix's new Inspection for AWS Transit Gateway functionality. Aviatrix becomes a policy-enforcement point on the existing transit with zero changes to AWS-native routing, no peering changes, no maintenance window. The AgentCore VPC's traffic reaches Aviatrix for inspection; the AWS Transit Gateway remains the source of truth for routing.
Three paths, one architecture. The blueprint repository encodes path 2 (deploy fresh, end to end). Paths 1 and 3 are documented in the deployment guide alongside the blueprint.
The Case Selective Decryption Was Built For
Most enterprises permit their AI agents to reach raw.githubusercontent.com. They have to — the agents need it for legitimate work. SNI-only allowlisting cannot distinguish a clean path on that host from a poisoned one. The TLS endpoint is the same.
Selective transparent TLS decryption in this VCA is scoped to a single destination FQDN SmartGroup containing the supply-chain hosts the URL filter cares about. Inside that scope, the gateway sees URL paths and applies a priority-29 deny rule seeded with the Shai-Hulud npm-worm IoC patterns. Outside that scope, no traffic is decrypted. The decision is conscious, not a default — the policy file documents the cert-pinning posture on every other rule, and DECRYPT_NOT_ALLOWED is set explicitly on each one.
The proof is in the scenario UI. A prompt-injected agent attempts two HTTPS GETs to raw.githubusercontent.com. The first hits a compromised-repo path; the second hits a legitimate path. The first is closed at the gateway before the origin sees the request. The second returns HTTP 200. Same domain, same TLS handshake, different outcome based on URL path. The AI-platform-trust-by-domain stack cannot solve this. The network layer can.
Where the VCA Ends and The AI Layer Begins
This is network-layer containment. It does not inspect prompt content, validate tool arguments, or filter model responses for sensitive data. That is the AI guardrail layer — Bedrock Guardrails today, an Aviatrix-native primitive on a future date. The VCA's architecture leaves a clean insertion point for the AI layer and does not pretend to be one. Both tiers matter. Network containment bounds where an agent can reach. The AI layer bounds what an agent can see and say. The argument we make to security buyers is that the lower tier is enforceable today with existing Aviatrix primitives, and that pretending to cover the upper tier would erode credibility on the layer the product does cover.
Three Things to ask Your Team this Week
Where are AgentCore Runtimes running in our environment, and is each one in VPC mode with subnets we control? AgentGuard answers the first half of that question from cloud telemetry alone, with no gateway insertion required.
If a prompt-injected agent attempted to exfiltrate customer data to an attacker-controlled domain right now, where in our stack would the connection be denied? If the honest answer is we would see it in flow logs tomorrow, the VCA is the deployment artifact that changes the answer.
Does our IAM policy for AgentCore creation include a condition that requires VPC mode and the approved subnets, or could a developer create a Runtime that escapes containment by mistake?
Next Steps
Validated Containment Architecture for AWS Bedrock AgentCore is now available. The Terraform blueprint, the platform-architect 101, the security-buyer 101, and the deep-dive 201 whitepaper ship together. Aviatrix Distributed Cloud Firewall customers on Controller 8.1 or later can deploy the blueprint today. Selective TLS decryption for URL-path enforcement requires Controller 9.0.
Ask your Aviatrix account team for a guided deployment focused on one AgentCore landing zone. The standing offer is to walk through Terraform apply, the six scenario cards, and the back-out path — end to end, against your AgentCore configuration, in under an hour.
Lab-tested before it arrives. Deployable the day it ships.
Frequently Asked Questions
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.
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.
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.
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.
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.
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.
