Integrations Elastic
Integration · SIEM and big data
Turn the Elastic you already run into an autonomous SOC.
ApexAI connects natively to Elastic, read-only first. It queries your logs where they already are, checks every conclusion against the raw events, and shows where your detection rules can do better. No rip and replace, and no mass copy of your logs.
Status: Available Direct read-only access to Elastic logs and detection rules is running; rule tuning proposals wait for approval and nothing is ever written back into Elastic.
Your data stays in Elastic
Many security teams have invested years in their Elastic deployment: data streams, ingest pipelines, retention and detection rules tuned to their own environment. ApexAI builds on that work instead of asking you to move it. It asks Elastic precise questions when it needs evidence, rather than copying your logs into another store.
The connection is read-only by design. Write requests are refused inside ApexAI before they ever reach your cluster, even if the account you provide happens to have broader rights. Queries are bounded in time and rate, so investigations and hunts do not compete with your analysts or your ingest.
What ApexAI does with Elastic
Hunts in place
Hunting questions run directly against your indices and data streams, and the results are tied to the hosts, users and IP addresses they concern.
Investigates with raw evidence
When an alert or case needs context, ApexAI pulls the surrounding events from Elastic and cites them in the investigation brief, so every conclusion can be checked.
Knows your fields
ApexAI keeps an up-to-date picture of which fields exist in your data and what they mean, refreshed daily, so its queries match your real mapping instead of a generic template.
Reviews your detection rules
Rules that never fire, rules with no data behind them, broken or noisy rules, duplicates and exceptions that are too broad are flagged, together with gaps in MITRE ATT&CK coverage.
From rule finding to approved change
01
Find
ApexAI reads your rule set and recent alert history, read-only, and records a health finding for each rule.
02
Propose
For rules that can do better, it drafts a tuning proposal: grouping, a narrower exception, a different threshold or retiring a duplicate.
03
Backtest
Where history allows, each proposal is replayed against past data so you see the expected change in alert volume and the risk of missing a true positive.
04
Decide
A person approves or rejects each proposal with a reason. The decision is recorded and also teaches ApexAI what your team prefers.
05
Apply in your tool
Approved changes are applied by your team in Elastic. ApexAI does not write rules into your cluster.
Why teams trust it
- Read-only in code, independent of the rights on the account you grant.
- Bounded queries that protect cluster performance.
- Every finding and proposal comes with the evidence behind it and an audit trail of who decided what.
- Works per tenant: each Elastic deployment or space is bound to its own ApexAI tenant by a platform operator, and data never crosses tenants.
- Elastic can be reached directly, or read-only through the data-sharing interface of a managed SOC provider that operates it for you.
Questions
Does ApexAI copy all my Elastic logs?
No. ApexAI queries your data where it lives and keeps only what it needs as evidence for entities, cases and briefs. Your logs stay in Elastic under your retention.
Can ApexAI change my Elastic detection rules?
No. It proposes changes with evidence and a backtest where possible. A person approves each one, and your team applies it in Elastic.
What access does the integration need?
A read-only account is enough and recommended. ApexAI also refuses write calls in its own code, so a broader account still cannot be used to write.
See ApexAI on your own alerts.
A walkthrough with your team, in observe mode first: ApexAI scores and proposes, nothing acts on its own.