Inspiration

The inspiration was the tension between machine-speed investigation and forensic integrity.

AI agents are increasingly capable of coordinating complex security workflows. That creates pressure to use autonomous systems on the defensive side too. But digital forensics has stricter rules than ordinary automation. Evidence should be handled read-only. Generated outputs should be traceable. A model should not get arbitrary shell access to a forensic workstation. A final report should not claim theft, exfiltration, malware attribution, memory findings, or compromise unless the submitted artifacts actually support those claims.

I wanted to build something that uses autonomy without surrendering the discipline of DFIR. The design goal became: let the model orchestrate, but force every claim through deterministic evidence checks.

That is why I chose the name Elenchos. It refers to refutation and cross-examination. In this project, that means every finding must survive the evidence pipeline, and unsupported conclusions are downgraded instead of polished into a narrative.

What it does

Elenchos provides a bounded autonomous triage loop around SIFT-compatible forensic workflows.

An analyst can start with a high-level prompt such as:

Triage the ROCBA case with Elenchos and tell me what happened.

From there, the agent can reason about the next operational step, but it must operate through a constrained interface. The workflow prepares a case, runs deterministic triage, summarizes generated outputs, validates the report, and finalizes the run state.

Elenchos generates structured outputs such as:

  • findings.json
  • case_questions.json
  • report.md
  • validation_summary.json
  • audit.jsonl
  • decision_trace.json
  • model_rationale.jsonl
  • policy_decisions.jsonl
  • orchestration_finalization.json

The important part is the separation of roles. model_rationale.jsonl records operational reasoning. policy_decisions.jsonl records allowed or rejected actions. audit.jsonl records deterministic execution. findings.json and case_questions.json carry status-labeled forensic conclusions. The analyst can trace from the report back to structured findings, evidence references, normalized events, and audit records.

How I built it

I built Elenchos as a local-first Python workflow with a deterministic forensic core and a bounded OpenClaw/MCP-callable interface.

The model-facing side exposes safe, typed actions. The forensic side handles case preparation, parser workflow execution, event normalization, finding generation, validation, and reporting. The policy gate sits between orchestration and execution.

The architecture is:

Analyst prompt
→ OpenClaw / MCP-callable interface
→ model rationale
→ policy gate
→ bounded Elenchos adapter
→ deterministic forensic core
→ SIFT-compatible parser workflows
→ normalized events
→ findings and case questions
→ validation
→ report, audit logs, and finalization

The demonstrated artifact scope is intentionally focused on Windows disk triage. Elenchos processes supported artifacts such as MFT-derived filesystem observations, Registry Run/RunOnce locations, user activity registry artifacts, and Amcache records with transaction sidecars where available.

I chose depth over breadth. Instead of wrapping many tools shallowly, I focused on a smaller artifact scope with stronger evidence boundaries, explicit statuses, and durable traceability.

Challenges I ran into

The hardest challenge was making autonomy visible without making it unsafe.

If the system only looked like a Python script, the autonomous orchestration would be easy to miss. If the model had too much freedom, it could become unsafe for a forensic setting. I had to design the workflow so the model’s reasoning was visible, but its authority was limited.

Another challenge was claim discipline. A model tends to be helpful. If asked about theft or exfiltration, it may try to answer even when the evidence scope is local disk artifacts only. Elenchos handles that by validating generated wording against artifact scope and preserving needs_review or not_assessed where necessary.

The final challenge was keeping the submission honest. Elenchos does not claim memory forensics, packet analysis, browser history, cloud telemetry, or full enterprise incident response. It is a bounded Windows disk triage workflow. That limit is deliberate.

Accomplishments that I'm proud of

I am proud that Elenchos demonstrates disciplined autonomy:

  • model-led orchestration without treating model text as evidence
  • deterministic evidence processing
  • policy-gated actions
  • read-only evidence handling
  • output fencing
  • status-labeled findings
  • validation against unsupported claims
  • durable logs for traceability
  • explicit preservation of analyst review

The system is conservative by design. It does not try to win by making the boldest claim. It tries to make the safest evidence-backed claim.

What I learned

The main lesson is that autonomous DFIR should be designed around constraints, not just capability.

A useful forensic agent does not need to sound certain. It needs to preserve the difference between confirmed evidence, inference, review candidates, rejected claims, and questions that were not assessed.

I also learned that auditability is not a reporting feature added at the end. It has to be part of the architecture. The model rationale, policy decisions, validation summaries, findings, case questions, and audit logs all need to be generated as first-class artifacts.

What's next for Elenchos

Next work would expand artifact coverage while preserving the same evidence model. Good future directions include browser artifacts, network telemetry, cloud sync logs, memory integration, richer trace maps, and repeatable benchmark packs.

The priority would remain the same: expand capability without weakening evidence integrity.

Built With

Share this project:

Updates