SIFTMESH

Because finding evil shouldn't cost more than the breach.

Comment

Inspiration

The core inspiration for the project came from combining classic DFIR workflows with modern AI-powered parallel processes. While developing feedback system agents, I was a bit confused about the agent names and how they interconnected. Then I discovered an open-source skill called https://github.com/code-yeongyu/oh-my-openagent, which offers several agent workflows for Opencode. That’s where I found the basis for my flow, but I ended up redesigning the entire system architecture from scratch to build our feedback agent system for DFIR. The hackathon handed me a real insider-theft case (ROCBA): researcher suspected of stealing IP, a 23 GB disk image, a 19 GB memory capture, and 5 questions (what he could access, what was taken, where, how, when). I sat with two options and didn't like either. Working it by hand is slow and serial, and I end up babysitting one tool at a time.

  • Throwing it at an autonomous AI agent is fast, but I can't trust anything it says about the evidence, and in forensics a made-up or unverifiable claim is worse than saying nothing. The question I couldn't drop was this: can I get an agent's speed without losing chain of custody and "no hallucinations"? That became the whole design, in one rule I kept repeating to myself: the LLM proposes, the code decides.

What it does

SIFTMesh is the controller I built with CLI-first, evidence-safe controller for autonomous DFIR. I point it at evidence and an objective; it orchestrates different operations like it seals the evidence read-only with a SHA-256 manifest, plans the work, sends an agent to investigate, and runs a deterministic critic that checks every claim against real tool output before it is allowed to become a finding.

  • It drives 19 real forensic tools behind a typed allowlist with a thin layer of MCP wrapped for external agents use (Sleuth Kit, Volatility 3, Plaso, evtx, regipy, prefetch, the $MFT, registry, browser history, LNK/JumpLists, shellbags, Amcache/ShimCache, the USN journal).
  • Every finding points back to the exact tool call and the hash of the bytes it came from. I can run it fully autonomously or step it through human gates, and I can swap the executor (Claude, OpenCode, Gemini, Codex, or a no-keys deterministic floor) without touching the engine.
  • On the real ROCBA evidence: 634 findings, 0 unsupported, 0 contradictions. Stolen ADAMANTIUM research to a personal Google Drive + USB, SDelete + ~48K USN deletions as cleanup, on a 5.7M-event timeline.

How I built it

Python throughout: a Typer CLI, Pydantic schemas, and a deterministic state machine for the engine (plan, dispatch, critique, decide, report) with append-only JSONL ledgers for claims, contradictions, and the audit trail.

  • The agent only ever reaches tools through an MCP boundary whose allowlist is a single frozen set of 19 names, with no raw shell and no arbitrary code.
  • The parts I leaned on hardest are the evidence vault (hash and read-only seal at ingest), a write-jail so nothing escapes the run directory, the critic as the only thing allowed to promote a finding, and an ultra-worker state machine that turns verdicts into done, retry, escalate, or human-review. A lot of the work came from me using it and reacting.
  • Tools reachable only through an MCP allowlist (19 names). No raw shell, no arbitrary code.
  • I wanted real-time visibility, so I specked a default tagged log stream: [info], [agent], [tool_log], [alert], [output], [result], [tasks], with a separator per task and a running completion percentage. And after watching a live agent crawl through tasks one at a time, I asked for parallel dispatch to turn on automatically whenever a live agent is the executor, because running them serially was its own problem.

Challenges I ran into

There were lot of issues during development but following were some interesting ones.

  • Plaso crashed on the disk: partial acquisition, VSS header points ~81 GB into a 23 GB file. Therefore, had to Fix runPlaso over extracted artifacts (still 5.7M events).
  • The second challenge arises when the autonomous executor agent in --agent mode sends excessive requests to my Claude subscription, creating a bottleneck. For instance, with 429 tasks and up to 3 calls each, the total reaches 1,287 calls per evidence on the subscription tool, making the economics unfeasible. To address this, I devised a solution using a deterministic finite state machine engine, grouping similar task vectors for recurring LLM calls. This approach works efficiently with a human-in-the-loop, supported by a critic and flagging system. -Token efficiency was a core value of SIFTMESH, but storage efficiency also became crucial. My virtual machine for the Sift workstation had only about 200 GB, with just 90 GB free, and the raw Standard Forensics Case with the ROCBA case was occupying most of the space, leaving little room for real DFIR evidence. Instead of treating this as an issue, I turned it into a feature by implementing a space-check mechanism and applying a divide-and-conquer approach for large evidence artifacts, processing one at a time using parallel or sequential methods according to user preference.
  • The development of the Ultra-worker Finite State Machine was critical, as the system and architecture I designed had to seamlessly fit into the overall flow. This required significant time to fine-tune, even with agents like myself ensuring the code was implemented correctly, and proper errors were fixed to maximize its efficiency.

Accomplishments that I'm proud of

Thinking about the whole project and hackathon participation is a proud moment for me, as I always wanted to join the SANS hackathon (not kidding) but often missed out due to various issues, problems, or time management challenges. So, the positive points after the cry above are...

  • Not all operations require costly LLM calls; in my tests, parallel runs matched sequential runs exactly, and a recorded golden run reproduced the entire pipeline without any API keys. This greatly improves token economy, as AI excels at rapid analysis, though it’s important to balance speed with accuracy.
  • I’m proud and confident that this is a genuine, autonomous orchestration engine running on real evidence, tackling all five case questions with success: 634 findings, all supported, noncontradictory, and each one traceable to both a tool call and a source hash. (It even saved my Claude subscription limits).
  • Also a critic agent that earned its place by catching a live agent producing garbage and refusing to promote any of it. Failures I left visible instead of hiding, like the corrupt log and the partial-acquisition timeline.

What I learned

  • What I Loved most is diving into learning this time, especially keeping the scope clear and prioritizing project implementation to fit the dev timeline.
  • Learned the hard way to create tasks, sub-tasks, and Epics, manage large projects, ship features with solid file organization, and pivot at dead ends.
  • The System Stayed in the loop not just blindly trusting AI outputs, correcting agents during development, and keeping hybrid systems balanced without one overshadowing the other.
  • Biggest takeaway: evidence safety must be in the architecture prompts aren’t controls, code is. Guardrails belong in the gate the agent’s output passes through.
  • I also learned to treat honest gaps as a feature or future features.

What's next for SIFTMESH

  • https://a2a-protocol.org/latest/ interop under the same policy layer, so a remote agent is governed like a local one.
  • https://agentclientprotocol.com/get-started/introductionreimplementation will allow OpenCode, Gemini and Codex etc. to access the typed tools in the same way Claude does now. It’s a promising framework, and so far, I’ve only implemented its basic features. In the next development cycle, I plan to go through the core implementation of this protocol to understand how it works, which will indirectly help me grasp the compatibility layer of this framework and reimplement its core features in our project as well.
  • Rework on the TUI,It gets the job done, but I’m not a fan. I’d prefer the UI and onboarding process to be more like Hermes Agent’s (shout out to the Hermes dev team and collaborators), with a simpler, yet impactful design like theirs.
  • Sigma/pySigma for broader detection coverage with also support for the deeper parsers I deferred (Outlook OST, OneDrive ODL) once I confirm a clean Linux parse. SRUM for per-app network bytes.
  • Also the unglamorous one I felt firsthand, tighter low-disk handling, so a full investigation fit on a stock workstation without me watching the free-space meter.
  • Maybe Create a Meta Harness for Multi Agent Orchestration support and to add support for Claude, Codex, Opencode and more. using Existing framework while keeping the core system and methodology intact

Built With

Share this project:

Updates

posted an update —

Do give it a like! if you loved the project and approach due to time restrictions on video submissions, I couldn’t explain much this time, but I’ll soon upload a clearer voice-over with a high-quality tutorial and project overview. Thanks, everyone!

Log in or sign up for Devpost to join the conversation.