Natural Language Investigation
Ask a question. Get evidence, not a query prompt.
Type 'Show me all API calls from alice's account to S3 in the 4 hours before the finding' and the search engine translates it to a structured query, runs it against the normalized event store, and returns a ranked set of results with entity context attached.
How the query engine works
Natural language queries are processed by an embedding and intent classification layer that identifies: the time window, the target entities, the event types, and any field-level filters. The classified intent maps to a structured query against the normalized event store — the same queries a power user would write by hand, generated automatically.
The engine understands entity graph shortcuts: "alice's manager," "the team that owns the prod-payments service," "all accounts created in the last 30 days" resolve to entity graph queries that expand to concrete entity IDs before hitting the event store.
"Which service accounts called sts:AssumeRole in the last 24 hours?"
Resolves to: event.type=sts.AssumeRole + entity.type=service_account + time_range=24h
"Show me all logins from the IP 198.51.100.42"
Resolves to: event.source_ip=198.51.100.42 + event.type=authentication
"What did the attacker do after gaining access to the prod-api server?"
Anchors to the attack chain timeline and returns events post-initial-access on that entity
More than a log search
Entity-aware results
Results are grouped and annotated by entity. A search for 'failed auth attempts' returns results bucketed by user — with each user's baseline failure rate, total attempts, and blast radius score displayed alongside the raw events.
- Results ranked by entity risk score, not just event count
- Baseline comparison shown inline with results
- Jump from result to entity profile in one click
Entity-aware results
Time-anchored investigation
Relative time expressions — 'before the finding,' 'during the attack window,' 'in the 30 minutes after the login' — anchor to the active case timeline. You never have to calculate epoch timestamps or toggle between the case view and the search page.
- Case timeline anchors available in all queries
- Graphical time range selector for refinement
- Results update in near-real-time as new events arrive
Time-anchored investigation
Query persistence and sharing
Saved searches can be shared with teammates, attached to a case, or promoted to a recurring threat hunt that runs on a schedule. Promoted hunts run automatically and create findings if the query returns results above a configurable threshold.
- Save and share queries within the case context
- Promote search to recurring hunt with one click
- Hunt results create findings through the standard detection pipeline
Query persistence and sharing
Natural Language Investigation — FAQ
Does the search engine understand field names from specific sources?
Yes. The intent classifier knows common field aliases across sources: 'user,' 'principal,' 'actor,' and 'account' all resolve to the normalized entity.user_id field. Source-specific field names like 'recipientAccountId' (AWS) are also understood.
What if the search engine misinterprets my query?
The generated structured query is displayed below the search bar. You can see exactly what was sent to the event store, correct it manually if needed, and save the corrected version.
Is there a query language for power users?
Yes. The search bar accepts natural language by default, but prefixing a query with '#' switches to a structured query language with field filters, boolean operators, and aggregations — the same language used internally by the natural language layer.
Can search results be used as detection rule input?
Yes. A search result set can be exported to the detection rule editor, with the query pre-populated as the rule filter. This is the recommended workflow for creating detection rules from threat hunting findings.
How does natural-language search handle multi-hop entity graph queries?
The intent classifier detects when a question requires graph traversal — 'show me everything the compromised account touched' — and generates a graph query rather than a flat event filter. Results include entity relationship paths alongside the matching events.
What is the latency for a natural-language search against 90 days of data?
Hot-tier queries (0–30 days) typically return in under 5 seconds for most query patterns. Warm-tier queries (31–90 days) may take 10–30 seconds for large data volumes. The search UI streams results as they arrive so analysts see partial results immediately.
Can search queries be saved and shared across the team?
Yes. Saved searches are bookmarkable and shareable via link. Teams can maintain a library of investigation pivots — common threat hunting queries, compliance evidence searches, and forensic timelines — accessible to any analyst in the tenant.
Does natural-language search work across all connected data sources simultaneously?
Yes. A single query runs across all normalised event sources simultaneously. Events from CloudTrail, Okta, CrowdStrike, and GitHub all appear in the same result set, correlated by entity ID and timestamp. Source filtering is available as an optional refinement.
How does the search engine handle ambiguous entity references like common user names?
When a search term could match multiple entities (e.g., 'admin' matching multiple accounts), the results include all matching entities with their source identifiers. A disambiguation sidebar lets analysts narrow to the specific entity they intend.
Investigate in plain English
Natural language search is included with every ManySignal deployment. No additional license, no separate tool.