Intrusion detection systems are moving from near-total reliance on known signatures toward a hybrid architecture that combines traditional matching, machine learning, and agentic investigation. An analysis published on the Stack Overflow blog argues that SnortML represents a low-level sensing layer within Snort 3, while agentic artificial intelligence connects events across time and sources and determines the next step in the investigation.
The problem with traditional signatures is not that they are inaccurate, but that they are accurate with respect to what they were designed to detect. A rule tailored to a specific vulnerability, such as CVE-2024-12345, may detect the known exploit with a very low false-positive rate, but it may not respond to a modified payload that passes through the same vulnerable code path. Between the appearance of a new exploit in the wild and its analysis, rule writing, testing, and distribution, days or weeks may pass—a dangerous gap when the vulnerability is being actively exploited.
How Does SnortML Work Inside Snort 3?
Cisco Talos introduced the SnortML engine in March 2024 as a machine-learning detection engine that runs natively inside Snort 3. The engine does not rely on an external cloud service; inference takes place locally within the same processing path used to evaluate rules, and it produces a result in less than one millisecond.
The implementation consists of the snort_ml_engine module, which loads pretrained TensorFlow models at startup, and the snort_ml inspector, which receives data from Snort 3’s existing service inspectors through the publish-subscribe interface. When the HTTP inspector finishes analyzing a request, it sends the query string and POST content to the event bus; SnortML then classifies them and returns a probability value indicating the likelihood that they contain an exploit attempt.
The model uses an LSTM network preceded by an embedding layer that converts raw byte values into vector representations, allowing it to capture relationships and context between bytes before the LSTM processes their order and sequence. A final dense layer reduces the result to a single probability value. LibML, included with SnortML, uses the XNNPACK library to accelerate matrix operations. According to the article, a single classification takes approximately 350 microseconds on an AMD processor clocked at 4.7 GHz.
Starting with Secure Firewall 10.0.0, SnortML automatically selects an appropriate model for lengths of 256, 512, or 1024 bytes. Requests longer than 1024 bytes are truncated at that limit before classification. The first release detected SQL injection; coverage expanded by late 2025 to include XSS and command injection, and model updates are delivered through the same Lightweight Security Package system used to distribute rule content.
The Strengths and Limitations of the Hybrid Approach
SnortML operates in parallel with signature matching rather than replacing it. The model can detect new variants of attacks that fall within known categories, while traditional signatures provide a low-noise baseline for confirmed patterns. When both paths generate an alert for the same payload, this can be considered a stronger signal than an alert produced by machine learning alone, while each mechanism retains different error characteristics.
However, SnortML analyzes a single HTTP parameter, such as a URI query string or POST content, and does not know what happened before or after the request or what the source address did during the preceding minutes. Consequently, a sequence of reconnaissance, enumeration, and tailored exploitation may pass without any individual step exceeding the detection threshold. The current model also does not see DNS tunnels, TLS-layer attacks, SMB exploitation, or anomalous behavior in non-HTTP protocols, because the available models are tied to the HTTP inspector data path.
The processing time of approximately 350 microseconds also adds a real cost, although it is limited and predictable thanks to XNNPACK. Model performance should therefore not be considered separately from the size of the rule set, protocol complexity, and processing budget of the security appliance.
What Does Agentic Artificial Intelligence Add?
The analysis distinguishes between a machine-learning model that evaluates only what is in front of it, a SOAR playbook that follows fixed steps, and an agent that maintains the state of a multistage investigation and decides what should be examined next based on previous results. According to the proposed concept, the agent can query the SIEM for related events, check a file hash through a threat-intelligence platform, retrieve user activity from the identity provider, and then assemble the context before recommending a response or referring it to a human analyst.
The article points to IBM’s launch of the ATOM platform, or Autonomous Threat Operations Machine, in April 2025, and Trend Micro’s launch of Agentic SIEM in August 2025. These systems are presented as mult-agent coordination and investigation platforms, not merely conversational interfaces equipped with security information. The analysis links their spread to the workforce shortage, citing a global gap of approximately four million vacant cybersecurity positions, along with a 2025 survey reporting that 82% of security operations center analysts are concerned about missing real threats because of alert volume.
In this architecture, Snort 3 and SnortML become sensors close to the network, providing the higher reasoning layer with what was actually observed. However, the higher level of automation makes sensor accuracy more important: a false positive not only consumes analyst time, but also consumes agent resources and may trigger containment actions in poorly configured environments. SnortML’s probability output also makes it possible to build a composite confidence score; an alert combining a traditional signature with an ML score of 0.97 should be handled differently from an alert triggered by ML alone with a score of 0.61.
Integration Architecture and the Feedback-Loop Problem
The article proposes an architecture that begins with packet capture through DAQ, using AFPacket RSS or DPDK according to throughput requirements, followed by a detection layer that runs the MPSE Hyperscan engine and SnortML in parallel. Both layers send JSON-formatted events containing alerts, probability scores, and flow data to a unified measurement bus.
The tasks are then distributed among specialized agents: an agent for triage, deduplication, and severity estimation; agents for enrichment and threat intelligence; an investigation agent that links SIEM logs, identity-provider records, and endpoint data; and a context agent that compares activity with historical patterns and known campaigns. The concept emphasizes the need to feed confirmed investigation results back into the model and rule engines rather than allowing the flow to stop at the response stage.
Payloads confirmed to be attacks but assigned a low score or not matched by a signature can be converted into training data or inputs for drafting new rules. However, this path requires human validation and mechanisms for detecting training-data poisoning, as an attacker may attempt to manipulate automated investigation results to introduce corrupted samples into the retraining process.
Deployment Constraints and Practical Recommendations
The analysis identifies additional gaps, including the current restriction of SnortML coverage to HTTP parameters, the immaturity of agent coordination protocols, and the limited interpretability of model alerts. Current outputs show the probability score and the payload that triggered the alert, but they do not explain which bytes or regions of the input influenced the result. According to the article, the model’s resilience to obfuscation, encoding, whitespace manipulation, and SQL comment injection has not been publicly described in published evaluations.
Practically, the article recommends initially running SnortML on a monitoring port and in alert-only mode, not inline with blocking. False positives should be measured against known application traffic for at least two weeks covering normal work cycles, and thresholds should then be tuned before enabling selective inline deployment. The ML score should also be treated as one factor in a composite confidence calculation, not as a replacement for a traditional signature or a standalone blocking trigger.
High-impact containment actions, such as blocking IP addresses, isolating devices, or resetting credentials, should remain within a human review loop. The analysis’s main conclusion is that automation can handle triage, enrichment, correlation, and context aggregation at scale, while the final response decision remains safer when reviewed by a human based on the context gathered by the agent.