Yesterday Doug declared the Containment Era. Today I want to show you what it looks like in production for AI workloads.
When prevention fails and detection is too slow, containment decides whether the incident becomes a catastrophic breach. That is the category. Zero Trust for AI Workloads is how we operationalize it — default-deny, network-layer Workload Containment for every AI agent, every LLM proxy, and every agentic framework running in your cloud. No code changes. No SDK integration. Available today on the Containment Platform customers already run.
Why AI Workloads Need Their Own Enforcement
Four realities are converging. First, shadow AI is everywhere. Developers are pointing backend services directly at OpenAI, Anthropic, Bedrock, and Gemini APIs. Third-party SaaS vendors are sending enterprise data to LLMs without disclosure. Eighty-three percent of organizations use AI in daily operations; only 13% have visibility into how. Code-based solutions — LiteLLM, SDK integrations, browser extensions — see what developers instrument and miss everything else.
Second, AI workloads have unrestricted egress by default. An MCP server that only needs api.github.com can reach anywhere on the internet. A RAG pipeline that should only call Bedrock can call any provider. Cloud native NAT gateways have no concept of approved AI providers, and Kubernetes NetworkPolicy cannot filter by domain.
Third, detection cannot distinguish compromised AI from legitimate AI. AI agents are autonomous, non-deterministic, and make outbound calls on behalf of an LLM. 82% of intrusions now use valid credentials — trusted code doing trusted-looking things. The Cascade proved this: trusted software moving through trusted pipelines is invisible to detection. The only defense is to govern what the workload can reach.
Fourth, compliance frameworks are ahead of the tooling. The EU AI Act, SOC 2, HIPAA, PCI-DSS, DORA, and FedRAMP all require proof of least-privilege governance. Most organizations do not have it for AI.
This is The Toxic Combination for AI security. One path leads to more application-layer gateways that only see the traffic routed through them. The other leads to Communication Governance at the network layer — the only control point that covers all AI traffic, instrumented or not.
How It Works: Deny by Default, Enforce at the Network
Zero Trust for AI Workloads extends Aviatrix Distributed Cloud Firewall into the AI era. Start in log-only mode to observe your AI egress patterns. Promote approved providers to permit. Deny everything else. You see before you enforce — no one flies blind, nothing breaks on day one.
Two capabilities make it work:
AI WebGroups — curated, auto-updated destination lists covering the entire AI provider landscape: OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, Google Vertex, and more. Aviatrix already knows every AI provider domain so you do not have to.
SmartGroups — identity-based workload tags by Kubernetes label, cloud tag, namespace, or Lambda ARN. Policy follows the workload, not the IP address.
Distributed Cloud Firewall combines SmartGroups as sources and AI WebGroups as destinations into permit/deny rules. Enforcement happens at the VPC boundary via spoke gateways — where Kubernetes egress actually occurs. A single rule can say: "only production workloads tagged as approved can reach Bedrock; dev can experiment with any provider; everything else is denied." One policy model covers Kubernetes pods, VMs, and Lambda, across AWS, Azure, GCP, and OCI.
No TLS decryption. No MITM. Enforcement uses SNI-based filtering at the spoke gateway — the place where egress actually happens. You can start in log-only mode to observe your AI egress patterns, promote approved providers to permit, and deny everything else. Shadow AI stops growing the moment default-deny is on.
Map that to the formal framework. Distributed Cloud Firewall enforcement at the VPC boundary is path-complete — it governs every communication path, including those that bypass centralized inspection. SmartGroups deliver identity-aware policy at the workload level. Coverage across Kubernetes, VMs, and Lambda is compute-model agnostic. A single rule propagating across all four clouds is universally propagated. And default-deny is detection-independent by design: enforcement holds whether or not you have detected the compromise. Five testable properties. All five delivered.
Why the Network Layer Is the Only Universal Control Point
We analyzed 41 MCP and LLM gateways — 19 open-source, 22 commercial. Not a single one provides network-layer enforcement. The entire gateway market operates at Layer 7. Anything that bypasses the gateway — a compromised agent, a misconfigured SDK, an unauthorized backend call — bypasses the entire security stack.
This is the Chokepoint Security pattern applied to AI: force traffic through a centralized inspection point and hope nothing routes around it. But Kubernetes pod egress frequently never traverses a central firewall. That is an architectural gap, not a configuration problem.
Application-layer AI security tools that govern content and prompts are complementary — they govern what the model sees and says. Aviatrix governs where the workload can reach. They deliver observability. We deliver enforcement. Visibility is not containment.
The Proof Point
The Fortune Global 500 customer that stopped The Cascade had Aviatrix in default-deny mode. When compromised code attempted to beacon to command-and-control infrastructure, the path did not exist. Four C2 IP addresses. One engineer. One policy update propagated across their entire cloud footprint. Zero credentials exfiltrated. The Blast Radius: one workload. The workload ran; the attack did not.
Through Aviatrix CoPilot, every AI egress decision is logged with full attribution — which workload, which destination, which policy, when. Continuous, audit-ready evidence of AI governance mapped to the EU AI Act, SOC 2, HIPAA, PCI-DSS, DORA, and FedRAMP. Compliance gets real answers, not point-in-time attestations.
Validated Containment Architectures: Day-One Containment for Every AI Workload
Enforcement is only as good as the architecture that deploys it. That is why we are shipping Validated Containment Architectures — lab-tested, partner-validated containment deployments for specific AI workload types. Each one includes an insertion pattern, an AI-aware SmartGroup model, and a baseline policy pack. Security teams deploy from day one. No SDK. No developer compliance.
Wave 1 ships May 27 with three architectures validated alongside AWS, Microsoft, and OBOT, a new Aviatrix partner: Contain AWS Bedrock AgentCore — default-deny MCP egress where each agent declares allowed destinations as policy-as-code. Contain Azure AI Foundry Agents — SmartGroups target ai_agent resource types directly, with east-west segmentation that prevents agent-to-agent lateral movement. Contain Enterprise MCP Infrastructure — zero-trust egress per MCP server, where OBOT-style CRDs let MCP server authors declare network scope at deployment time.
Five more Validated Containment Architectures follow on a weekly cadence through July — covering GitHub Pipelines, enterprise AI chat, NemoClaw agentic environments, and more. Each ships with a reference architecture diagram, deployment guide, SmartGroup model, and baseline policy pack, published on GitHub and the Aviatrix docs site. The roadmap is prioritized by what enterprises are actually running.
Blast Radius is determined by architecture — not by how fast you detect. Validated Containment Architectures make the default posture for every new AI workload type "contained on day one" rather than "governed eventually."
Aviatrix AgentGuard: From Discovery to Containment
Validated Containment Architectures solve containment for organizations that know what to govern. But IBM's 2025 Cost of a Data Breach Report found that shadow AI adds an average of $670,000 in additional breach costs per incident. You cannot enforce what you cannot see.
Aviatrix AgentGuard — now in early access — is the industry's first Containment Platform purpose-built for AI agents. It discovers every AI workload in your cloud, maps the LLMs and tools each agent connects to, builds a continuous risk profile, and delivers the enforcement path from discovery to Workload Containment on a single fabric. Chris McHenry will detail the full AgentGuard architecture tomorrow.
Getting Started
Zero Trust for AI Workloads is generally available today — no TLS decryption, no code changes, no new agents. Existing Distributed Cloud Firewall customers add new rules to the firewall they already run. New customers deploy through the AI security use case and expand from there.
AgentGuard early access is open. Request access. The first three Validated Containment Architectures ship May 27.
One question: Can you say — right now — which AI providers your workloads are allowed to call, and how you enforce that? If the answer is "we don't know" or "we can't," that is the gap Zero Trust for AI Workloads closes. Register for early access.
