Lantern: my hackathon SIEM assistant, rebuilt and extended

Lantern started as my hackathon project and is now being rebuilt and extended. At a security hackathon, two teammates and I built a monitoring platform on Wazuh and open-source scanners, and it placed second of 33 teams. My part was an MCP server that gives an AI assistant 29 investigation tools over the SIEM: 28 read-only, and one osquery tool that runs only vetted queries. The first sections below describe that version; the last two cover the rebuild and what comes next.

The hackathon version: investigation tools

The first version had nine: the triage queue, endpoint investigation, alert investigation, fleet status, threat hunts, posture checks, correlation, osquery and fleet search. It grew to 29 from there. Most of an analyst's time on an alert goes into this kind of pivoting: which endpoint, which user, what else that host did around the same time. An assistant can do it fast. Each tool queries the SIEM manager API and the OpenSearch indexer directly, aggregates on the server side, and returns structured context with citations for the model to reason over. There is no retrieval index in between, so one alert comes back as a timeline.

Keeping the assistant read-only

An assistant holding SIEM credentials is a new principal with reach into some of the most sensitive data a company has, and it spends all day reading text an attacker can write, because log lines are attacker-controlled. So the controls sit in front of the model, in the credentials and the tool layer.

• Allowlisted queries. osquery runs only from a hardcoded list of 91 vetted, SELECT-only queries. There is no arbitrary SQL against the fleet.
• Read-only credentials, proven. The credentials are scoped to specific API and index roles, and a write returns 403. That test is how read-only is proven.
• Secret truncation. A result can confirm that a secret exists without exposing it.
• Audit and rate limits. Every call is logged with credentials stripped, and calls are rate-limited.

Two-stage triage

A deterministic heuristic pass resolves the obvious false positives at no model cost. Only the ambiguous high-severity alerts go to a model, which bounds both the cost and how much data leaves the SIEM. An incident narrative generator posts a draft to the analysts' chat, and by design it cannot trigger any remediation.

What the model can and cannot reach

The model is a reader, never an actor. Fed a hostile log line, the most it can do is read what it was already allowed to read. That property comes from the credentials and the allowlist, which I can test, rather than from instructions in a prompt, which I can't.

The risk I watch for is on the human side. An analyst who stops looking where the assistant already looked inherits its blind spot. A SOC that deploys a copilot like this should measure what its analysts now miss as well as what they now catch.

The rebuild

The hackathon code stays private, so Lantern is a fresh rewrite on synthetic, replayable data. The first version targets Wazuh 4.x. It reads alerts from the indexer, groups alerts that share an identity or an asset into one incident, and writes a factual summary of each incident, end to end and offline. Everything Wazuh-specific sits in one adapter, so a change of Wazuh version is a mapping swap, not a rewrite. The read-only MCP server is the next piece to ship on it.

The next iteration

The next version moves to Wazuh 5 and reads its common schema from the indexer. On the same read-only tools, agents will check an alert against related evidence, follow it across the identities and assets it touches, and draft the incident narrative. A case console gives the analyst one place to triage, open a ticket or mark a false positive.