Inspiration
Security Operations Centers are drowning. The average SOC analyst handles over 1,000 alerts per day, and studies consistently show that more than half of those alerts are never investigated — not because they are unimportant, but because there simply isn't time. An analyst who receives a Splunk alert today has to manually open the SIEM, run multiple queries across different data sources, correlate the findings, assess severity, write up a summary, decide what actions to take, and document everything. That process takes 20-40 minutes per alert on a good day. Meanwhile attackers move in minutes.
The problem is not that analysts are bad at their jobs — it is that the tools force them to do mechanical, repetitive investigation work instead of applying their judgment where it actually matters. We wanted to build something that handles the investigation and summarisation automatically, so the analyst's first interaction with an alert is already a complete picture: what happened, why it is suspicious, how severe it is, and what to do about it.
What It Does
SentraX is an autonomous SOC co-pilot that sits between Splunk and the analyst. When Splunk fires an alert, SentraX automatically runs a full investigation, scores the severity, generates an AI summary with precautions, proposes ranked response actions, and presents everything in a clean dashboard — all before the analyst even opens the ticket.
Concretely, when an alert arrives:
The system identifies the entity involved — whether it is a user account, an IP address, or a host machine. It then fires a battery of targeted Splunk queries automatically: login history, geolocation anomalies, off-hours activity, privilege escalation events, process creation with suspicious command lines, network connections, DNS lookups, and threat intelligence lookups. It scores the severity on a 0–10 scale using a deterministic rule engine. It searches memory for similar past incidents to provide historical context. It sends all of this structured data to an LLM which writes a plain-English summary explaining what happened, why it is suspicious, and exactly what the analyst should do. It then generates a ranked list of response actions — isolate the host, disable the account, block the IP, force a password reset — each with a one-sentence rationale.
The analyst sees all of this on a dashboard with four tabs: the AI summary, the playbook with approve/reject controls, a conversational chat interface for asking follow-up questions about the incident, and a raw data view showing all the Splunk query results. They can submit their disposition — true positive, false positive, or escalate — and that feedback is written back to Splunk to power a calibration dashboard that tracks accuracy over time.
There is also a proactive threat hunt feature where an analyst can investigate any entity on demand, without needing an alert to trigger it first. This surfaces near-miss anomalies — entities that have suspicious behaviour but scored just below the alert threshold.
How We Built It
The backend is a FastAPI application that receives Splunk webhook alerts and kicks off a LangGraph state machine. LangGraph manages the 9-node pipeline as a directed graph, passing state between nodes sequentially. Each node is a Python async function with a clearly scoped responsibility.
Splunk integration is handled through a custom async REST API client built on httpx. All SPL queries are pre-written parameterised Python templates — the LLM never writes SPL. There are separate template modules for user, IP, host, and DNS entity types, each querying both the BOTSv3 static dataset and a live windows_logs index simultaneously using coalesce() to handle field name differences between data sources.
For live endpoint telemetry we set up Sysmon on the Windows machine with a custom event filter configuration, and a Splunk Universal Forwarder to ship events to Splunk in near real-time. This gives visibility into process creation (EventCode 1 and 4688), network connections (EventCode 3), and DNS queries from all applications including browsers (EventCode 22).
The LLM layer uses Groq's API with llama-3.1-8b-instant. We deliberately constrained the LLM to three specific text generation tasks and gave it detailed, structured prompts. The model is called with the actual Splunk data, the severity score, and the breakdown of contributing factors so its output is grounded in real evidence rather than hallucination.
The frontend is React with Vite, using Server-Sent Events for live pipeline progress streaming and Recharts for the calibration dashboard visualisations.
How AI Is Used
This is important to explain clearly because we made a deliberate architectural choice: the LLM only generates text, never makes decisions.
Every routing decision, every severity score, every SPL query selection, every playbook action ranking — all of that is deterministic Python code. The LLM is called in exactly four places:
Node 5 — Draft Summary. The LLM receives the raw Splunk query results, the severity score, the breakdown of contributing factors, and any similar past incidents. It writes a 4-6 sentence summary that explains what activity was detected, why it is suspicious, what the severity level means, and what specific precautions the analyst should take. The prompt explicitly requires it to address all four of these points.
Node 7 — Critique and Revise. The LLM receives the draft summary and the results of counter-evidence queries — VPN exception logs, benign history records, baseline comparisons. It either revises the summary downward if the counter-evidence explains the activity, or keeps the original assessment and states why the counter-evidence does not apply. It always ends with a specific "Recommended next step" sentence.
Node 8 — Playbook Rationale. The LLM receives the ranked list of response actions (ranked deterministically by severity score, entity type, and historical disposition data) and writes one sentence of rationale for each action explaining why it is appropriate given the specific severity level.
Node 10 — Conversational Drill-down. When an analyst asks a question about an incident in the chat interface, the system maps the question to a pre-written SPL template using regex pattern matching, runs the query, and sends the results to the LLM to phrase as a conversational answer.
This design means the system is fully auditable. Every severity score shows its exact component breakdown. Every recommended action has a traceable reason. Nothing is a black box.
Challenges We Ran Into
Port conflict between Splunk and FastAPI. Splunk's web UI was running on port 8000, which is also FastAPI's default. The frontend was silently hitting Splunk's web UI instead of the API, causing "Failed to fetch" errors with no obvious explanation.
LangGraph node naming collision. LangGraph raises a ValueError if a node name matches a state key name. We had a node called "draft_summary" and a state field also called draft_summary. Renamed the node to "draft_summary_node" to resolve it.
Browser DNS bypass. Modern browsers (Edge, Chrome) use their own DNS resolver and bypass the Windows DNS Client API entirely. The Microsoft-Windows-DNS-Client/Operational event log only captures DNS queries from desktop apps, not browsers. The solution was Sysmon EventCode 22, which captures DNS queries at the kernel driver level and catches everything including browsers.
Splunk KVStore corruption. The embedded MongoDB in Splunk crashed with a WiredTiger checksum error, blocking token authentication entirely. Fixed by stopping Splunk, deleting the corrupt KVStore data directory, and letting Splunk rebuild it on restart.
Small LLM quality. gemma:2b was too small to reliably generate numbered lists for playbook rationale — it would write one rationale and stop. Switching to llama-3.1-8b-instant via Groq solved this completely.
SPL field name differences. The BOTSv3 dataset and live Windows Event Logs use different field names for the same data (e.g. user vs TargetUserName vs SubjectUserName). Rewrote all SPL templates to use coalesce() across all possible field names.
Accomplishments We're Proud Of
The live telemetry pipeline working end to end is the biggest one. Sysmon capturing a PowerShell execution or a browser visiting a suspicious domain, that event flowing to Splunk within 30 seconds, a Splunk alert firing to SentraX, the 9-node pipeline running, and a complete AI-analysed incident appearing in the dashboard — that full chain working automatically is genuinely satisfying.
The AI summary quality surprised us. With the right structured prompting and Groq's speed, the revised summary reads like something a real analyst would write: specific, grounded in the actual data, clearly explaining the risk level, and ending with a concrete action. Not boilerplate.
The calibration dashboard closes the feedback loop in a way most SOC tools do not. Most AI security tools fire and forget. SentraX tracks whether its severity scores are actually predicting real threats over time, without retraining any model. That is the responsible AI story.
What We Learned
Constraining the LLM makes it more useful, not less. Every time we tried to give the LLM more autonomy — letting it suggest what queries to run, letting it explain its own scoring — the outputs became less reliable and harder to debug. Reducing it to a text formatter with structured inputs and explicit output requirements made it both faster and more accurate.
Endpoint telemetry is the missing piece for most hobbyist SIEM setups. Everyone has Splunk running with some dataset, but without a forwarder and Sysmon the data is static and stale. Getting live Windows events flowing made the threat hunt feature actually useful instead of a demo with canned data.
Deterministic scoring is more trustworthy than LLM scoring for security decisions. An analyst can click the severity badge and see exactly why the score is 8.0 — "+3 off-hours activity, +2 privilege escalation events, +3 investigation volume." They can disagree with that and their feedback trains the calibration. That transparency builds trust in a way a neural confidence score never could.
What's Next for SentraX
Multi-entity correlation. Currently each alert investigates a single entity. Real attacks involve lateral movement — the same attacker touches multiple users, hosts, and IPs in sequence. The next version would correlate alerts across entities by time window and shared indicators to detect kill chains rather than isolated events.
Automated playbook execution. Right now the playbook is advisory — the analyst approves and then manually takes the action. Integrating with Active Directory, firewall APIs, and ticketing systems (ServiceNow, Jira) would let approved actions execute automatically while keeping the human approval gate.
Adaptive scoring. The rule-based scoring engine is static. Using the growing sentinel_feedback dataset to weight scoring factors based on what has historically been a true positive for this specific environment would make the system smarter over time without retraining a neural model.
Broader data source support. Currently querying Windows Event Logs and Sysmon. Adding cloud trail logs (AWS CloudTrail, Azure AD sign-in logs), endpoint telemetry from other operating systems, and network flow data would make it useful beyond a single Windows endpoint.
Local LLM option for compliance environments. The architecture already supports swapping Groq for a local Ollama model with a one-line config change. Packaging a pre-configured Ollama setup for air-gapped deployments would make SentraX viable for healthcare, government, and financial environments where data cannot leave the network.
Log in or sign up for Devpost to join the conversation.