Inspiration
AI-powered attackers can move from initial access to major impact faster than a human responder can open their toolkit. Protocol SIFT shows how AI agents can operate on the SANS SIFT Workstation, but defensive AI has to be more than fast. It has to preserve evidence, avoid hallucinated findings, and explain exactly why it believes something.
SIFT Sentinel was built to close that gap: an autonomous DFIR agent that responds quickly while behaving like a careful senior analyst.
What It Does
SIFT Sentinel is an evidence-safe autonomous incident response agent and custom MCP server for Protocol SIFT.
Instead of giving an AI agent arbitrary shell access, SIFT Sentinel exposes typed forensic tools with strict boundaries. The agent can inventory evidence, analyze parsed memory and disk artifacts, generate findings, validate its own gaps, re-run missing checks, and produce a traceable report.
Every confirmed finding includes row-level evidence references and the exact tool call ID that produced the evidence. Every run also generates pre-run and post-run evidence manifests, proving that configured evidence artifacts were not modified.
How We Built It
The project is built as a dependency-light Python package with four main layers:
- A custom MCP stdio server exposing typed DFIR tools
- An evidence policy layer that denies writes into evidence paths
- A self-correcting triage loop with a hard max-iteration cap
- A benchmark and accuracy reporting system with structured JSONL logs
The demo case is synthetic and redistributable, but shaped like real SIFT outputs: memory processes, network connections, malfind output, Prefetch, Amcache, timeline data, Windows event logs, registry Run keys, and PCAP summary data.
Self-Correction Example
The demo intentionally includes a trap: C:\Users\Public\svchost.exe appears in Prefetch, which looks suspicious.
SIFT Sentinel initially records it as an inferred lead, then notices the finding is single-source. It requests Amcache and timeline corroboration. When those sources do not support the lead, the agent refutes it instead of reporting it as confirmed.
That is the core idea: speed with restraint.
Evidence Integrity
SIFT Sentinel does not rely on a prompt that says “do not modify evidence.” It enforces the boundary in code.
The system:
- Reads only from the configured evidence root
- Writes only to the configured output root
- Denies write attempts inside evidence paths
- Hashes evidence before and after the run
- Produces
evidence_integrity.json - Exposes a
spoliation-testcommand for judges
Challenges
The hardest part was designing autonomy that judges could trust. A fast hallucination is still a failure. The agent needed to distinguish confirmed findings from inferred leads, preserve a full audit trail, and show when it changed its mind.
What We Learned
Prompt guardrails help, but architectural guardrails matter more. A custom MCP server with typed tools is a better fit for DFIR than an open-ended shell because the unsafe actions are not exposed in the first place.
We also learned that self-correction should be visible. The execution log records validation gaps, new tool requests, and status changes from inferred to confirmed or refuted.
What's Next
Next steps include adding more native SIFT parsers, running against larger public datasets such as CFReDS and Honeynet challenges, and building a small UI for live analyst review.
Log in or sign up for Devpost to join the conversation.