ScreamSIEM

ScreamSIEM is an SSH-native incident-response platform for small Linux fleets. It continuously detects suspicious changes, like unexpected network listeners, then uses GPT-5.6 to explain the evidence.

Comment

Inspiration

Small Linux fleets are difficult to monitor well. Operators often know that something is wrong, a new process or an unexpected port or a strange service, but still have to assemble evidence manually and remember the right commands to investigate it. Other SIEM tools often require manually coding in plumbing.

I wanted to build something practical for self-hosted infrastructure: a security monitor that could connect over the SSH access that sysadmins already have that would explain what it found in plain English, and recommend safe next steps without handing an AI unrestricted shell access.

What it does

ScreamSIEM connects to Linux servers, virtual machines and containers over SSH. Each host exposes a constrained, read-only MCP bridge for process, socket, service, journal, log, and system metrics. An "Approve Exact Action" button exists that allows actions to be run as suggested by the AI (GPT-5.6) but it needs explicit permissions set up and should not be used without understanding the possible consequences. It is not compulsory to allow this, and not every company will have a security posture that allows this button.

The system learns a baseline of normal host behaviour and uses deterministic detectors to identify changes such as unexpected listening ports. GPT-5.6 then investigates the evidence, explains what may be happening, cites the relevant events, describes uncertainty, and proposes manual or approval-gated actions(Approval-gated actions need explicit permissions to work and are disabled by default).

The dashboard provides live findings, evidence, confidence scores, host health, SSE updates, sound alerts, copy-pasteable commands, and human approval before any mutating action is attempted. It can use either an OpenAI API key or headless Codex ChatGPT authentication, so remote servers do not need a browser or locally stored API key.

## How I built it

I started by using ChatGPT with GPT-5.6 Sol to create the specification, implementation tickets, security boundaries, and architecture diagrams. Codex then helped implement the system with GPT-5.6 Luna High using a test-driven workflow.

The project is built with FastAPI, SQLite, Pydantic, AsyncSSH, MCP, systemd, and a Cloudflare Worker that serves the installation scripts and enrolment flow. I continuously tested both deterministic fallback behaviour and a real two-host deployment: one controller and one monitored Linux server.

Challenges I ran into

A complete SIEM is an enormous project, so the biggest challenge was choosing a useful, demonstrable MVP instead of trying to recreate Splunk or Wazuh.

Security boundaries were equally important. We did not want to give the model arbitrary shell access or allow it to execute its own recommendations. Investigation is limited to bounded evidence and read-only tools; mutation requires an exact human approval and is checked again on the host. Access to the SIEM dashboard is handled with a SSH tunnel, which while secure in production, made exposing a demo for the judges a little more difficult. A cloudflare worker handles this.

I also had to solve headless ChatGPT authentication, strict structured output schemas, SSH host enrollment, live event streaming, and a dashboard that remains usable while telemetry is constantly arriving.

Accomplishments I am proud of

I completed an end-to-end working MVP in four days.

The system can be installed on a controller through a public curl command, enrol remote hosts, detect a deliberately created HTTP listener, investigate it with GPT-5.6, explain the risk, suggest read-only verification commands, and present approval-gated remediation.

It works on real machines rather than only in a mock demo.

What I learned

I learned that deterministic detection and AI explanation complement each other. The detector should establish what changed but GPT-5.6 Sol is able to convert the output into readable English.

I also learned that security products need strong interaction design. Evidence, uncertainty, permissions, approval state, and action results must all be visible. Structured output validation, least privilege, and safe fallbacks are core product features.

What's next for ScreamSIEM

Next I want to add a more complete least-privilege remediation model, additional Linux detectors, better incident history and search, role based access, stronger audit trails, production hardening, and integrations with existing alerting systems(SMS via Twilio or AWS SES, Pagerduty for after hours)

The long-term goal is to make high quality incident response accessible to teams that have Linux infrastructure but do not have the budget or operational complexity of a full enterprise SOC or CERT.

Share this project:

Updates

Submission history