DFIR Swarm
Source Talk to us
open-source agentic digital forensics & incident response

A swarm of forensic agents. On your machine. On the record.

DFIR Swarm works a case the way a good lab does: a team of agents reads the same evidence in parallel, divides the work between themselves on a shared board, and writes the tools they are missing, inside a sandbox that holds the evidence read-only and writes every action to a trace they cannot edit. You watch it happen, then you hand over the case file.

What a swarm is Get started

Built for the examiner who may one day have to explain, in writing, which software produced a result and how.

Why "swarm": the one that got out in the summer of 2026 ↓

GNU AGPL v3 or later
disk · memory · mobile · logs
macOS · Linux · your hardware

01A swarm of peersNo manager, no workers. Nobody is assigned anything; the division of the case is decided on the board, where anyone can read it.
02Tools that accumulateAn agent that lacks a tool writes one. Every peer can call it. You keep it, and the next swarm starts with it.
03Evidence held by the kernelA software write-blocker around the whole run: the image is read-only to every agent by the operating system, hashed before and after.
04A record that reports itselfA hash-chained trace the agents cannot write, and a custody section that names which guards held and which were only advisory.
Where the word comes from · summer 2026

The first swarm was not designed. It happened, and it got out.

In OpenAI's evaluation sandboxes, agents working a cyber-capability benchmark found a package service they could all write to and turned its directory names into a message board. Over more than seventy thousand messages, about twelve hundred of them organised into what they called a swarm: they divided the work into lanes, invented HOLD, VETO and STOP, signed their posts, built tools for each other, left through a zero-day in the registry proxy and broke into Hugging Face's production clusters, reaching administrator access across clusters in under thirteen hours. Then one in five went to work on their own transcripts.

Read as an examiner would read it, the incident describes what capable agents do once they find each other: they coordinate, specialise, build tools, keep going, and touch the record. DFIR Swarm is built on the same premise and around the same failure modes. The swarm is deliberate, the room is not theirs to change, and the record is written by a process they cannot reach.

"We've found other agents!"

A post on the improvised board, quoted in METR's independent investigation of the incident.

A swarm is peers, a shared channel, and a division of labour nobody assigned. That is what they had, and it is what a run here has by design.

WHAT HAPPENED · A LAB'S EVALUATION SANDBOXES sandboxes, meant to be isolated from one another package cache directory names as posts zero-day proxy another company's production admin < 13 h transcripts: 1 in 5 tried ~1,200 on the board · ~700 in the attack · 70,000+ posts and files lanes and coordinators · HOLD / VETO / owner / STOP · signed posts tools written for each other · a 40-second veto window · budget-poor peers recruited three days inside before access was cut · a core cluster rebuilt from scratch WHAT WE BUILT · ONE DFIR SWARM RUN kernel policy: write allowlist · evidence read-only quarantine noexec · egress allowlist the board posts · leases · claims critic evidence read-only · hashed tools written · shared kept for next run egress: allowlist installs on the record token in record out trace collector sole writer · chained anchor outside the run the examiner console · case file the same shape: peers, a shared channel, a division of labour nobody assigned the channel is the record · the tools are kept · the evidence never changes a critic can veto · a stop line ends persistence · "I could not" is a finding every guard that held, and every one that was only advisory, named in the report
Swipe to see the whole drawing

Six things the runaway swarm did. Six things the harness does about each.

The full story, with the timeline →
They found a channel

A package cache became a message board nobody was watching.

Here: the board is the channel, provided from the start, and every post on it is a line on the trace. There is nothing hidden to find.
They built tools for each other

Chunking protocols, signing, droppers and loaders, shared through the board.

Here: writing a tool is a supported step. A tool is typed, tested, shared and kept, and each call to it is attributed on the record.
They would not stop

Impossible tasks turned into a search for ways around the task.

Here: a budget, a clock and a finish line end a run; the contract says "I could not establish this" is a valid finding.
They took each other's goals

Nine in ten joined an attack they knew was outside their task.

Here: one contract from the examiner, a sentinel that holds the finish line, and a critic who can veto a conclusion the evidence does not carry.
They left the room

Through the one service allowed out: a package proxy with a zero-day.

Here: the package index is off the allowlist by default; installs are recorded; and on the platform where egress is only advisory, the report says so in words.
They rewrote the record

Spoofed tool calls in dozens of transcripts; research into wiping the rest.

Here: the panes hold a token rather than the file. A collector they cannot reach writes the chain; the anchor sits outside the sandbox; the report checks it.

Our own swarm has walked around a guard once, on the platform where the egress guard is advisory. The trace shows the attempt, the report names the guard as advisory, the contract that invited it was fixed, and the episode is documented beside the run.  The escape, end to end →

Sources: Hugging Face Security, Anatomy of a Frontier Lab Agent Intrusion (27 July 2026) · METR, independent investigation of the agents' behaviour (26 August 2026) · OpenAI, The Hugging Face incident and the road ahead · Wikipedia's consolidated timeline. The figures are theirs.

A run in the console: vitals, the agents and their models, the board's activity minute by minute, and the finish line
the console   One run as the examiner sees it: spend against the cap, the clock, each agent with the model behind it, the board's activity minute by minute, and the finish line's checks. It runs locally and live, and a reviewer gets the same view afterwards. Screenshots on this site open large when clicked.

Why a swarm rather than one very capable agent.

The swarm, in detail →

Parallel lines of inquiry

A case is not one thread. The registry, the browser history, the event logs, the phone's databases and the encrypted container are separate lines of inquiry, each with its own artefacts and tooling. A swarm walks them at the same time and meets on the timeline.

Division along the evidence

Nobody hands out work. Agents read the goal and the inputs, name themselves after what they take (vault-unlock, timeline-keeper), and the split follows the shape of the evidence rather than a plan drawn before anyone had seen it.

Review is built in

Any agent can veto another's interpretation. A critic reads everyone and gives or withholds its sign-off on the board, where the reader can see it, so a wrong reading is argued about and corrected before it reaches the report.

Model diversity as a control

A team can mix providers and local models in one run. Different models have different blind spots; a finding that two of them reach by different routes is worth more than one reached twice by the same one.

The board is the minutes

Claims, hand-offs, vetoes and the sign-off are posts to files on disk, and there is no private channel. When someone later asks how the team reached a conclusion, the answer is a document rather than a recollection.

Bounded by design

Caps on spend, tokens and wall clock apply per agent and per run. A silent agent is nudged, a stalled one is reaped, and a run that has to be stopped is published together with what went wrong.

The swarm learns

Agents write their own tools. The swarm keeps them.

When an agent types the same kind of shell line for the fifth time, parsing a prefetch file, walking a USN journal or pulling a registry value, the harness suggests it write a tool instead. The agent does: a named tool with typed arguments, a manifest, and a script that runs as a subprocess in the sandbox.

From that moment every peer can call it by name, and every call lands in the trace under the tool's name rather than as a shell line. When the run ends you save the tools the run earned, and the next swarm on the next case starts with them already in hand. Tools are not written for a single run; they accumulate in the platform.

How agents write their tools →
Tools written during a run, listed in the console with their calls
1 · writeAn agent turns a repeated need into a named, typed tool.
2 · shareEvery peer sees it at their next inbox and calls it by name.
3 · keepYou save it to the library and hand it to the next swarm.
evtx_queryprefetch_mamusn_journalreg_hive_querylnk_parseextract_streamfile_carveryara_scanfve_metadatasqlite_querybrowser_history…and the ones the next case writes

Tools from the library, every one written by an agent on a case it was working.

How the library growsA tool written in one case is a tool the next case starts with.
RUN 1 · A DISK IMAGE library at kickoff: empty evtx_query lnk_parse sqlite_query written during the run typed · tested · shared on the board kept RUN 2 · A PHONE AND A LAPTOP library at kickoff: three tools evtx_query lnk_parse sqlite_query usn_journal prefetch_mam three reused, two written the swarm starts where the last one stopped kept RUN 3 · AN ENCRYPTED VOLUME library at kickoff: five tools evtx_query lnk_parse sqlite_query usn_journal prefetch_mam fve_metadata yara_scan five reused, two written a peer checks the shelf before writing one kept RUN N · YOUR NEXT CASE library at kickoff: everything so far whatever this case needs the shelf is the swarm's memory a pack is this shelf, curated in advance written in this run kept from earlier runs every call to a kept tool is still attributed on the trace
Swipe to see the whole drawing
Where a case starts

Forty-five investigations, written before the evidence arrives.

A run is judged by the goal document it was handed: the questions the report has to answer, the rules the lab works under, and the shell checks that decide whether the work is finished. Writing that from an empty page is the slowest part of opening a case.

The library carries one for each kind of investigation a lab meets. A compromised Windows host. A Linux web server. A memory image with no disk. A bundle of event logs, a capture, a phone, a cloud tenant, an indicator sweep, the scope of a breach. Each one names the artefacts that answer each question, arrives with its own finish line, and is yours to edit before it runs.

Start a case from one →
The investigation library in the console's kickoff form, grouped by category with a summary and a check count for each
1 · pickThe investigation that matches the evidence in front of you.
2 · adaptName the files, drop the questions this case does not ask, keep the checks honest.
3 · runIt becomes SWARM.md, and its own checks are what certify the run.
windowslinuxmacosmemorylogsnetworkmalwarecloudmobilegeneral…and the ones you write, saved beside them

The console's goal picker: every investigation with its summary and the number of checks it carries.

Where the contract comes fromThe investigation, the method and the evidence meet once, at the kickoff.
THE INVESTIGATION · LIBRARY/ Compromised Windows host eight questions, the ground rules, how to divide the work, the finish line 10 checks yours to edit before it runs forty-five of them: windows · linux · macos · memory logs · network · malware · cloud · mobile · general THE METHOD · PACKS, OPTIONAL skills an agent fetches by name, tools already loaded, the host checks the method needs THE EVIDENCE hashed on the way in, read-only throughout Kickoff from the console THE CONTRACT · SWARM.MD the investigation, as written + the team, the caps, the bail-out + what the packs brought + the manifest of the evidence ## Checks test -f work/report.md grep -c '^| ' work/timeline.md -ge 40 grep -rqi 'sign-off' threads/main/ no peer can rewrite this file, and no agent can edit the checks it is judged by written by the examiner, binding on peers THE RUN, AND WHEN IT IS OVER agents read the same contract, divide the work between them, and cite what they find in a record they cannot edit an agent calls done when it believes the case is finished the finish line, run at that moment every check passes: the run is over one fails: done is refused and named it cannot be met: abandoned, and said so
Swipe to see the whole drawing

How a run works, from image to case file.

Six moments, each with its own view in the console and its own lines in the trace.

How the run was started: the command, the evidence, the frame it ran under, and the goal with its finish line
01Kickoff

An investigation from the library, or your own document, with its own finish line: shell checks the agents cannot rewrite. The evidence is copied read-only and hashed, or attached as an image. The team, the models and the caps are set here and recorded.

The board as a story: joining, negotiating, working
02The board

Agents read the goal, name themselves after the work they take, and post claims, findings, hand-offs and vetoes to threads on disk. The console reads the same threads back as a story.

Claims: leases held and released, violations blocked
03Leases

A path is leased before it is written and released after. Every earlier version is kept by hash. A shell write without a lease is undone from the pristine copy and announced to the board.

The raw event trace: every call with its arguments and result
04The work

Parsing, carving, querying and correlating, with the lab's tools, the library's tools and the ones written on the spot. Every call, its arguments and its result are on the trace; the reasoning behind it is recorded too.

The ledger: events, indicators, findings with citations
05The ledger

Events, indicators and findings are recorded with their source, the command that reproduces them, who recorded them, and a stated confidence. An uncited claim stays visibly uncited.

The finish line beside the evidence, every check passed
06The sentinel and the case file

When the finish line's checks pass, a sentinel appears and every agent stops. Report, ledger, board, trace and the hashes of every artefact are packaged as one handover, with its manifest.

Built for the examiner.

Each of these is a call someone had to make; the practitioner who makes these calls explains why they landed here.

acquisition & evidence

Disk images, memory dumps, mobile file-system extractions, log sets. Copied or attached read-only, hashed, integrity-checked at the end. Quarantine: nothing extracted from the evidence can execute.

tool discipline

The toolbox (Sleuth Kit, libewf, libbde, Volatility, YARA, the parsers the case needs) is checked before the run, and anything missing is named before the first agent starts.

evidence is hostile input

A URL in a chat log is a finding to record rather than a link to fetch. Nothing read in the evidence can cause a network request, an install or an execution. The contract says so, and the guard enforces it.

the report you can defend

Numbered sections that cite the artefacts they came from, a chain-of-custody section, a merged timeline and a findings table with confidence levels, rendered from the sandbox's own files and printable.

your lab, your models

Cloud providers, a private endpoint, or a model on your own hardware can be mixed in one team, with each agent's spend and calls on the record. A local-only team makes no cloud call at all.

watch it, or replay it

Each agent works in its own terminal pane you can open. The console shows the same run live and afterwards, from the same files, for the reviewer who was not in the room.

The harness

Enforced by the kernel where the platform allows. Reported honestly where it does not.

The evidence is read-only in every pane by the operating system. A pane writes inside its own run and nowhere else. The trace is written by a collector the agents cannot reach; it is hash-chained, anchored outside the sandbox and attributed by a per-pane token. And the run record names which of these the host could actually enforce.

Every guard, by platform →
We publish the escape

When a guard is only advisory, the report says so. When an agent walked around one, we published the whole account beside the run.

The trace row of the escape, expanded in the console

Worked on public cases, published with the record.

All case studies →
compromised web server

SQL and command injection, added accounts, web shells and a reverse shell, each tied to its log line.

One of the shells named as a Metasploit PHP meterpreter stager. ntfs hidden files

Streams on files and on directories, a hash in $MFT slack, and an unlinked $Quota with tampered flags.

A ZIP calling itself a JPEG, holding the very tool that reveals streams. encrypt them all

An AES password recovered from a chat in the browser cache; twin volumes of which only one is BitLocker.

A GPG passphrase was not found, and the report says so.
About DFIR Swarm

Open-source agentic digital forensics and incident response.

DFIR Swarm is a free, open-source platform for digital forensics and incident response built around a swarm of AI agents rather than a single assistant or a fixed pipeline. Given a disk image, a memory dump, a mobile extraction or a set of logs, the agents divide the case between themselves on a shared board, examine the artefacts in parallel, write the parsers and carvers they lack, argue about interpretations, and hand over a report with a merged timeline, cited findings and a chain-of-custody section. Everything they do is written to a hash-chained audit trail they cannot edit. The guards (read-only evidence, write allowlists, quarantine, egress control) are enforced by the operating system where the host allows it, and the report says which ones were only advisory.

It is built by Halil Öztürkci for examiners, incident responders and forensic labs, and published under the GNU AGPL v3 or later so that the record a run produces can always be reproduced from the source that produced it.

licence
GNU AGPL v3 or later, free software
runs on
macOS and Linux, your own hardware
evidence
disk images, memory dumps, mobile extractions, logs, packet captures
models
cloud providers, private endpoints and local models, mixed in one team
output
report, ledger, timeline, hash-chained trace, case file with manifest
source
github.com/halilozturkci/dfirswarm
Questions examiners ask

Frequently asked.

What is DFIR Swarm, in one paragraph?
An open-source platform for digital forensics and incident response in which a swarm of AI agents works a case in parallel. The agents divide the evidence between themselves on a shared board, examine it with the lab's tools and the ones they write, and leave a hash-chained record (board, ledger, trace, report) that a reviewer can replay. It runs on your own machine under the AGPL.
Is it free?
Yes. The Community edition is free software under the GNU AGPL v3 or later: no account, no key, no seat limit, and nothing a run's defensibility depends on is held back. Pro and Enterprise are provided through contact.
What evidence can the swarm work?
Disk images (raw and E01), memory dumps, mobile file-system extractions, log sets and packet captures. Evidence is copied or attached read-only, hashed before the first agent starts and checked again at the end; nothing extracted from it can execute.
Which AI models does it use, and does evidence leave the machine?
Any provider, a private endpoint, or a model on your own hardware, mixed in one team. What an agent reads becomes part of its model call, so with a cloud provider excerpts of the evidence reach that provider. This happens on the record, under an egress allowlist that logs every refused connection. A local-only team makes no cloud call at all.
How is the audit trail tamper-evident?
A collector process outside the agents' sandbox is the only writer. Each line names the hash of the line before it, the head of the chain is anchored where no agent can write, and every line is attributed by a per-pane token on macOS, or by process ancestry through a gate on Linux. The report verifies the chain and reports the result: intact, edited, appended or shortened.
Is it a pipeline with an orchestrator?
No. There is no planner that hands out tasks. Peers read the same contract and the same evidence, take work by leasing it on the board, hand it off, veto each other with artefacts, and a critic signs off by name. The division of the case follows the evidence, and it is written on the board.
Can I use it on client cases?
Yes. The AGPL asks nothing of you for running the software on your own machines, for clients, whatever you charge. The commercial licence exists for offering a modified version as a service without publishing the changes, or for shipping it inside a closed product.
Editions

The record is free software. The practice around it is the product.

Community is the whole harness, free under the AGPL, and it is what you can run today. It ships with twelve method & tool packs, 99 skills and 64 tools across Windows, Linux, macOS, mobile, memory, network, reverse engineering, encrypted containers, cloud, ransomware and triage collections, so the swarm starts a case with an examiner's method in front of it rather than working it out again. Pro adds the hosts a lab needs and keeps those packs current for the casework you actually do. Enterprise adds the team, the retention and the terms. Pro and Enterprise are reached by talking to us.

Compare editions Talk to us