- How NLQ works
- Where NLQ is being adopted
- Why NLQ matters for security teams
- Five challenges NLQ solves in security operations
- Limitations of Natural Language Querying
- How NLQ fits into the agentic AI landscape
- How Corelight uses NLQ
- From NLQ to Agentic Triage
- Getting started with NLQ
- Frequently asked questions
Natural language querying (NLQ) lets analysts search and analyze security data in plain English. Learn how NLQ works, its limits, and its role in the SOC.
Natural language querying (NLQ) is the practice of using plain, conversational language to search, filter, and analyze structured data. Instead of writing queries in a specialized language like Structured Query Language (SQL), Search Processing Language (SPL), or Kusto Query Language (KQL), an analyst types a question in English. The system interprets that question, generates a valid query against the underlying data, and returns results.
The concept has existed in some form since the 1970s, when early systems like LUNAR converted English sentences into database queries using rule-based grammars. What has changed about NLQ is the technology behind it. Modern NLQ systems are powered by large language models (LLMs) that can interpret complex, ambiguous questions and map them to the correct tables, fields, and filters across large schemas. That shift has moved NLQ from an academic curiosity into a production capability across business intelligence, observability, and security operations.
In network security, NLQ is particularly significant. Security analysts work with some of the most complex and specialized data schemas in any industry: connection logs, DNS transaction records, TLS certificate metadata, and protocol-level fields across dozens of log types. The expertise required to query that data effectively has historically limited who can investigate threats and how quickly they can do so. NLQ removes that constraint.
How NLQ works
Under the hood, most modern NLQ systems follow a four-stage pipeline:
1. Intent parsing
The system interprets what the user is actually asking. "Show me anything unusual leaving the network after midnight" contains no specific field names, no operators, and no time format. The NLQ engine has to determine that "unusual" implies a deviation from the baseline, "leaving the network" refers to outbound traffic, and "after midnight" specifies a time range.
2. Schema mapping
Once the intent is understood, the system maps natural-language terms to the underlying data structure. This is one of the hardest problems in NLQ. A user might ask about "failed logins," but the underlying table calls that field `auth_status` with a value of `0`. The system needs to understand the schema well enough to bridge that gap. In security data, this challenge is amplified. Zeek® logs, Suricata® alerts, and SIEM platforms each have their own field-naming conventions, and the same concept (such as "bytes transferred") might be stored differently across log types.
3. Query generation
The system produces a structured query in the language used by the target platform (SQL, LQL, SPL, KQL, Lucene, or others). This query must be syntactically valid, semantically correct, and faithful to what the user actually asked.
4. Validation and execution
The best NLQ implementations don't stop at generation. They add a verification layer: syntax checking, dry-run execution, or a second-pass review of the generated query before it runs. This matters because LLMs can produce queries that look correct but reference fields that don't exist, apply the wrong aggregation, or misinterpret the scope of a filter. In security, where a wrong query can mean missing a threat or wasting an investigation, this validation step is critical.
Where NLQ is being adopted
NLQ has gained traction across multiple industries and use cases:
- Business intelligence: Platforms like Tableau, Power BI, ThoughtSpot, and Looker all offer NLQ interfaces that let business users query data warehouses without writing SQL. This is arguably the most mature NLQ market today.
- Databases and data platforms: Snowflake, BigQuery, and Databricks are building natural language layers into their query interfaces, bringing NLQ to the data engineering workflow.
- Observability: Log analysis and monitoring platforms like Splunk and Elastic have invested in NLQ to let operations teams explore logs and metrics without mastering platform-specific query languages.
- Security operations: NLQ is now entering the SOC, where analysts use natural language security queries to investigate alerts, hunt for threats, and explore network telemetry. Security is a particularly high-value use case because the data is complex, the stakes are high, and the talent pool is limited.
Key insight
"The global cybersecurity workforce gap stands at roughly 4.8 million professionals (ISC2, 2024). NLQ doesn't replace analysts. It multiplies the effectiveness of the analysts you have."
Why NLQ matters for security teams
Security teams generate and collect enormous volumes of network telemetry: Connection records, DNS logs, file transaction metadata, TLS handshake details, and protocol behaviors across dozens of application layers. The depth of this data is one of the industry's greatest strengths. It is also one of its most persistent operational challenges.
The problem is not a lack of data. It's the cost of accessing it. Every platform has its own query language, syntax, field-naming conventions, and approach to filtering and aggregation. Analysts who are fluent in one platform's language still lose time when they move to another. Even within a single platform, constructing the right query for a complex investigation requires knowledge of the schema that takes months to build.
Industry surveys consistently show that analysts spend more time constructing and debugging queries than on the actual investigative reasoning those queries are supposed to support. That's an expensive inversion. The analyst's value lies in their ability to interpret evidence and make decisions, not in remembering whether the field is called `id.orig_h` or `src_ip`.
NLQ flips that ratio. When an analyst can describe what they need in plain English and receive accurate results in seconds, the bottleneck shifts from data access to data interpretation. Investigations move faster. More of the team can contribute. And evidence that was previously locked behind schema complexity becomes accessible to every analyst in the SOC.
1. Query language fragmentation
Security teams typically operate across multiple platforms: a Security Information and Event Management (SIEM) system, an Endpoint Detection and Response (EDR) console, a network sensor, and a threat intelligence feed. Each has its own query language. Analysts context-switch between syntaxes throughout the day, which slows investigations and increases the chance of errors. NLQ provides one interface that works regardless of what's running underneath.
2. The expertise bottleneck
In most SOCs, a small number of senior analysts write the complex queries that drive investigations. When those analysts are unavailable or overwhelmed, investigations stall. NLQ distributes that capability across the team, enabling tier-1 and tier-2 analysts to ask sophisticated questions without waiting for escalation.
3. Slow investigation pivots
Investigations rarely involve a single query. Analysts need to pivot from one finding to the next: check the source host, then its DNS activity, then its outbound connections, then the certificates involved. In a traditional workflow, each pivot means constructing a new query from scratch. NLQ supports natural follow-up questions that maintain the context of the investigation, preserving momentum rather than breaking it.
4. Underutilized evidence
Organizations invest heavily in collecting network telemetry, but analysts often query only a fraction of it. When the schema is complex or poorly documented, entire log types go unexplored. NLQ makes the full evidence base discoverable by letting analysts ask for what they need without knowing where it lives in the schema.
5. Onboarding time
New analysts spend weeks or months learning platform-specific query languages before they can investigate independently. NLQ compresses that ramp-up. An analyst who understands network security concepts can start pulling evidence on their first day, even if they've never written a line of LQL or SPL.
Limitations of Natural Language Querying
NLQ is a powerful capability, but it is not without trade-offs. Organizations adopting NLQ should understand where the technology excels and where it requires caution.
Ambiguity
Natural language is inherently ambiguous. "Show me all hosts in the finance department that are connected to external IPs" could mean hosts that belong to the finance department, or hosts that are connected to finance-related external IPs. Humans resolve this kind of ambiguity through context. NLQ systems have to make a best guess, and sometimes they guess wrong. The best implementations handle this by showing the generated query, allowing analysts to verify the interpretation.
Accuracy on complex queries
On clean academic benchmarks, the best NLQ systems achieve over 90% execution accuracy for text-to-SQL translation. But on production-scale data with messy schemas, that number drops to the low-to-mid 80s (based on the BIRD benchmark, which tests against 95 real-world databases with dirty data). Human data engineers still outperform the best systems by roughly 10 percentage points. For simple filters and lookups, NLQ is highly reliable. For multi-table joins, nested aggregations, and queries that require external knowledge, accuracy drops, and analyst review becomes important.
Domain-specific terminology
General-purpose LLMs may not understand specialized security schemas out of the box. Terms like `id.resp_h`, `orig_bytes`, or `JA4` fingerprint fields are not part of standard training data. Effective security NLQ requires schema-aware models that understand the specific telemetry they're querying.
Trust and transparency
Analysts need to trust the queries NLQ generates. If the system is a black box that returns results without showing how it arrived at them, adoption will stall. Transparency (showing the generated query, explaining the interpretation) is not optional. It's a requirement for production use in security.
How NLQ fits into the agentic AI landscape
NLQ is part of a broader shift toward agentic AI in security operations. It helps to understand where NLQ sits on that spectrum:
NLQ as a translator
The analyst asks a question. The system generates a query. The analyst reviews the results and decides what to do next. This is NLQ in its simplest form, and it is already a significant productivity gain.
NLQ with automation
The system generates the query, executes it, and summarizes the results. The analyst still drives the investigation but spends less time on mechanical steps.
Agentic investigation
The system autonomously decides what to query next based on initial findings, chains multiple queries together, and surfaces conclusions. The analyst reviews and validates rather than directing every step.
NLQ is the foundational capability that makes each of these stages possible. An AI agent that can't translate investigative intent into accurate queries can't investigate at all. In this sense, NLQ is the interface layer for the future of security operations, whether that future is analyst-driven, agent-assisted, or fully autonomous.
How Corelight uses NLQ
Corelight's Natural Language Query capability is built into Investigator, Corelight's SaaS-based investigation and threat hunting interface that’s available within the company’s Open NDR Platform. Analysts type plain-English questions, and the system translates them into LogScale Query Language (LQL), executes the query against the customer's data, and returns results directly in the interface.
Built on the industry's richest network of evidence
NLQ is only as useful as the data it can access. Corelight generates network telemetry from Zeek and Suricata, as well as from proprietary machine learning and behavioral analytics. That telemetry spans dozens of fields per connection and hundreds of unique fields across 80+ specialized log types, including protocol details, DNS transactions, TLS certificates, file hashes, and more. The breadth of this evidence base means analysts can ask detailed, specific questions and get meaningful answers, not just surface-level filters.
Transparent by design
Every query NLQ generates is visible to the analyst. A collapsible analysis panel explains how the system interpreted the question: which logs it identified as relevant, what criteria it extracted, and how it constructed the query. Analysts can use this to learn the underlying query language over time, modify the generated query, or save it for reuse. The system shows its work, building trust and making NLQ a teaching and productivity tool.
Paired with investigation playbooks
Corelight also ships the Agent Builder Library, a set of structured investigation playbooks that outline what to look for given a specific alert type. NLQ and the Agent Builder Library are designed to work together. The playbook tells the analyst what evidence matters. NLQ lets them pull that evidence immediately, regardless of their familiarity with the schema. The combination means that knowing what to investigate and being able to investigate it are no longer separate skills.
From NLQ to Agentic Triage
NLQ is one part of Corelight's broader investment in making network evidence accessible. Alongside NLQ, Corelight's Agentic Triage delivers pre-investigated findings directly to a customer's SIEM, reducing the manual workload on SOC teams. Together, these capabilities represent a shift from tools that require expertise to tools that deliver outcomes.
Evidence depth: NLQ is bounded by the underlying data. Platforms that generate rich, structured, protocol-aware network telemetry will produce better results than those built on shallow flow data or sampled packet headers.
Transparency: The system must show the generated query and explain its interpretation. Black-box NLQ will not earn analyst trust.
Accuracy on real-world data: Ask vendors how their NLQ performs on production schemas with real field names and dirty data, not just curated demos.
Follow-up support: Investigations are multi-step. NLQ that treats each question in isolation forces the analyst to re-establish context with every query. Look for systems that maintain investigative continuity across a sequence of questions.
Schema awareness: General-purpose NLQ will struggle with specialized security telemetry. The system needs to understand the specific log types and field structures it's querying.
Corelight's NLQ is part of a broader platform that includes the Agent Builder Library for investigation playbooks and Agentic Triage for automated alert investigation. To see NLQ in action against live network data, reach out for a demo.
What is a natural language security query?
A natural language security query is a question about security data, such as “Show me anything unusual leaving the network after midnight,” that an analyst types in plain, conversational language instead of a specialized language like SQL, SPL, or KQL. The system interprets that question, generates a valid query against the underlying data, and returns results.
How accurate is natural language querying for security investigations?
Natural language querying is highly reliable for simple filters and lookups. For multi-table joins, nested aggregations, and queries that require external knowledge, accuracy drops, and analyst review becomes important. The best implementations handle this by showing the generated query, allowing analysts to verify the interpretation before acting on the results.
Which security platforms support natural language querying?
Natural language querying is becoming a standard capability across security platforms. Major SIEMs, including Splunk and Microsoft Sentinel, have introduced NLQ interfaces, and several NDR and XDR vendors are adding similar features as LLM-powered query translation matures.
Corelight's Natural Language Query is built into Investigator, its SaaS-based investigation and threat-hunting interface. Analysts type plain-English questions, and the system translates them into LogScale Query Language (LQL), executes the query, and returns results with every generated query visible for review. When evaluating NLQ across platforms, look for depth of the underlying evidence, transparency into how queries are generated, accuracy on real-world schemas, and support for multi-step investigations.
Book a demo
We’re proud to protect some of the most sensitive, mission-critical enterprises and government agencies in the world. Learn how Corelight’s Open NDR Platform can help your organization mitigate cybersecurity risk.