-
Notifications
You must be signed in to change notification settings - Fork 5
FAQ
An autonomous DFIR agent on the SANS SIFT Workstation that thinks like a senior analyst — architecture-first, not prompt-first.
Detection And Response Team. See About the name for the full four-phase plan.
The "Agentic" prefix signals that this is an autonomous loop, not a wrapper around an LLM. The work unit is the agent's iteration, not the prompt.
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.
SANS FIND EVIL! 2026 explicitly asks for autonomous DFIR systems on the SIFT Workstation. The judging criteria align cleanly with the architectural claims this project is making.
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.
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.
~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.
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 dart-corr.
Yes. macOS dev mode is documented in Running on macOS. The SIFT Workstation is the production target because that's the hackathon's target environment, but the code does not depend on SIFT-specific paths.
Three reasons:
- The MCP ecosystem is Python-first
- DFIR tooling (Volatility, Plaso, etc.) is Python
- 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.
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.
It can, in the sense that any LLM can. The architectural guarantee is not that the agent never hallucinates. The guarantee is that:
- Every claim must cite an audit_id from a real MCP call
- The audit log is replayable and tamper-evident
-
dart-corrflags contradictions asUNRESOLVEDrather than hiding them
So a hallucinated finding either (a) lacks an audit_id and gets blocked at write time, or (b) has an audit_id, in which case a human reviewer can replay the call and confirm.
Doesn't matter. The system prompt is not a security boundary. The MCP surface is. See Architecture-first vs prompt-first.
- 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-DART addresses them by not being responsible for them.
Velociraptor is excellent for collection. Agentic-DART is for reasoning over collected evidence. They compose: a Velociraptor flow collects, then dart-agent --case reasons over the output.
KAPE is similar — collection / triage. Same compositional answer.
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.
The "just give the LLM bash" approach is exactly what dart-mcp is designed to not be. See Architecture-first vs prompt-first.
Yes. This is a personal/independent submission. The README's Author section makes that explicit.
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, sample-evidence generation, test scaffolding, and documentation drafting were AI-accelerated. Every commit is reviewed before it lands.
the full test suite passing on a fresh clone. the typed MCP function surface (native + SIFT adapters). broad MITRE ATT&CK enterprise tactic coverage — detect_dns_tunneling (added in v0.6.1) opens TA0011 (Command and Control) via Iodine/dnscat2 signature + Shannon-entropy + per-domain volume heuristics. TA0009 Collection remains the one tactic deferred to Phase 2. See docs/accuracy-report.md for the full mapping.
The bypass tests. They make the architectural claim mechanical, not rhetorical.
Three things:
- PCAP analysis for full TA0011 (Command and Control) coverage
- Sigma rule synthesis (Phase 2 work)
- A real-world dataset run against an Ali Hadi or NIST CFReDS image, with published metrics
Agentic-DART — autonomous DFIR agent · architecture-first, not prompt-first · MIT license · github.com/Juwon1405/agentic-dart
- The Memex bet ⭐ Why this design
- About the name
- Architecture-first vs prompt-first
- Architecture deep dive
- Threat model
- Glossary
- dart-mcp — typed surface (native + SIFT adapters)
- dart-agent — senior-analyst loop
- dart-corr — cross-artifact correlation
- dart-audit — SHA-256 chained log
- dart-playbook — senior-analyst sequencing rules (v3 default)
- MCP function catalog (native + SIFT adapters)
- Comparison with adjacent tools
- FAQ
- Operator guide — distro-agnostic
- Running on SIFT
- Live mode
- Accuracy report
-
Roadmap ⭐ Phase 1 ~95% complete
- Phase 1 — Agentic DFIR ⭐ dedicated page · SANS submission
-
Phase 2 — Detection engineering
- The self-learning loop ⭐ design note
- Phase 3 — Agentic SOC
- Phase 4 — Broader agentic security