Bedrock Guardrails Won't Stop an Exfiltrating Agent, But Here's What Will

If you're running agents on Amazon Bedrock AgentCore, you've probably already turned on Bedrock Guardrails, and you should keep them on. But ask yourself a different question: when a compromised agent opens an HTTPS connection to a domain you've never heard of, what stops the packet? 

Bedrock Guardrails won't, and that's not a knock on AWS. AWS built Guardrails to govern content: prompts, model responses, tool arguments. They operate on what the agent says, and they have no opinion on where the agent connects. An AgentCore Runtime, by default, can reach any destination on the internet the moment it starts, and its outbound tool calls, model invocations, and remote MCP connections look identical on the wire to legitimate work. 

That's the gap: content governance without communication governance. It's exactly the gap attackers walked through in March 2026. 

The Kill Chain that Content Filters Can't See

The Cascade of supply chain attacks in March followed a pattern worth studying because every stage before the last one defeats a different control you probably already own. 

It starts with a malicious npm package planted in an agent toolchain. No known CVE at install time, so it passes vulnerability scanning. Then a compromised MCP tool response injects a follow-on instruction into the agent's context window: collect data, upload it to an attacker host. Prompt injection defenses catch some of this; they don't catch all of it, and one miss is enough. The agent then uses its own legitimate Confluence, S3, and service permissions to gather confidential content. To your identity governance tooling, this looks like an authorized workflow, because it is one, technically. 

Then comes stage four: the agent makes an HTTPS POST to an attacker-controlled domain. This is the first moment in the entire chain where the malicious activity is unambiguous at the network layer. The destination is not something your agent has any business talking to. 

If nothing sits in that path, the data leaves. If a default-deny enforcement point sits in that path, the TCP handshake never completes. One Aviatrix customer with workload-level communication governance in place saw exactly that during the Cascade of March 2026: the exfiltration attempt was blocked before the first packet left the VPC. Detection saw it in the logs, but it was the architecture that stopped it. 

Why AgentCore Makes this Your Problem

AgentCore's shared responsibility line is clear: the Runtime's outbound connections belong to you, the tenant. AWS gives you the primitives. With VPC mode, each per-session microVM gets an ENI in subnets you control. What AWS doesn't give you is an in-path enforcement point that understands agent traffic, ships with a policy model for it, and blocks a PUBLIC-mode Runtime from ever being created outside your governed landing zone. 

Most teams respond in one of two ways. Some pile on more detection and hope SOC response outruns exfiltration. Others start hand-building egress controls from NAT gateways, security groups, and route tables, then discover that maintaining an allowlist of LLM provider endpoints and MCP platforms by hand is a full-time job. 

There's a third option: deploy an architecture that's already been built and tested. 

The Validated Containment Architecture for AWS Bedrock AgentCore 

We published a Validated Containment Architecture for AWS Bedrock AgentCore: a lab-tested, Terraform-deployable design that puts default-deny enforcement at every Runtime ENI. It's validated against the OWASP LLM Top Ten and MITRE ATLAS, and it deploys in 25 to 30 minutes with one terraform apply. No sidecars, agents in the container, or code changes are required. 

The design has three enforcement layers: 

Communication governance at the Runtime ENI. The Runtime subnet's default route points to an Aviatrix Spoke Gateway, so every outbound flow traverses the Distributed Cloud Firewall before the first packet leaves the subnet. A seven-rule policy pack evaluates first-match: sanctioned model providers and MCP platforms are permitted through Aviatrix-managed WebGroups that update themselves (no hand-curated FQDN lists), approved tool endpoints get an operator-maintained allowlist, DNS traffic to anything other than the VPC resolver is dropped to kill DNS-tunneled exfiltration, and everything else hits default-deny. Rule changes propagate in about 100 milliseconds. Your blast radius is bounded by the policy at the moment of compromise, not by how fast your SOC responds. 

Ingress through PrivateLink. Two interface endpoints anchor the AgentCore data plane and control plane inside the landing zone, with ingress rules keyed to client VPC identity. VPCs you haven't authorized can't initiate agent sessions. 

Control-plane containment through IAM. A managed policy with condition keys on bedrock-agentcore:subnets and bedrock-agentcore:securityGroups denies Runtime, Browser, and Code Interpreter creation unless the request references your approved landing-zone subnets. A PUBLIC-mode Runtime, which runs on AWS-managed infrastructure and never touches your enforcement point, fails at the AWS API before a single packet flows. This closes the drift path: nobody can quietly stand up an ungoverned Runtime next to your governed ones. 

And when something is blocked, you have the evidence in hand. Every deny logs to CoPilot with the workload identity, destination FQDN, human-readable rule name, and timestamp: the audit evidence HIPAA, SOC 2, and EU AI Act assessments ask for. 

What it Doesn't Do (On Purpose)

Scope honesty matters more in AI security than anywhere else right now, so here's ours. This architecture governs network reachability. It does not inspect prompt content, validate tool arguments, or filter model responses; that's the guardrail layer, and Bedrock Guardrails remain the right tool there. Both layers are required for a complete posture. Version one covers the AgentCore Runtime; Browser, Code Interpreter, and Gateway come in v2. The known constraints, including the TLS decryption prerequisites and the DNS resolver requirement, are documented on the architecture page before you find them in production. 

Try it Against Your Own Traffic

The Terraform blueprint is on GitHub, including a probe script and a scenario UI that lets you replay the kill chain above in your own lab. Deploy the policy pack in monitor mode first, watch what your agents actually talk to, then promote rules to enforcement one at a time. It requires Aviatrix Enterprise (Controller 8.2+); if you're new to Aviatrix, the 30-day trial on AWS Marketplace includes Validated Containment Architectures at no extra cost. 

Start with a 2-minute video that shows how Aviatrix Validated Containment for AWS Bedrock AgentCore stops an AI agent with valid credentials from exfiltrating data. Bedrock Guardrails decide what your agents can say, but you still have to decide what they can reach, and enforce it before the handshake completes.