AI-assisted investigation that you can check
ThirdEYE investigates alerts automatically, but it does not treat a model as the first answer. Known patterns are resolved by built-in logic, models are used where they add something, and every step is logged.
The problem
Analysts drown in repeat alerts
Most alerts look like ones the team has already judged. Re-investigating them wastes time and, with an LLM, money.
Black-box verdicts are hard to trust
A risk score with no reasoning cannot be reviewed, challenged or defended in an incident review.
Model quotas and outages break triage
A free-tier limit or provider outage should degrade analysis, not stop it.
How ThirdEYE addresses it
Reuse what is already known
A new alert is first compared with correlated alerts and prior confirmed analyses. Near-identical alerts reuse the earlier conclusion, and a guard prevents fallback-origin verdicts from being reused.
Resolve with Security AI
The built-in engine matches the alert against rules and human-confirmed memory. By default this covers high and critical severity; Sigma-based resolution is optional.
Enrich and map
Indicators are extracted, enriched from threat-intelligence providers you configure, and mapped to MITRE ATT&CK techniques.
Ask a model only when it helps
If a verdict is still needed, the platform calls a configured provider (Groq, Gemini, Mistral, OpenAI or a local Ollama model). A daily token budget moves analysis to a lighter mode before a quota is exhausted.
Decide and log
Configurable thresholds choose between block, escalate, investigate and triage. The verdict, risk score and written justification are stored, and live response attempts are written to a hash-chained audit log.
Try the decision path
- Reuse an earlier conclusion
Compare with correlated alerts from the last 24 hours.
- Security AI: rules and confirmed memory
Match the rule catalog and analyses a person has confirmed.
- Enrich and map
Extract indicators, query threat intelligence, map to ATT&CK.
- Model analysis
Ask a configured provider for a verdict and risk score.
- Rule-based fallback
Used only if no model answered.
- Decision thresholds
Block, escalate, investigate or triage, with a logged justification.
Illustrative walkthrough of the documented decision order. Not live data. Which steps run in a real deployment depends on severity, configuration and the models you connect.
Key capabilities and their status
Status labels reflect what is in the product today.
Automatic alert investigation loop
New alerts are investigated automatically on a schedule: correlation reuse, rule match, enrichment, MITRE mapping, verdict and risk score.
Security AI: rule and memory resolution before any LLM call
A built-in engine resolves known patterns from rules and previously confirmed analyses first, so repeat alerts do not need a model call.
Note: By default only high and critical alerts go through rule matching. Sigma-based resolution is off by default.
Multi-provider LLM with failover, local models and built-in fallback
Groq, Gemini, Mistral, OpenAI and local Ollama are supported with an ordered fallback chain that ends in rule-based logic, so analysis does not hard-fail without a key.
Note: Needs the operator to supply provider keys or a local model. Fallback results are marked and never auto-close alerts.
LLM usage log, token budgets and per-tenant LLM policy
Every model call is logged with provider, tokens and outcome; a daily token budget degrades analysis to a lighter mode; policy can restrict a tenant to rules only, open-source models or paid providers.
Similar past incidents memory
Completed investigations are stored in a tenant-scoped semantic memory and searched for similar history.
Decision thresholds with logged justification
Configurable block, escalate and investigate thresholds decide what happens automatically and what waits for a person; each decision keeps its justification.
Masking of secrets and personal data before external LLM calls
Prompts are masked before they leave for an external provider. By default credentials and secrets are masked; wider personal-data masking is a configuration option (LLM_PII_MASK).
Note: Masking reduces exposure; it is not a guarantee. Local models keep data on the operator's infrastructure.
AI analyst chat grounded in platform data
A chat console for analysts that answers from platform data through the same LLM provider layer.
Note: Quality depends on the configured model.
Where it fits in your environment
ThirdEYE reads alerts from the sources you connect and writes its verdicts back into its own alert and case records. You choose where models run: cloud providers, a local Ollama model on your own hardware, or no model at all.
Policy can be set per tenant, for example rules only for one tenant and a paid provider for another.
Scope to know about
- If every model is unavailable the platform falls back to rule-based logic. Fallback results are marked and never close an alert automatically.
- High and critical alerts are never auto-closed.
- Answer quality depends on the model you configure. Local models are weaker than large cloud models.
- Masking reduces what leaves your network; it does not make an external provider risk-free.
See the investigation flow live.
Book a walkthrough with the team. We will show the platform end to end, tell you what is production-ready and what is not, and discuss how it would sit next to your existing SIEM.