SIFT Kernel

Forensic Evidence Operating System — An MCP server that makes evidence spoliation architecturally impossible, hallucinations structurally unregisterable, and forensic methodology computationally enforced.

Built for the FIND EVIL! Hackathon by SANS Institute.

Judges: Every turn-in requirement maps to a specific file. Nothing is hidden.

SIFT Kernel sits between any AI agent (Claude, GPT, Llama, etc.) and the SANS SIFT Workstation's 200+ forensic tools. It provides:

• 129 forensic operations across 14 categories + 21 reporting tools, exposed via the Model Context Protocol (MCP)
• Category dispatcher architecture — agent sees 32 tools (14 forensic categories + 18 kernel), each category groups related operations
• Capability-based security — no shell access exists, read-only evidence mounts
• Hash-chained evidence ledger — every tool call cryptographically recorded
• Confidence scoring — findings require evidence links (hallucinations structurally blocked)
• FARE reasoning engine — Dempster-Shafer evidence fusion (PCR5), Active Inference (EFE) tool selection, Rough-set confidence tiers, convergence detection, cognitive bias monitoring
• Auto-correlation — deterministic attack chain detection via temporal proximity + MITRE kill-chain sequencing + shared entity linking
• Self-correction architecture — coverage gap detection, FARE conflict interrupts (K>0.3), entropy-plateau falsification injection, evidence provenance verification
• Forensic knowledge enrichment — every tool response includes expert caveats, corroboration suggestions, and interpretation guidance at the response level (not system prompt)
• Determinism tracking — measures how closely the agent follows server methodology recommendations (0.0-1.0 score)

┌─────────────────────────────────────────────────────────────┐
│  ANY MCP CLIENT (Claude Code, Cursor, Zed, etc.)            │
└────────────────────────────┬────────────────────────────────┘
                             │ MCP Protocol (stdio)
┌────────────────────────────▼────────────────────────────────┐
│  SIFT KERNEL                                                 │
│  ┌────────────────────────────────────────────────────────┐ │
│  │ Category Dispatchers (14 forensic + 18 kernel = 32)   │ │
│  ├────────────────────────────────────────────────────────┤ │
│  │ Meta-Cognitive Toolkit (self-correction engine)         │ │
│  ├────────────────────────────────────────────────────────┤ │
│  │ Evidence Ledger (hash-chained, append-only)            │ │
│  ├────────────────────────────────────────────────────────┤ │
│  │ Output Intelligence (anomaly detection)                │ │
│  ├────────────────────────────────────────────────────────┤ │
│  │ Capability Kernel (DAG prerequisites, ro mounts)       │ │
│  ├────────────────────────────────────────────────────────┤ │
│  │ Tool Executors (binary allowlist, shell:false)         │ │
│  └────────────────────────────────────────────────────────┘ │
└────────────────────────────┬────────────────────────────────┘
                             │ subprocess (shell:false)
┌────────────────────────────▼────────────────────────────────┐
│  SIFT WORKSTATION (200+ forensic binaries)                   │
└─────────────────────────────────────────────────────────────┘

• Node.js 18+
• SIFT Workstation (for actual forensic tool execution)

git clone https://github.com/Sathvik-1007/sift-kernel.git
cd sift-kernel
npm install

# As MCP server (stdio transport — for Claude Code, OpenCode, etc.)
npx tsx src/index.ts --output ./investigation

# With evidence pre-loaded (optional — can also load dynamically via mount_evidence tool)
npx tsx src/index.ts --evidence /path/to/image.E01 --output ./investigation

# HTTP transport with bearer auth (for remote/multi-client access)
npx tsx src/index.ts --transport http --port 3000 --token YOUR_SECRET

# Fresh investigation (wipes prior state)
npx tsx src/index.ts --fresh --output ./investigation

Add to your MCP client configuration:

{
  "mcpServers": {
    "sift-kernel": {
      "command": "npx",
      "args": ["tsx", "/path/to/sift-kernel/src/index.ts", "--output", "/tmp/sift-output", "--fresh"],
      "env": {}
    }
  }
}

while (not done):
    result = call("suggest_next_action")
    call(result.tool_name, result.params)

Any model that can parse JSON and call a function produces a valid, methodology-correct, auditable forensic investigation. The intelligence is in the server.

At session start, the agent sees 32 tools (14 category dispatchers + 18 kernel). Each category groups related operations:

filesystem(operation="list_directory", path="/Users")
registry(operation="get_persistence_keys")
event_logs(operation="parse_event_log", path="/Windows/System32/winevt/Logs/Security.evtx")

The capability kernel still blocks out-of-order calls — methodology is enforced regardless of what the agent tries.

The server doesn't just run tools — it reasons about the investigation state using published mathematical frameworks:

Every tool response includes the FARE state: entropy, dominant hypothesis, active signals, conflict coefficient, and bias warnings.

suggest_next_action returns a full forensic cognitive frame — not just "run this tool":

{
  "tool": "registry",
  "operation": "get_persistence_keys",
  "directive": {
    "whatEvilLooksLike": "Entries pointing to temp dirs, random names, encoded PowerShell",
    "whatNormalLooksLike": "Chrome Update, Windows Defender, Office updaters",
    "hypothesisTested": "Has the attacker established registry-based persistence?",
    "confirmationCriteria": "Run key value points to a path containing suspicious executables",
    "ifConfirmed": "Register T1547.001 finding, advance to scheduled tasks",
    "ifAbsent": "Persistence is NOT via registry — check scheduled tasks"
  },
  "efe_score": 0.34,
  "information_gain": "EFE=0.34 (risk=0.20, ambiguity=0.14)"
}

The methodology engine drives the investigation — any MCP-capable LLM follows the structured directives without needing forensic domain knowledge.

Findings cannot appear in the final report without evidence links. Hallucinations are structurally impossible.

Every tool call produces a hash-chained ledger entry:

• Tool name + parameters
• Output hash (SHA-256)
• Previous entry hash (tamper detection)
• Capabilities held at time of execution
• Duration

Run verify_chain to cryptographically validate the entire audit trail.

This project implements the first computational realization of several theoretical frameworks for DFIR:

Formally verified via property-based tests (npm test):

• P1: No shell execution capability exists (no code path)
• P2: No finding without evidence links enters the report
• P3: Capability graph is a valid DAG (no cycles)
• P4: Hash chain valid for any operation sequence
• P5: Every tool call produces exactly one ledger entry
• P6: All file access contained within evidence mount prefix

# Type check
npx tsc --noEmit

# Run tests
npx vitest run

# Watch mode
npx vitest

| Package | Purpose | |---------|---------|
| @modelcontextprotocol/sdk | MCP server (stdio + HTTP/SSE transport) | | zod | Runtime validation + branded types | | better-sqlite3 | Evidence ledger (WAL mode, hash-chained) | | neverthrow | Type-safe Result<T, E> — no exceptions in domain layer | | nanoid | Unique IDs for ledger entries + findings | | exponential-backoff | Retry transient I/O failures with jitter | | vitest + fast-check | Testing + property-based formal verification |

MIT