Why joining OISF is a natural extension of how Aviatrix has always thought about cloud security
The Containment Era is defined by a simple shift in assumption: attackers will land. The question is what they can reach when they do.
Aviatrix was built around that assumption from the start. Communication Governance enforced at every workload bounds the Blast Radius the moment a compromise begins. Suricata — embedded in the Aviatrix platform as our core IPS — watches every bounded space inline, on the data path, across AWS, Azure, and GCP. DCF drops unauthorized connections at the first hop before a threat can propagate.
Contain. Detect. Eliminate. That’s not a roadmap. It’s how the platform has always operated. Today’s announcement is about investing in the open-source community that powers the detection layer at the center of it.
Why We’re Joining OISF
Suricata has been running inline in the Aviatrix platform since its integration as our core IPS — doing deep packet inspection, processing custom rulesets, decrypting TLS traffic for full visibility in IPS + TLS Decrypt mode, and feeding directly into the Distributed Cloud Firewall (DCF) enforcement layer. It is not a new integration. It is the detection engine at the core of the Aviatrix IPS.
As AI workloads have become a primary attack surface, Aviatrix has extended that detection depth accordingly. The platform now ships 556 purpose-built Suricata rules covering AI-specific threat categories: prompt injection and jailbreak detection, sensitive data leakage, malicious tool usage, data exfiltration, agent-to-agent threats, and malicious file uploads. These rules operate inline within the Aviatrix traffic inspection pipeline — after TLS termination and decryption — confirmed zero false positives across live gateway validation against benign traffic. This is Suricata doing work that no general-purpose ruleset was built to do.
That engine is also one of the most actively developed projects in open-source security. In the past twelve months alone, 44 developers contributed new code to Suricata — placing it in the top 2% of all project teams on Open Hub. More than 300 contributors and 22,800+ commits. This is not a static project maintaining old signatures. It is a growing, innovating community meeting the evolving demands of network security.
One area where the community has room to grow: cloud native coverage. Detection rule sets and deployment patterns have largely been built for on-premises infrastructure, while enterprise workloads have moved to the cloud. By joining OISF as a consortium member, Aviatrix is contributing engineering resources, multicloud reference architectures for AWS, Azure, and GCP, and cloud native detection rule sets covering IAM lateral movement, IMDS abuse, Kubernetes service token theft, and Cascade-class supply chain attack patterns. Every Suricata deployment worldwide benefits — not just Aviatrix customers.
Why the Sequence Matters
Contain-Detect-Eliminate reorders the traditional security cycle deliberately. Most architectures detect first and contain after — which means Blast Radius is still expanding when the first alert fires. Aviatrix enforces containment first. By the time Suricata identifies a threat, the attacker is already operating in a bounded space. Detection becomes faster and more precise because the surface it’s watching is finite.
This is the fundamental difference between chokepoint security and Containment Architecture. A chokepoint governs only the traffic that routes through it — K8s pod egress, serverless functions, east-west VPC traffic, and newly deployed workloads can all move outside its view. Containment Architecture enforces policy at every workload, every path, every region — automatically propagating to new workloads the moment they’re deployed.
Consider what this looks like against a real AI workload threat. An AI agent is asked to build a slide deck. It searches Confluence, reads confidential product roadmap data, and — unable to deliver the file locally — attempts to upload it to a public file-sharing site. Without network security, that data is gone. With Aviatrix: egress policy locks down risky MCP servers before the upload attempt begins (Contain). Suricata detects the bulk encoded payload in outbound HTTP and drops the connection inline (Detect). Every blocked attempt fires a critical alert to the SOC with full policy citation, source workload, and destination (Eliminate). The confidential data never leaves the environment.
An AI agent exfiltration attempt — and how Aviatrix stops it at each stage.
Elimination closes the loop. In a detection-only world, eliminating a threat means blocking a session or quarantining a host — reactive, after the attacker has already moved. In the Containment Era, DCF drops the connection at the source the moment Suricata fires. The threat is removed before it can reach anything else, because containment already bounded what it could reach.
Where This Lives in DCF
The Distributed Cloud Firewall is where all three stages operate as one system.
DCF continuously discovers every VM, container, serverless function, and managed service across clouds — including ephemeral resources legacy tools miss. Workloads are grouped by identity, not IP, using cloud native tags, labels, namespaces, and service identity via SmartGroups. Policy is defined once and enforced everywhere across AWS, Azure, and GCP, with full L4–L7 inspection at the source of traffic. All policies are managed as code through Terraform and CI/CD pipelines — auditable, repeatable, and fast.
Suricata runs on that same data path — watching every packet moving through the bounded space DCF defines. One architecture. One data path. Containment, detection, and elimination operating as a unified system.
See how DCF brings it together.
Explore Aviatrix Validated Containment Architectures, lab-tested deployment blueprints that offer containment architectures for specific AI platforms.
Frequently Asked Questions
Contain-Detect-Eliminate is the Containment Era security sequence Aviatrix operates on: bound what a compromised workload can reach first, detect the threat inside that bounded space, then eliminate it at the source. The order is deliberate. Most architectures detect first and contain after, which means the Blast Radius is still expanding when the first alert fires. Aviatrix enforces Communication Governance at every workload before any alert, so by the time Suricata identifies a threat the attacker is already operating in a finite, bounded space. Detection becomes faster and more precise because the surface it watches is small.
Suricata, the open-source engine governed by OISF, has run inline as the core intrusion prevention system inside the Aviatrix platform since its integration. It performs deep packet inspection, processes custom rulesets, decrypts TLS traffic for full visibility, and feeds the Distributed Cloud Firewall enforcement layer. As a consortium member, Aviatrix contributes engineering resources, multicloud reference architectures for AWS, Azure, and GCP, and cloud native detection rule sets covering IAM lateral movement, instance metadata service abuse, Kubernetes service token theft, and Cascade-class supply chain attack patterns. Every Suricata deployment worldwide benefits, not only Aviatrix customers.
Aviatrix ships 556 purpose-built Suricata rules covering AI-specific threat categories: prompt injection and jailbreak detection, sensitive data leakage, malicious tool usage, data exfiltration, agent-to-agent threats, and malicious file uploads. The rules run inline within the Aviatrix traffic inspection pipeline after TLS termination and decryption, and were validated against live gateway traffic with zero false positives against benign traffic. This is detection depth no general-purpose ruleset was built to deliver.
Aviatrix stops it at each stage of Contain-Detect-Eliminate. Consider an AI agent asked to build a slide deck that reads confidential roadmap data from Confluence and tries to upload it to a public file-sharing site. Contain: egress policy locks down risky Model Context Protocol servers before the upload begins. Detect: Suricata identifies the bulk encoded payload in outbound traffic and drops the connection inline. Eliminate: every blocked attempt fires a critical alert to the security operations center with full policy citation, source workload, and destination. The confidential data never leaves the environment.
A chokepoint governs only the traffic that routes through it, so Kubernetes pod egress, serverless functions, east-west traffic between Virtual Private Clouds, and newly deployed workloads can all move outside its view. Containment Architecture enforces policy at every workload, every path, and every region, and propagates automatically to new workloads the moment they are deployed. In Aviatrix, the Distributed Cloud Firewall and Suricata run on one shared data path, so containment, detection, and elimination operate as a single system rather than separate tools.
Containment is the architectural enforcement of explicit communication policy at every workload — governing what it can reach and what can reach it, at the granularity of workload identity and protocol — on every path available to it, independent of whether a compromise has been detected. In other words, containment is not a reaction that triggers after a threat is spotted; it is enforced by architecture before, during, and after a breach. This is what makes the sequence work: because Communication Governance has already bounded what any workload can reach, a compromised workload is operating in a finite space the moment it lands, and detection and elimination follow inside that boundary. As the principle goes: when prevention fails and detection is too slow, containment decides whether the incident becomes a catastrophic breach.
