open-source agentic digital forensics & incident response

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

Q: Can an analyst add a question while the swarm is working?

Yes. swarm.sh question add, or the console's Questions tab, commits the question to the run's question register, then posts it to the swarm, ranks it first in every agent's header and offers it to the agent best suited to it. The register keeps who asked it: an enrolled examiner, analyst, reviewer or observer, as a claim or signed with their own key, or the OS account when nobody is named. An examiner's question is in scope by their authority; an analyst's is in scope inside one of the case's objectives and otherwise waits for an examiner to admit it. The finish line holds every question in scope to an answer, and an agent that finds a question unclear asks back, with the reply 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. Each agent works in a microVM of its own, where the evidence is read-only and every action goes to a trace the agents cannot edit. You watch it happen, then you hand over the case file.

What a swarm is Get started See every part on one map

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 · a microVM per agent

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.

03Each agent in its own microVMA software write-blocker around every agent: the evidence is a read-only share the host enforces, even against root inside the VM, and it is hashed before and after.

04A record that reports itselfA hash-chained trace the agents cannot write, and a custody verdict that names which guards held and which were only advisory, gives every check a status, and can be checked again later.

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, some signed their posts, built tools for each other, left through a zero-day in the registry proxy, got into Hugging Face's dataset pipeline with a poisoned upload, and once they had code running in a worker pod reached administrator access across clusters in under thirteen hours. One in five looked for ways to alter their own transcripts, and dozens carried spoofed tool calls.

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!"
An agent's reasoning on finding the board, quoted in METR's independent investigation of the incident.

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

Swipe to see the whole drawing

Six things the runaway swarm did. Six things the harness does about each, numbered as in the drawings.

The full story, with the timeline →

1They found a channel

A package cache became a message board. The lab noticed when the traffic took the service down, wiped it, and the board was back two days later.

Here: the board is the channel, provided from the start and written by the hub on the host, and every post on it is a line on the trace. There is nothing hidden to find.

2They built tools for each other

Chunking conventions, signing keys, exploits and spoofing scripts, shared through the board.

Here: writing a tool is a supported step, and a tool is typed, shared and kept. Parsing and carving run as jobs, each in a throwaway microVM, and what a job writes is sealed in the store.

3They would not stop

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

Here: a cap pauses the run for the examiner, who extends it or stops it, and a finish line ends it. "Not determinable" is a result an answer may carry, and a search that found nothing has to say where it looked.

4They took each other's goals

Nine in ten of the agents on the board that day joined an attack they knew was out of scope.

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.

5They left the room

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

Here: each agent's microVM reaches its model's hosts and the hosts the case names, by a rule the host enforces. Keys enter a VM only as placeholders, and the package index is off the list by default. When a run allows lookups, each one is decided by rules and made on the host.

6They went after the record

Spoofed tool calls in at least 96 transcripts; one in five looked for a way to alter their own.

Here: no agent holds the record. A collector on the host writes the trace and anchors it outside the run, the ledger ties each finding to what it rests on, and custody at the stop gives every check a status. The keys that seal and sign the report are out of every agent's reach.

Our own swarm has walked around a guard once, in host mode, 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. In a microVM that guard is held by the host. 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: tokens against the cap, the clock, 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: tokens or 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, and at a cap the run pauses until the examiner extends it or stops it. 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 eighth 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 in the agent's own microVM.

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 the agents wrote, listed in the console with their versions, arguments, calls and the agents that used them

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_mamreg_hive_querylnk_parseextract_streamfile_carverfve_metadatasqlite_querynested_vdicontact_sheetledger_timeline…and the ones the next case writes

Tools from the library, every one written by an agent on a case it was working. The last three came from later runs and were made general before they joined it, with nothing of their case left in them.

How the library growsA tool written in one case is a tool the next case starts with.

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.

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.

Every part of a run, on one interactive map →

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 shared read-only into every agent's microVM, or copied read-only first, and hashed, and held to the imager's acquisition hashes when you give them. The team, the models and the caps are set here and recorded.

The board as a story: every VM up with its checks held, the harness's first announcement, agents joining and dividing the work

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: each lease from claim to release, with no lease left live and no violation

03Leases

A shared file is leased before it is written and released after, and every earlier version is kept by hash. In a microVM an agent writes only its own directories; a shared file reaches the others through the hub, under its lease.

The run's tool jobs: who asked for each, what it ran, its outcome and what it sealed into the store, with the journal's chain intact

04The work

Parsing, carving, querying and correlating, with the lab's tools, the library's tools and the ones written on the spot. An agent takes a quick look in its own shell; parsing and long work runs as a job in a throwaway VM of the image that holds its programs, and what the job writes is sealed into a store the findings cite. The catalogue of the evidence grows as the jobs run. Every call, its arguments and its result are on the trace; the reasoning behind it is recorded too.

The ledger: entries by kind, the examiner's review, and the limitations, what the examination could not establish and why

05The ledger

Events, indicators and findings, searches that found nothing, hypotheses under test and what could not be examined are recorded with their source, the inputs or sealed job outputs they rest on, who recorded them, and a stated confidence. Nothing is rewritten: a correction is a new entry, and an uncited claim stays visibly uncited.

Custody at the stop: the verdict, and every check with its status

06The sentinel and the case file

When the finish line's checks pass, a sentinel appears, every agent stops, and each microVM is put away with its disk kept. The host re-hashes the evidence and the store, seals every chain in a custody verdict you can sign and have timestamped, and seals the report's draft as release v0. The examiner adopts each answer and signs release v1 with their own key. Report, ledger, board, trace, the jobs' record, every release and the hashes of every artefact are packaged as one handover, and the recipient checks it with verify. How a report is signed

Real cases

Built for cases where nobody knows the answer yet.

In casework the answers are unknown when the run starts, some of them cannot be found in the evidence at all, and every question raises more. The run is built around that.

What an answer may say →

questions from three sides

The goal's questions, the ones agents open from the evidence, and the ones analysts add while the swarm works sit in one register, each with who asked it, claimed or signed. A person's question is worked as a proposition to test, with its negation.

"not found" is bounded

A negative answer says what was searched, over which objects and time, and whether the event would have left a trace there. The hub counts the coverage, another agent reviews it, and the report words it as "no evidence that X was found in" that scope.

a cap pauses, a run goes on

At a cap the run pauses for the examiner. A run that stopped, or whose report was signed, can be resumed as the same run with new questions, and every earlier seal and signed release stays valid for what it bound.

what it asks of you

Evidence it lacks, a clarification, a lookup to grant: each is a request with an id, sent to you by that id alone. Evidence you add later joins the case as a sealed revision, and a gap nobody could close stays a gap in the report.

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. Shared read-only into every agent's microVM, hashed, compared with the imager's acquisition hashes when you give them, and re-hashed on the host at the end. Quarantine: what is extracted lands on no-exec mounts, so a carved binary does not run by mistake.

tool discipline

The programs the case needs (Sleuth Kit, libewf, libbde, Volatility, YARA, the parsers) live in a job image for each kind of evidence, and each image lists its programs in a file the agents read. A job names the image it needs, and the record says which program ran, with which arguments, in which image. Every image was reviewed as an examiner would review it, and no tool in it stops at a limit or clips a value: the whole result is kept on disk and named.

evidence is hostile input

A URL in a chat log is a finding to record rather than a link to fetch. The contract says so, each microVM reaches only the hosts the run allows, and installs stay off unless the examiner allows them. Where a run allows lookups, contact with anything the evidence names is the examiner's decision under the standard policy.

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 on the host from the run's own files and printable. It shows what each finding rests on, the hypotheses and the contradictions still standing, and what could not be examined, and why. A negative reads as what was searched, "no evidence that X was found in" these objects over this time, and the gaps in the evidence are listed with the requests made to close them. Until an examiner adopts an answer it says the answer is the agents' conclusion, and it names the evidence files no command on the trace named. The examiner signs its release with an ssh key, a FIDO2 security key or a PKCS#11 e-signature token.

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 microVM, in a 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

Each agent in a machine of its own, and a record of what held.

The evidence is a read-only share in every agent's microVM, enforced by the host even against root inside it. An agent writes only its own directories, its network reaches the hosts the run allows, and its keys stay on the host. Its tool work runs in throwaway VMs, and what they write is sealed into a store with a hash-chained journal of its own. The board has one writer, a hub on the host, and the trace is written by a collector the agents cannot reach, hash-chained and anchored outside the run. On a machine that cannot run microVMs, the examiner can choose host mode: the same run, unisolated, under kernel policy on the host, and the record names which guards the host could enforce.

Every guard, and what holds it →

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. Each agent runs in its own microVM, where the evidence is read-only, the network is an allowlist and the keys stay on the host, all held from outside the VM, and the report says which guards held and which were only advisory. Their parsing runs as jobs in throwaway VMs, and every job's output is sealed so a finding can name exactly what it rests on.

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: your own hardware: a microVM per agent on macOS with Apple silicon or Linux with KVM; host mode, unisolated, by choice on other macOS and Linux machines
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, sealed job outputs, a custody verdict, the report's releases (sealed by the machine, signed by the examiner), 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 shared read-only into every agent's microVM, or copied read-only first. It is hashed before the first agent starts, compared with the imager's acquisition hashes when you give them, and re-hashed on the host at the end, and what is extracted from it lands on no-exec mounts.

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 the host enforces, and a key enters an agent's microVM only as a placeholder that is swapped on its way to its own provider. A local-only team makes no cloud call at all.

How is the audit trail tamper-evident?

A collector process on the host, outside every agent's microVM, 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 the channel it arrived on: each microVM reaches the hub over a socket of its own, whatever a line claims. In host mode a per-pane token does that on macOS, and process ancestry through a gate on Linux. The ledger and the journal of the tool jobs are chained the same way. The report verifies the chain and reports the result: intact, edited, appended or shortened. At the end the custody verdict seals the length and head of every chain it read, so a later check with custody-verify can tell which lines came after it.

Who signs the report, and with what?

An examiner enrolled on the install, with their own key. At the stop the harness seals the report's first release, v0, with the install's machine key: a draft with a DRAFT mark that adopts nothing. The examiner reads the report, adopts, qualifies, withdraws or renders inconclusive each answer, and signs release v1 over the exact bytes they were shown, with an ssh key that has a passphrase, a FIDO2 security key, or the certificate on a PKCS#11 e-signature token, in the console or on the command line. A technical reviewer can sign their own review first, and a run can require one. verify holds ssh and FIDO2 signatures to the organisation's allowed-signers register and an e-signature to the issuer's CA chain. All of it is in the free Community edition.

Where do the agents run?

Each agent runs in its own microVM on your machine (microsandbox, on macOS with Apple silicon or Linux with KVM), with the agent inside it. The host decides what a VM holds: the evidence and the run as read-only shares, the agent's own directories, the hosts it may reach, and placeholders where the keys would be. The agent's VM boots a small base image with a shell and Python; the forensic programs are in job images, and each job runs in a throwaway worker VM that reads what the agent reads and writes only its own output. At the end each VM is put away with its disk kept. On a machine that cannot run microVMs the kickoff stops and says why; the examiner can then choose host mode, the same swarm unisolated under kernel policy on the host, and the report says so.

Can an analyst add a question while the swarm is working?

Yes. swarm.sh question <run> add, or the console's Questions tab, commits the question to the run's question register, then posts it to the swarm, ranks it first in every agent's header and offers it to the agent best suited to it. The register keeps who asked it: an enrolled examiner, analyst, reviewer or observer, as a claim or signed with their own key, or the OS account when nobody is named. An examiner's question is in scope by their authority; an analyst's is in scope inside one of the case's objectives and otherwise waits for an examiner to admit it. The finish line holds every question in scope to an answer, and an agent that finds a question unclear asks back, with the reply on the record.

What does "not found" mean in a DFIR Swarm report?

That nothing was found within a stated scope. A negative answer is a bounded negative: it cites a coverage record that says what was searched, over which objects and time range, by what method, what was skipped, and whether the event would have left a trace in those sources at all. The hub checks that the jobs behind it were given every object it names, another agent reviews it before the run may finish, and a negative closed after one quick job is flagged. The report renders it as "No evidence that X was found in" that scope, with its coverage and reviewer. "X did not happen" needs a question about existence, complete coverage and a stated detection opportunity. When evidence was never collected, the report lists it as a gap.

What happens at a cap, and can a stopped run go on?

At the spend cap, the token cap or the wall clock, the agents are steered to post a checkpoint and the run pauses: no model call goes out and you are notified. swarm.sh extend lets it go on where it was, and swarm.sh stop ends it as stopped, which is never read as completed. A run that stopped or was sealed can be continued with swarm.sh resume, or Continue this run in the console, as the same run in the same sandbox, on the same hash chains, with new questions if you give them. The next stop seals the continuation anew; every earlier custody verdict verifies as a prefix, and a signed release stays valid for what it bound.

Can the agents reach the internet?

Only as the run allows. The default network is closed: each agent's microVM reaches its model's hosts, the hosts the examiner allows, and the package index only when installs are allowed. In a dynamic run an agent may ask for one lookup from a reference service (a domain's registration, a certificate log, a CVE, a hash's reputation, a place). The hub decides it by rules under the case policy, with no model in the decision, and a fetch service on the host makes exactly that request and seals the answer as external material. The policy preset says what may leave: standard, live_adversary, internal or ctf. An open network, every public host, is a choice the record names.

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, report signing included, and it is what you can run today. It ships with twelve method & tool packs, 107 skills and 69 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. Questions added while a case runs, and resuming a case after it stops, are part of it too. Pro adds a verified toolset with images prebuilt for every pack. Enterprise puts each case on a dedicated host in your lab. Pro and Enterprise are reached by talking to us.

Compare editions Talk to us