CrowdStrike sat down to contain their own autonomous AI agents and did not put detection at the base of the stack. They put a default-deny network boundary. From the best detection engineering organization on the planet, that is a clear signal about where the industry is heading.
On August 4, they published the architecture they use to run offensive AI agents safely: not a prescriptive guide for what enterprises should do, but their actual running architecture, documented from operational necessity. It describes seven independent control layers, each built on the assumption that the others might fail, and states that all of them are implemented and running. The layer listed first is network isolation.
Their harness environments sit on an isolated VLAN behind a restrictive firewall policy. Egress is default-deny. Only the destinations an agent actually requires, such as the model API endpoint, are reachable. Outbound traffic routes through controlled proxies that inspect and log. Higher-risk work runs in separate cloud accounts with their own restricted identities. The reason CrowdStrike gives for putting this first is that when every inner layer fails, the agent still has no route to the internet or to adjacent internal systems.
The governing principle they name: “contain by construction, not by trust": treat the agent the way a security engineer treats untrusted code. CrowdStrike has spent decades building the tooling, the data pipelines, and the expertise that define what world-class detection looks like. But when they had to contain something they did not fully trust, they did not reach for their own platform. They reached for a network boundary.
At Aviatrix, we have been making the same argument for enterprise cloud environments since before AI agents were part of the conversation: the network boundary is the control that works even when every other layer fails. Seeing CrowdStrike reach the same conclusion under real operational pressure is exactly the kind of external validation that moves this from “Aviatrix position” to “industry consensus.”
The interesting question is what it takes to build the same thing outside a controlled lab.
Seven Layers, and What Each One is Doing
Layers 1 through 4 are nested. An action has to travel outward through all of them to get out. Layer 1 is the network isolation described above. Layer 2 puts each harness in a dedicated virtual machine, never on a workstation or shared host, so a full compromise stays inside a disposable guest. Layer 3 runs agent workloads in containers with syscall filtering and unprivileged execution. Layer 4 is a component they call ward, which confines the agent process to declared filesystem paths and network endpoints using kernel-level sandboxing, with permissions that cannot be widened once applied.
Layers 5 and 6 are peers rather than a stack. One mediates tool calls at the Model Context Protocol layer, checking method names and parameters against policy. The other intercepts shell commands before execution and returns allow, log, escalate, or deny. Layer 7 caps volume: quotas, rate limits, wall-clock ceilings, and spend limits, all failing closed.
CrowdStrike is direct about where this design is soft. Command filtering matches known-dangerous patterns, so a sufficiently novel invocation could slip past it. The tool-call gate and the command gate do not back each other up, and an action channel nobody anticipated would bypass both. Their answer is that enforcement was never resting on the gates. Whatever channel an action arrives through, it still has to clear kernel-enforced path policy, container and VM isolation, and default-deny egress.
That is the design decision worth studying: the layer that catches failures nobody predicted is the one that does not need to know what it is looking for.
Why East-west Traffic Security Is the Layer That Holds
A detection control needs a signal. It has to recognize something as bad before it acts, which means it fails against anything it has not seen. A pattern-matching command filter fails the same way, one level down.
A reachability control asks a different question. Instead of evaluating whether an action looks malicious, it evaluates whether a path exists between this workload and that destination. If policy never granted the path, the connection does not form. That property holds against novel commands, unknown channels, prompt injection, and compromised Trust Chain components equally, because none of those change what the network permits.
This is why CrowdStrike put the network at the base of the stack rather than the top. The controls above it are more precise and more informative; the control below them is the one that keeps working when precision fails. The Blast Radius of any failure is bounded by the paths that exist, not by the paths an attacker might want.
The Containment Era is built on the same principle: architectural properties that hold before, during, and after a failure, without requiring anyone to detect the failure first. If there were any remaining question about whether detection-first or containment-first is the right foundation for AI agent security, CrowdStrike’s architecture is the answer. Instead of reaching for their own platform to solve this, they reached for a network boundary. That is not a knock on detection: it is an acknowledgment that the base of the stack needs to work even when detection fails.
What the Enterprise Version Actually Requires
CrowdStrike’s Layer 1 works because they own the substrate. One harness, one VLAN, one firewall policy, one egress proxy. They decided what the environment looks like and drew a line around it. That is a meaningful achievement, and the design reflects real operational discipline.
One seam is worth naming: not to criticize the design, but because it is the exact problem the enterprise version has to solve differently. Their architecture routes outbound traffic through controlled proxies that inspect and log. Proxy inspection is a detection control: it has to identify a request as problematic before it can act, which places it in the same category as the command filter and the tool-call gate. A proxy evaluates what it can recognize. A structurally valid request passes regardless of intent, which is why proxy-traversal is a documented pattern in AI agent escapes: the request looks fine to the inspection layer, so the inspection layer approves it. A proxy that inspects and logs adds real visibility. But the allowlist enforced before traffic reaches the proxy is the containment boundary, not the proxy itself. CrowdStrike layers other controls around this, which is the right approach. The point is simply that inspection and containment are different things, and only one of them bounds the Blast Radius.
Production AI workloads do not have the shape of a controlled lab in any case. A retrieval pipeline runs in one VPC and queries a vector database in another. An agent framework in AWS calls a model endpoint in Azure. MCP servers run on Kubernetes with pods that are replaced hourly and IP addresses that mean nothing five minutes later. Managed services sit outside any subnet you control, reachable over paths you did not build and cannot put a proxy in front of.
Three questions fall out of that, and they are the right ones to ask about any AI deployment:
Where is the VLAN when the workload spans two cloud providers? There is no single broadcast domain to isolate. The boundary has to be defined somewhere other than network topology.
What does default-deny egress mean when a single service has a dozen outbound paths, several of them to managed services that never traverse a gateway you operate? Chokepoint Security governs the traffic that passes through the chokepoint. Anything routed around it is ungoverned.
What identifies the workload when the IP address changes on every deployment? Policy written against addresses describes a network that no longer exists by the time it is enforced.
None of this makes the principle wrong, but it makes the implementation non-portable. East-west traffic accounts for roughly 70-80% of cloud network traffic, and in most environments, it is governed only by broad security group rules that permit nearly everything inside a VPC. An isolated VLAN is one way to bound that traffic, but it is not a way that survives contact with multicloud.
The Enterprise Version of Layer 1 Has to Live in the Fabric
This is the problem Aviatrix has been working on since before AI agents were part of the conversation. Complex multicloud environments, with workloads spanning VPCs and cloud providers, managed services on paths you do not control, and infrastructure that changes faster than IP-based policy can track, need Communication Governance enforced in the fabric the traffic already crosses. The enterprise version of CrowdStrike’s Layer 1 has to live there, and it has to be written against workload identity rather than addresses.
Aviatrix SmartGroups resolve Kubernetes pod labels, namespaces, service accounts, cloud tags, and Lambda ARNs into workload identity in near-real-time, so policy follows a workload when it scales, moves, or gets replaced. WebGroups define permitted destinations for AI-specific traffic, covering model providers, vector databases, and agent platforms. The Distributed Cloud Firewall enforces the resulting rules at every VPC egress point across AWS, Azure, Google Cloud, and OCI, without TLS decryption, without an SDK, and without changing application code.
The practical shape of a policy is short. Production workloads reach an approved model provider. Development workloads reach any approved provider. Everything else is denied, and the final rule denies all egress by default. A compromised workload cannot reach a destination that policy never permitted, whatever the code is doing and whoever signed it. That closes the proxy seam too: the allowlist is enforced at the fabric, so there is no trusted hop that can be traversed to reach a destination policy never opened.
For MCP deployments, the same logic applies per server. A GitHub MCP server reaches its declared API endpoint and nothing further, so a compromise cannot become exfiltration, because the egress path was never created. Aviatrix Zero Trust for AI Workloads supports a log-only mode so teams can observe real egress before enforcing anything, which is the same observe-first approach CrowdStrike recommends for rollout.
None of this replaces the inner layers. Container isolation, process confinement, and tool-call mediation all do work that Communication Governance cannot do, and CrowdStrike’s design is right that no single control should be trusted alone. The outermost boundary has to exist somewhere, and in an environment where no VLAN spans the workload, the only place it can exist is the fabric the traffic already crosses.
The Question to Bring to Your Own Environment
CrowdStrike treats its agents as untrusted code and contains them by construction. It's the correct instinct, and the seven-layer design is good engineering worth borrowing from.
The open question is for everyone running agents in production rather than in a research harness. Those agents are calling models, querying data stores, and reaching MCP servers across VPC and cloud boundaries right now. Ask which control in that environment does the job CrowdStrike assigned to Layer 1, and what an agent can reach today if every layer above it fails.
The business stakes are high. An AI agent with an open east-west path and access to a model context window that includes customer data can exfiltrate that data through a request that looks like normal model traffic. SEC disclosure obligations apply when that data includes material nonpublic information. The board conversation the morning after is not about the agent: it is about why no architectural control existed to prevent the path. That is the conversation CrowdStrike’s team avoided by building Layer 1 first.
If the answer is a security group that permits most traffic inside the VPC, the outermost layer is missing.
Map what your AI workloads can actually reach today with a 15-minute Workload Attack Path Assessment.
For more context on how Communication Governance applies to AI deployments, learn more about Aviatrix Zero Trust for AI Workloads.
Frequently Asked Questions
Layer 1 is network isolation. CrowdStrike places its agent harness environments on an isolated VLAN behind a restrictive firewall policy with default-deny egress, so only the destinations an agent requires can be reached. It is the outermost of seven layers, and the one CrowdStrike relies on when the inner layers fail.
Detection has to recognize an action as malicious before it acts, so it fails against anything it has not seen before. Reachability enforcement does not evaluate the action at all. It evaluates whether policy permits a path between two workloads, and an unpermitted connection never forms. That holds against novel commands, prompt injection, and compromised dependencies alike.
Not when it depends on a VLAN or a single inspection gateway, because neither spans cloud boundaries. It works when policy is enforced in the cloud network fabric at each VPC egress point and written against workload identity instead of IP addresses. Aviatrix enforces this model across AWS, Azure, Google Cloud, and OCI.
Write policy against workload identity rather than addresses. Aviatrix SmartGroups resolve Kubernetes pod labels, namespaces, service accounts, cloud tags, and Lambda ARNs into identity in near-real-time, so the policy follows a workload when it scales, moves, or is replaced. Rules written against IP addresses describe a network that has already changed by the time they are enforced.
No. Container isolation, process confinement, and tool-call mediation each do work that network policy cannot do, and CrowdStrike's design is right that no single control should be trusted on its own. East west traffic security is the outer boundary that catches what the inner layers miss, not a substitute for them.
East-west traffic is roughly 70-80% of cloud network traffic. Most security investment sits on north-south perimeter controls that never see it, which is why open east-west paths remain the mechanism attackers use to move between workloads after an initial compromise.
Ready to see Aviatrix in action?
Get a personalized live demo walkthrough or explore our latest deep-dive cloud threat research intelligence.
Gartner Strategic Roadmap for Zero Trust Security Programs 2025 Report
Download and gain actionable insights to advance your cloud security strategy.
