Using a Local LLM to Explain Security Alerts: What Works and What Doesn’t

Security analysts are inundated with alerts, a challenge compounded by the need for rapid, context-rich explanations to determine true threats. Machine learning (ML) can help detect anomalies, but the “why” behind an alert is often missing. This is where Large Language Models (LLMs) offer intriguing potential. Running an LLM locally within a security monitoring system presents a compelling proposition: generating immediate, tailored explanations for alerts, suggesting concrete remediation steps, and even assisting in the creation of new detection rules—all without sending sensitive data to external services. But how well does this work in practice? Based on a lab project that built an integrated monitoring system for the OWASP Juice Shop application, we examine the role, capabilities, and significant limitations of a locally deployed LLM component. We’ll explore why you might run an LLM locally, what tasks it can be asked to perform, the guardrails necessary for safe operation, and a candid look at its observed strengths and weaknesses, including the fundamental challenge of applying ML to rare attack traffic. Remember, all such lab work should be conducted only in authorized, isolated test environments.

Why Integrate a Local LLM into Security Monitoring?

The primary motivation for running an LLM locally is control and privacy. By hosting the model within the monitoring infrastructure, telemetry and alert data never leave the controlled environment. This mitigates data exfiltration risks associated with cloud-based AI services and ensures compliance with data protection principles like minimization and redaction, which were design considerations for the system. The local LLM component acts as an on-demand analyst assistant, tasked with specific functions to augment human review rather than replace it.

Core Tasks for the LLM Component

In the lab system, the LLM service was prompted to perform three key defensive functions upon receiving an alert:

• Alert Explanation and Evidence Analysis: The LLM synthesizes the available alert context—HTTP metadata, matched rule details, ML scores, and behavioral indicators—into a coherent narrative. It is instructed to describe the observed anomaly, suggest benign alternative explanations for the activity, and explicitly note any missing evidence (like a full response body or independent audit log).
• Remediation Suggestion: Based on the type of attack indicator (e.g., SQL injection, path traversal), the LLM generates recommended steps for verification, mitigation, and prevention. These suggestions are grounded in security playbooks; for instance, SQLi recommendations target query parameterization and database privilege review.
• Detection Rule Proposal (for Human Review): For novel attack patterns, the LLM can be asked to draft a new detection rule, typically as a regular expression or logic condition, accompanied by positive and negative example HTTP snippets. Critically, these proposals enter a managed lifecycle with states like “proposed,” “validated,” and “active,” requiring explicit operator review and activation.

Architectural Guardrails and Output Control

Integrating a generative model into a security system necessitates strict guardrails to ensure reliability and safety. The project implemented several controls. The LLM call is wrapped in a dedicated service that enforces a strict JSON Schema for output, ensuring structured, parsable responses for explanation, assessment, and steps. The system uses prompt engineering to separate instructions from untrusted data (the HTTP request content), a basic defense against prompt injection. The context sent to the LLM is intentionally limited—to around 9,000 characters in this setup—and includes metadata noting if request or response bodies were redacted or unavailable, encouraging the model to acknowledge the limits of its analysis.

Furthermore, the rule proposal function includes pre-flight validation. Generated regex rules are checked for syntactic validity and are disallowed from containing potentially dangerous features like complex lookarounds or unbounded repetitions that could lead to Regular expression Denial of Service (ReDoS). Proposals are also tested against a small set of benign samples to catch obvious false positives before even being presented to a human. These guardrails are essential, but they do not eliminate all risks, such as hallucination or technically incorrect advice.

How the LLM Was Evaluated in the Lab Context

Evaluation focused on the appropriateness of the LLM’s outputs for the defined scenarios. The system was tested against common web attack indicators like SQL injection (SQLi), cross-site scripting (XSS), and path traversal. For each generated alert, the LLM’s analysis was assessed on criteria such as: Did the explanation correctly reference the evidence (e.g., “rule WEB-002 matched on the ‘q’ parameter”)? Did it acknowledge limitations (e.g., “the response body was not captured”)? Were remediation steps relevant to the alert type? Rule proposals were evaluated on syntactic correctness and basic coverage of the provided example, not on comprehensive attack-class detection.

It’s crucial to note that evaluation was qualitative and scenario-based within the controlled test environment. The LLM was not subjected to broad benchmarking frameworks like HELM. Its performance was tied directly to the quality and completeness of the evidence provided by the upstream detection pipeline. For instance, if the content ML model did not receive input because a request was only logged in an access log, the LLM would have less data to analyze, which was considered a system limitation, not an LLM error.

Observed Strengths and Practical Benefits

The local LLM integration demonstrated clear strengths in organizing and presenting information. It successfully consolidated multiple detection sources—rule matches, ML scores, and behavioral alerts—into a single, readable summary, saving an analyst time from manually correlating logs. Its ability to draft initial rule proposals based on a few example malicious requests showed promise for accelerating the detection engineering workflow. The structured output (JSON) allowed for easy integration into dashboards and ticketing systems. By running the Qwen3:4B model locally via Ollama, the system provided these functionalities without external API calls, with inference parameters like temperature set to 0 for more deterministic outputs.

LLM Task	Primary Strength	Key Constraint
Alert Explanation	Consolidates multi-source evidence into a narrative.	Limited by the evidence provided by the collection system.
Remediation Suggestion	Links alert type to standard security playbook actions.	Cannot verify exploit success; steps are generic.
Rule Proposal	Accelerates initial draft creation from samples.	Requires human validation and testing for coverage.

Candid Limitations and Where the LLM Falls Short

Despite its utility, the LLM component has significant limitations that necessitate human oversight. A core issue is hallucination or confabulation: the model can generate plausible-sounding but technically incorrect details or unsupported claims, such as asserting an attack succeeded without independent verification evidence. Its explanations, while coherent, are based on pattern recognition in the provided text, not on true understanding of the application’s state. The LLM also has no inherent knowledge of the current system; its “understanding” is bounded by the context window provided in the prompt.

Furthermore, the quality of analysis is directly gated by input quality. If the monitoring pipeline’s redaction or capture rules omit critical payload parts, the LLM works with incomplete data. The rule proposal function is particularly limited: generated rules are often literal matches to the provided example and do not generalize to cover an entire attack class. They require security expertise to expand and test properly. Finally, resource consumption is non-trivial; the 4-billion-parameter model requires several gigabytes of memory, and inference times can span seconds, which may not be suitable for high-volume, real-time alert streams without significant optimization.

The Base-Rate Problem: A Foundational Challenge for ML Detection

The LLM’s analysis is only as good as the alerts it receives, and those alerts originate from ML and rule-based detectors. This introduces a fundamental evaluation challenge known as the base-rate effect. In real-world traffic, malicious requests are extremely rare (low prevalence, π). Even with a good ML model that has a high recall (r) and low false positive rate (f), the precision of alerts—the fraction of alerts that are truly malicious—can be very low because of the overwhelming number of benign requests. The formula Precision = (rπ) / (rπ + f(1−π)) makes this mathematically clear.

In the lab environment with a higher concentration of attack traffic, this effect was less pronounced, allowing the ML models (LinearSVC and Isolation Forest) to appear more precise. However, this is not representative of operational deployment. The lab project’s ML was trained on a limited dataset of 847 samples. While techniques like class weighting were used, the model’s performance on truly novel, real-world traffic is uncertain. This base-rate reality means an LLM explaining alerts could be spending most of its time analyzing false positives if the underlying detectors are not tuned for a low-prevalence environment, highlighting that improving upstream ML precision is paramount.

Operational Considerations and System Design Lessons

Deploying such a system teaches several operational lessons. Observability is critical: the system used Prometheus to track metrics like request counts and detection sources, which is essential for understanding pipeline health and alert volumes. Data provenance and integrity are needed for forensic analysis; the system correlated events using request IDs and stored redaction logs. The durability of state—like behavioral detection windows—was a challenge, as a system restart could reset sliding window histories, affecting detection consistency.

From an integration standpoint, the LLM service was treated as a fallible component. Errors in ML inference or LLM timeouts were caught and handled gracefully, setting states to “unavailable” rather than crashing the pipeline. The architecture also maintained a clear separation: the LLM was used only for post-alert analysis and rule proposal, not for making blocking decisions. All active response measures would remain under direct human or deterministic rule control.

Key Takeaways

• A locally run LLM can provide valuable analyst support by explaining multi-source alerts, suggesting remediation from playbooks, and drafting initial detection rules, all while keeping sensitive data within the environment.
• Strict guardrails are mandatory, including output schema enforcement, prompt injection defenses, input truncation, and human-in-the-loop validation for any generated detection logic.
• The LLM’s utility is bounded by the quality and completeness of the evidence fed to it by upstream collection and detection systems; it cannot overcome gaps in telemetry.
• Hallucination remains a key risk, meaning all LLM-generated explanations and recommendations require expert review and independent verification against original evidence.
• The effectiveness of the entire system is subject to the base-rate fallacy; high alert precision in a lab setting with common attacks does not guarantee low false positive rates in real-world, low-prevalence conditions.

Frequently Asked Questions

Related reading: Monitoring OWASP Juice Shop with Rules, Machine Learning and a Local LLM

About the author