SENTINEL

SENTINEL turns raw security logs into an attack-path graph and incident report where each claim cites a log line, with Grok narrating, providing recommendations, leaving no room for made-up evidence.

Comment

Inspiration

Security teams don't lose because they lack alerts. They lose the hours it takes to prove what happened. When a breach lands, someone has to go from thousands of log lines to a story they can defend in front of their manager, their legal team, and sometimes a regulator. AI tools can summarize quickly, but they also invent things, and in an incident, a confident wrong answer is worse than no answer. We wanted to give those hours back without giving up on the truth.

What it does

SENTINEL is a web app that investigates security incidents from log files. It's built for security analysts and IT teams who have a pile of logs after something went wrong and need to work out, quickly and provably, what happened and what to do next.

You upload a log file (JSONL, JSON, or CSV), and SENTINEL gives you back a complete investigation:

  • Findings: Seven detection rules flag the events that matter: repeated failed logins followed by a success, logins from outside the network after hours, accounts added to admin groups, newly installed services, logons that hop from one machine to another, access to sensitive files like finance or payroll, and large data transfers leaving the network.
  • Attack-path graph: SENTINEL connects those findings into a visual map of how the attacker moved, from the first login to the last machine they touched. Every arrow in the graph is backed by specific log events.
  • Evidence panel: Click any finding, machine, or arrow, and the app shows the exact log lines that support it. Nothing on screen exists without a log line behind it.
  • Incident report: A ledger that separates what the logs prove (green) from what is only a reasonable guess (yellow), an overall risk rating, and clear defensive next steps: block an IP address, disable an account, isolate a machine, review group changes.
  • Grok summary: When an xAI API key is set, Grok rewrites the summary into readable plain English. It can't change the findings, graph, or actions, and any draft that cites an event not in the file is thrown out.

How we built it

  • Backend: Python + FastAPI. A rule-based detection engine, a graph builder that only draws edges it can cite, and a report generator. Pydantic models carry event IDs from parsing through to the final report.
  • Grok Bot: orchestrates the five-step investigation. Grok (xAI API) is only allowed to rewrite the summary. A draft is rejected if it cites an event ID that isn't in the file or includes attack procedure, and the local summary is kept instead.
  • Frontend: React + TypeScript + Vite. Findings, the attack graph, the evidence panel, and the report are linked, so selecting one moves the others to the same events.
  • Shipping: A multi-stage Docker build serves the UI and API on one port. Pytest covers the investigation pipeline, including the benign control.

Cursor: AI built it, we managed it

SENTINEL was built by AI. Cursor's agent wrote the code: the FastAPI backend, the detection rules, the graph builder, the React dashboard, the demo logs, and the tests. Our job was to manage it the way a product lead manages an engineering team.

  • We set the direction: the problem (analysts lose hours proving what happened), the product (an investigator where every claim cites a log line), and the demo story.
  • We set the guardrails: a Cursor project rule (.cursor/rules/sentinel.mdc) that applies to every backend and frontend file. Every finding, graph edge, and report statement must cite a parsed event ID. No exploit code, payloads, scanners, or attack tooling. Recommendations stay containment and recovery: block an address, disable an account, isolate a host, review a group.
  • We reviewed and shipped: the agent delivered its work as a pull request, and we reviewed it, tested the demo, and merged it.
  • We told the story: the pitch, the demo script, and this write-up.

Grok Bot: how SENTINEL runs an investigation

We started from xAI's quickstart to get the Grok API working, then made Grok Bot the engine of the app. Grok Bot owns the investigation workflow. Every case runs through five fixed steps, and the UI shows each one as it completes:

  1. Ingest: parse the uploaded JSONL, JSON, or CSV log.
  2. Detect: apply seven rules and record which events each finding cites.
  3. Correlate: build the attack-path graph, where every edge cites at least one event.
  4. Reason: call Grok through the xAI API to rewrite the incident summary in plain English.
  5. Report: produce the evidence ledger, risk rating, and defensive actions.

Grok is the narrator, never the source of evidence. We send it the rule-based summary plus the list of cited event IDs. The system prompt tells it to use only those facts, add no new event IDs, and describe no commands, malware, or attack steps. We run it at low temperature (0.2) for consistency.

Every draft goes through an evidence check before we accept it:

  • Every event ID it mentions must be one the rules actually cited.
  • It must cite at least one real event.
  • It must not contain attack-procedure language, such as tool names or "step-by-step" instructions.

If a draft fails, the call errors, or no API key is set, Grok Bot keeps the local summary and says so in the Reason step. The ledger, graph, and actions come from the rules either way. Cursor built SENTINEL, Grok narrates every case, and the rules keep it defensible.

Challenges we ran into

  • Keeping the AI honest: Letting an LLM write the whole report was tempting. We limited it to narration and built a check that throws out any draft with citations we can't verify.
  • Not crying wolf: A backup job that reads a lot of data or one failed login from outside shouldn't look like an attack. Most rules only fire for hosts and accounts already on the path, so normal activity stays off the path.
  • Knowing where the logs stop: The hardest part of the report was what not to say. Separating observed facts from hypotheses forced us to be explicit about every gap.

Accomplishments that we're proud of

  • Zero uncited claims: every conclusion traces back to a specific log line.
  • A demo that tells a full intrusion story, from brute force to exfiltration, in about a minute.
  • A control dataset that shows the tool staying quiet on a normal day.
  • A clear defensive boundary: SENTINEL explains logs. It doesn't scan, exploit, or attack anything.

What we learned

In security tooling, AI is most valuable as a narrator over deterministic evidence, not as the source of truth. Constraining what the model may say made the output more trustworthy, not less useful. We also learned that a tool that admits "the logs don't show this" earns more trust than one that always has an answer.

What's next for SENTINEL

  • More sources: Windows event logs, cloud audit trails, EDR exports
  • More detection rules, plus a way for teams to write their own
  • Exporting the cited case straight into incident-response tickets

Built With

Share this project:

Updates

Submission history