SentinelIQ.
Security log analytics that turns multi-format logs into a queryable, anomaly-scored timeline, with a natural-language layer that turns plain-English questions into search filters.
The Problem
Security analysts spend much of their day three things deep: pivoting between SIEM dashboards that don't talk to each other, hand-writing query DSLs against schemas they've memorized but resent, and trying to remember whether this spike of failed logins is "Tuesday morning normal" or "actually an incident."
SentinelIQ is built around a different default: ingest everything, embed it, score it three ways, and let the analyst ask questions in English. Logs are useless if they're locked behind a query language; alerts are noise if the model thinks a holiday weekend is anomalous; and a SIEM that can't tell you "show me failed SSH attempts from new IPs in the last hour" without you knowing the schema is just a $50K log archive.
Multi-Format Log Ingestion
Real security teams aren't running one log source — they're running a syslog collector for Linux fleet, Windows Event collectors for the AD domain, a CEF feed off a network appliance, and a CSV dump from whatever EDR they bought last year. SentinelIQ parses all of them, plus generic JSON, into a single schema:
- Syslog (RFC 5424) — structured priority, facility, severity, hostname, app-name, msgid, timestamp, message body.
- Windows Event Logs (JSON export) — channel, event-id, provider, level, computer, user-sid, payload data.
- CEF (Common Event Format) — vendor, product, signature-id, name, severity, custom extensions. The lingua franca for network appliances.
- JSON and CSV — generic parsers with flexible field detection, so exports from other tools, firewall CSVs included, drop in without code changes.
Each event lands in SQLite for the timeline view and in ChromaDB as an embedding, so the anomaly engine and the query layer reason over the same store.
Three Anomaly Scoring Methods
One scoring method = one blind spot. SentinelIQ runs three methods over the recent window and keeps the highest score for each event, along with which method flagged it and why.
Embedding distance
Each event's embedding is compared against the centroid of the stored events. Events that sit unusually far from it get flagged, even when the text looks routine.
Frequency Z-score
Per-source event counts in ten-minute buckets, scored against that source's own baseline. A brute-force burst isn't anomalous because the words are scary; it's anomalous because the rate sits far above this host's normal.
Severity escalation
Compares the share of high and critical events in the recent window against the earlier one. When that rate more than doubles, the newer high-severity events are flagged as an escalation.
Every flag explains itself. Each anomaly carries the method that raised it and a one-line reason, so an analyst can see why an event was flagged before deciding whether it matters.
Natural Language Query Engine
An analyst types a question like "show failed SSH logins from the last hour". A local model served by Ollama turns it into structured search parameters (a text pattern, a time range, a limit), the query runs against the event store, and semantic search over the embeddings fills in when few events match.
Everything runs locally, so logs never leave the machine. If the model's output doesn't parse, a keyword fallback still builds a usable query instead of failing.
[03:14:23] WARN Anomaly score 0.87 — src 10.0.0.45 (vector_distance)
[03:14:24] CRIT Threat score 0.90 — sshd "invalid user" + "failed password" from 10.0.0.45
[03:14:25] INFO Embedding vectors indexed: 24,891
[03:14:26] WARN Frequency spike from 192.168.1.33 — 10-min bucket far above baseline
[03:14:27] NLQ "show failed logins last 24h" → 312 results
[03:14:28] ALERT Severity escalation — high/critical share more than doubled
[03:14:29] INFO ChromaDB k-NN: 12 nearest events (cos-dist 0.21–0.34)
[03:14:30] NLQ "summarize last 5 alerts" → AI-gen incident report
Architecture
[ Log sources ] syslog winevt CEF JSON / CSV │ │ │ │ └────────────┴───────────┼────────────┘ ▼ Format-agnostic parser layer ▼ Normalized event { ts, src, type, msg, ... } ▼ ┌──────────────────────┼──────────────────────┐ ▼ ▼ ▼ SQLite (timeline) ChromaDB (vectors) Anomaly M01 / M02 / M03 │ │ │ └──────────────────────┼──────────────────────┘ ▼ FastAPI (query + WebSocket stream) ▼ ┌──────────────────────┼──────────────────────┐ ▼ ▼ ▼ Ollama LLM React Dashboard Incident NL → search filters timeline / severity summarizer
Why It's a Useful Signal
I built SentinelIQ for one reason: in my QA & Cybersecurity Engineer role at NextgenID I'd written enough vulnerability assessments and FedRAMP / NIST 800-53 documentation to know what's missing in the day-to-day analyst workflow — and what won't get sold to teams that already have Splunk.
- Local-first. Logs never leave the network. Ollama, ChromaDB and SQLite all run on a single box, which suits air-gapped and regulated networks.
- Format-pluralism, not format-religion. No "convert your logs to our schema first" — meet the team where the logs already are.
- Three methods, each explained. Every flagged event says which method raised it and why, instead of a bare score.
- NL query as the front door, not a feature. The dashboard exists, but the primary interaction is "ask in English, get the matching events back." That's the workflow change that matters.
Papi AI →
AI dating wingman on the App Store: React Native app, FastAPI backend, hosted Groq models behind fallback chains.