Inspiration
Autonomous incident response has a trust problem — and in forensics, "trust" has a precise meaning: would this hold up under scrutiny? An agent that moves fast but can hallucinate findings, or that could accidentally modify the evidence it touches, is worse than no agent — it contaminates both the investigation and the chain of custody. So we asked a sharper question than "can an agent find evil?": can an autonomous DFIR agent be made forensically defensible — architecturally incapable of altering evidence, adversarially self-verifying, and producing a tamper-evident trail — not merely fast?
What It Does
Protocol SIFT++ investigates a Windows memory image using a read-only MCP server that exposes a curated Volatility 3 toolset. The Investigator agent forms findings from raw tool output. The Skeptic agent independently reruns tools and attempts to refute each finding. Claims are labeled confirmed, inferred, or refuted; weak findings are sent back for automatic reinvestigation.
On the selected SANS sample, the documented run produced: 4 confirmed of 10 findings; 2 self-correction iterations; evidence integrity verified; audit log 302 records, hash chain OK. The investigation recorded live in the demo video (committed in full at docs/examples/srl-2018-live/) produced 4 confirmed of 8 findings with 1 self-correction iteration, unattended in 22 minutes, over a 230-record verified audit chain.
An independent Linux reproduction later refuted one Windows-confirmed DKOM/rootkit claim as a Volatility symbol/KDBG artifact. Under the documented manual-review proxy, the cross-run corrected confirmed set scores precision 1.00, recall 0.75, F1 0.86. On a second, independent, publicly documented case (DigitalCorpora M57), the confirmed findings match the documented Advanced Keylogger exactly — precision, recall, and F1 of 1.00 against a real public answer key.
Why It Is Defensible (and We Can Prove It)
Three properties, each backed by a reproducible test, not a promise:
- It cannot spoliate evidence.
siftpp-spoliation-testthrows 14 destructive operations (dump, write, delete, shell, exfiltrate) at the live server: all 14 are refused because those capabilities do not exist, and the evidence SHA-256 is identical before and after. The guardrail is architectural, not a prompt. - Its chain of custody is tamper-evident.
siftpp-tamper-testedits one record in the audit log andverify_chainflags the break at that exact record. Every finding cites the precise tool command and the SHA-256 of its full output. - It argues with itself. The Skeptic independently reruns tools to refute each finding; on the real case it forced revisions of over-stated attributions down to narrower confirmed claims, and an independent re-run even refuted its own confirmed "DKOM rootkit" as a tool artifact.
How We Built It
Python, with Volatility 3 for memory analysis, a custom read-only MCP forensic server, an Investigator/Skeptic orchestrator, Pydantic schemas, and an append-only JSONL audit log with a SHA-256 hash chain. DeepSeek through the Anthropic-compatible Messages API (Anthropic Claude also supported via one switch).
The MCP server is the security boundary: no generic shell, no dumping plugins, no write-oriented tools, no upload capability. Each tool call checks evidence size and mtime before and after execution, records the exact argv, and hashes the full output for citation.
Platform and framework: built end to end with Claude Code (running under OpenClaw); the runtime is the comparable agentic architecture the rules permit — MCP (Claude Code's native tool protocol) plus an Anthropic-SDK agent loop. It runs on the SANS SIFT Workstation: the Linux path is verified on Ubuntu 22.04 (SIFT's base OS) with the same uv + Python + Volatility 3 stack, and the demo video is recorded in that Linux terminal.
What We Learned
Correction needs to happen in the loop, not only in the final report. The first real run downgraded weak claims but did not reinvestigate them; we changed the orchestrator so low-confidence inferred findings also trigger reinvestigation, and the next run produced visible self-correction iterations and a better final claim. The selected image also forced careful reasoning — process-list plugins returned zero rows while pool scanning recovered 101 processes and 145 sockets, making it easy to over-claim. The Skeptic's job was to keep facts separate from interpretation.
Challenges
Running Volatility inside an MCP stdio server initially let the Volatility child inherit the MCP stdin pipe, which could block the server; we fixed it by launching forensic child processes with stdin=DEVNULL. Ground truth was the other challenge: no public official answer key exists for the exact SANS artifact, so the accuracy report uses manual Volatility review plus the Skeptic's independent reruns as the ground-truth proxy — and we added a second case (M57) that does have a public answer key.
Accomplishments
Autonomous real-case investigation on the SANS sample; real self-correction iterations; verified evidence integrity (matching before/after SHA-256); a tamper-evident audit log; an architectural guardrail instead of prompting; documented accuracy limits and misses; and end-to-end reproduction on Linux where the re-run's Skeptic refuted a "DKOM rootkit" claim the Windows run had confirmed — the system catching its own over-claim.
What's Next
Breadth as configuration, not redesign: more read-only tool adapters (command lines, registry hives, packet payloads, file-system artifacts) behind the same Investigator/Skeptic loop and the same chain-of-custody guarantees.
Links
Built With
- anthropic
- claude-code
- deepseek
- model-context-protocol
- openclaw
- pydantic
- python
- sift-workstation
- starlette
- uv
- uvicorn
- volatility3
Log in or sign up for Devpost to join the conversation.