Who builds this

Who builds this, and why it is built this way.

This page is for anyone weighing the harness for casework. It names the design decisions that matter when a run has to be defended in review, and the person who makes them.

In short
Field
Digital forensics and security research
In security since
Twenty-five years
Founded
ADEO Cyber Security, BlueCortex AI
Current research
LLM security and AI red teaming
The calls

The four decisions that shape the rest of the harness.

Each one costs something in convenience. Each one is here because the alternative fails the moment a run has to be explained to someone who was not in the room.

Evidence is read-only at the kernel

The evidence is copied or attached, hashed before the first agent starts, checked again at the end, and held read-only by the operating system in every pane. A tool that relies on agents choosing not to write to the evidence has no answer when the question is put properly.

The record is written from outside the sandbox

A collector process the agents cannot reach is the only writer. Each line names the hash of the line before it, and the head of the chain is anchored where no agent can write. A log the examined party can edit carries no weight in a report.

The report says what your host could not enforce

The kickoff measures the machine once and writes the answer into the record. A run on a host that lacks a guard still runs, and the report names the gap. A gap the record names can be answered in review, which is why the measurement is written down rather than assumed.

The finish line is fixed before the work starts

The goal document carries a definition of done and checks the agents are refused permission to edit. A goal without a finish line does not start at all. An examination whose scope moves while it runs produces findings nobody can rely on afterwards.

The maintainer

Halil Öztürkci

Twenty-five years in information security. He founded two companies in the field, ADEO Cyber Security and BlueCortex AI, and has trained the analysts who staff security operations centres. His work now is in artificial intelligence, the security of AI systems, and what AI changes about security work. He builds ventures in that space and advises organisations on it.

DFIR Swarm comes out of that work: a way to put many examiners on one body of evidence without losing the account of who touched what. The guards in it are the controls a forensic examination needs in order to be defensible, moved from procedure into the kernel.

Labs that want someone alongside the tool can have that too. Support, training and consulting are arranged directly, and the work is done remotely.

How the project is heldDFIR Swarm is maintained independently and published under the GNU AGPL v3 or later, which cannot be revoked for the versions already released. The Community edition is free and nothing a run's defensibility depends on is held back. Commercial licensing, Pro and Enterprise deployments are arranged by contact, and the terms are scoped with you.

Bring it a case.

The Community edition is free, runs on your own machine and needs no account with us. If your lab needs a scoped deployment, terms, or a commercial licence, that conversation starts here.