FAQ

FAQ

Project basics

What is Agentic-DFIR, in one sentence?

An autonomous DFIR agent on the SANS SIFT Workstation that thinks like a senior analyst — architecture-first, not prompt-first.

What does the name mean?

It is literal: agentic — an autonomous, iterative, auditable loop rather than a wrapper around an LLM — plus DFIR, digital forensics and incident response. See About the name for the four-phase plan.

Is this a fork of something?

No. Original work, MIT licensed. The MCP protocol is from Anthropic, and Claude is the LLM used in live mode, but the architecture and code are independent.

Is this a personal project?

Yes. This is a personal, independent project; the README's Author section makes that explicit.

Was AI used in the development?

Yes, openly. The "Development approach" section of the README discloses Claude as a coding collaborator. Architectural decisions, threat coverage taxonomy, MITRE mapping, and final review are human-driven; implementation, synthetic evidence generation, test scaffolding, and documentation drafting were AI-accelerated. Every commit is reviewed before it lands.

---

Technical

Is the MCP surface really fixed in size?

Yes. tests/test_mcp_surface.py asserts the exact positive set. If a 73rd appears or any of the canonical set disappears, the test fails on the next CI run.

Does Agentic-DFIR work without the Claude API?

Yes. The deterministic demo path (bash examples/demo-run.sh) runs end-to-end with no API key. Live mode (real Claude API + MCP stdio) is available but optional. See Live mode.

How big is the audit log?

~500-700 bytes per MCP call (one JSONL line per call). A typical 25-iteration run produces an audit log of around 12-18 KB. The chain is verified on every run; tampered logs are detected.

Why DuckDB and not SQLite?

DuckDB handles columnar joins on millions of rows orders of magnitude faster than SQLite, which matters for MFT-scale timeline correlation. SQLite is fine for the audit log; DuckDB is right for dfir-corr.

Will it run on other Linux distributions outside SIFT?

Yes. The host is Linux only — the SANS SIFT Workstation (Ubuntu 22.04) is the primary target, and other distributions (RHEL / Rocky / AlmaLinux 8+, Fedora) work via their package manager. macOS and Windows are not supported as the host (the Plaso / libyal toolchain doesn't build cleanly on them). This is about where the agent runs — macOS and Windows evidence are fully supported as analysis targets (dedicated artifact parsers; case-03 is itself a macOS investigation).

Why Python and not Rust / Go?

Three reasons:

1. The MCP ecosystem is Python-first
2. DFIR tooling (Volatility, Plaso, etc.) is Python
3. The bottleneck is LLM API latency, not Python execution time

If a specific function needed to be rewritten in a faster language (e.g. an MFT parser doing 10M rows), it would still be exposed via the same MCP schema. The MCP surface is what the agent sees; the implementation is opaque.

---

Safety & guarantees

Can the agent damage evidence?

No. By construction. The MCP surface has no write functions, and the evidence directory is mounted read-only at the OS level. See Architecture-first vs prompt-first.

Can the agent make stuff up?

It can, in the sense that any LLM can. The architectural guarantee is not that the agent never hallucinates. The guarantee is that:

1. Every finding carries the audit_ids of the MCP calls that produced it
2. The audit log is replayable and tamper-evident
3. dfir-corr flags contradictions as UNRESOLVED rather than hiding them

So a hallucinated finding either (a) carries no audit_id, which is visible in the report, or (b) has an audit_id, in which case a human reviewer can trace it back to the logged call (python3 -m dfir_audit trace <audit.jsonl> <finding_id>), replay it, and confirm.

What if the LLM ignores the system prompt?

Doesn't matter. The system prompt is not a security boundary. The MCP surface is. See Architecture-first vs prompt-first.

What's NOT in scope for safety?

• Confidentiality of the evidence (the agent reads everything you mount)
• Network egress prevention (run in an air-gapped environment if you care)
• Resource exhaustion (use container limits)

These are deployment concerns. Agentic-DFIR addresses them by not being responsible for them.

---

Comparison with adjacent tools

How is this different from Velociraptor?

Velociraptor is excellent for collection. Agentic-DFIR is for reasoning over collected evidence. They compose: a Velociraptor flow collects, then dfir-agent --case reasons over the output.

How is this different from KAPE?

KAPE is similar — collection / triage. Same compositional answer.

How is this different from a fine-tuned LLM?

This project doesn't fine-tune anything. The LLM is generic; the value comes from the architecture (MCP surface + correlation engine + audit chain + playbook). A fine-tuned LLM could replace the generic one, but it would still need this scaffolding to be safe and auditable.

How is this different from "just give the LLM bash"?

The "just give the LLM bash" approach is exactly what dfir-mcp is designed to not be. See Architecture-first vs prompt-first.

---

← Back to Home