AI Forensic Investigator

I Spent a Weekend Building an AI Forensic Investigator. Here's Exactly How I Did It.

I do a lot of work in cloud security. But this past weekend I went deeper into the stack than usual — into digital forensics — and built something that genuinely changed how I think about AI in security work.

This is the full story of what I built, how it works, and what surprised me along the way.

First — what problem was I trying to solve?

When a company gets hacked, someone has to reconstruct exactly what happened. Not just "we got breached" — but how did they get in, what did they touch, how long were they there, and what did they take?

That work is digital forensics. And it's exciting.

A forensic analyst sits down with a memory dump, disk images, and logs that might span millions of events across days or weeks. They run a tool. They find something odd. They note the process ID, manually switch to another tool, cross-reference the results, pivot again. Every step is a human decision. Every connection between pieces of evidence has to be held in one person's head simultaneously.

A serious investigation can take days — and the bigger the incident, the worse it gets.

I kept thinking: the tools already exist. The knowledge of what to do next already exists. What if the investigator didn't have to be the one executing every single step?

The platform I built on

The SANS SIFT Workstation is the industry-standard Linux environment that professional forensic investigators use. It comes with 200+ specialist tools covering everything from memory forensics to disk imaging to log analysis. It's powerful — and completely manual.

I built Protocol SIFT on top of it: an AI agent that operates the SIFT toolset autonomously, reasons over what it finds, and chains its own next actions without waiting to be told what to do.

The key technology underneath is MCP — Model Context Protocol. MCP is a way of exposing tools to an AI in a structured way, so the AI knows what each tool does, what inputs it needs, and how to interpret what comes back. Think of it as giving the AI a properly labelled toolkit rather than a pile of unlabelled parts.

How I set it up

The first thing to get right was the gateway — the layer that connects Claude to the forensic tools.

The gateway confirming it's live: 49 tools connected across 4 backends, with all controls — sandbox, deny rules, audit hook — confirmed active.

This screen matters more than it looks. Each of those backends is a separate MCP server:

• forensic-mcp — the core toolset: memory analysis, filesystem, timeline, registry

• sift-mcp — SIFT-specific tools and the 58 forensic utilities

• case-mcp — case and evidence management

• report-mcp — structured output and report generation

The controls listed at the bottom — sandbox enabled, 43 deny rules, audit hook, prompt hook — are the guardrails that enforce forensic discipline. The AI runs inside a walled environment where it cannot modify evidence, only read it. Every action is logged. The deny rules define what it's not allowed to do without explicit human approval.

Getting all four backends healthy and all controls active was the first milestone. Without this, nothing else works.

Starting an investigation

Once the gateway was running, I launched Claude Code inside the case directory and handed it the evidence.

Claude Code starting up in the case directory. The agent immediately inventories the evidence files, creates a mental task plan, and reads its own permission settings before touching anything.

This startup behaviour was one of the things I was most deliberate about designing. The first thing the agent does is not start running tools. It reads its own configuration — what it's allowed to do, what requires human approval, what's forbidden — and only then starts planning.

The evidence manifest it loaded covers 11 artefact types:

• process_tree.txt — full process tree showing parent-child relationships

• socket_map.txt — all open network sockets with owning processes

• login_history.txt — recent authentication activity

• running_services.txt — all active systemd services

• recent_files.txt — files modified in the last 24 hours

• crontabs.txt — scheduled tasks

• installed_packages.txt — all installed software

• active_connections.txt — live network connections

• suid_binaries.txt — SUID binaries with privilege escalation potential

• environment.txt — system environment variables

• init_scripts.txt — startup scripts

That's a lot of data to hold in your head manually. The agent ingests all of it, reasons across it simultaneously, and starts building a picture.

The agent actively reasoning mid-investigation — running bash commands, checking case state, building its task plan. Note the "Inferring... still thinking" indicator: this is the agent working, not waiting.

What it found

This is where it gets interesting.

Finding A: Firefox RDD process with extreme CPU accumulation — 1,627 minutes of CPU time running at 143% on a media subprocess. The agent flags this as a potential cryptomining signature and maps it to MITRE ATT&CK T1496 (Resource Hijacking).

Let me explain what the agent did here. It didn't just look at the process list and notice Firefox was running. It:

1. Identified that the subprocess type — rdd (Remote Data Decoder) — is a media handler, not a compute-heavy process

   
   

2. Noted that 27+ hours of CPU time on a media decoder with no obvious corresponding video activity is anomalous

3. Connected that behavioural signature to browser-based cryptomining via WebAssembly

4. Assigned a confidence rating (LOW-MEDIUM, because there was no corroborating network traffic to mining pools)

5. Mapped it to the correct MITRE technique

That last point — assigning a confidence level honestly — was something I had to build explicitly. The agent is trained to distinguish between what the evidence directly shows and what it's inferring. A low-confidence finding is still reported, but it's clearly labelled as one. In forensics, that distinction matters enormously.

Finding C: the agent surfaces a broad attack surface finding — SSH, SMB (both ports), HTTP, and GNOME Remote Desktop all listening on all interfaces. It maps this to T1021.002 and T1021.005, assesses it as informational, and asks for human approval before recording it.

This screenshot shows something important about how the human-in-the-loop works. The agent doesn't just dump findings silently — it surfaces them with a specific approval prompt. The investigator decides whether to record it, dismiss it, or investigate further. The AI does the legwork; the human retains the judgement call.

The hardest part of building this

I expected the hardest part to be the AI reasoning, or getting the forensic tools to behave. It was neither.

It was the schema layer.

Every forensic tool outputs data in its own format. Some produce structured JSON. Some produce fixed-width ASCII tables that haven't changed since the 1990s. Some are completely silent on success and cryptically verbose on failure. Getting all of that normalised into a consistent format the AI could reason over reliably was roughly 40% of the total engineering effort — and the part I'd most underestimated going in.

The lesson I took from it: when you're building AI integrations over an existing toolchain, the transformation layer between raw tool output and structured AI input is the real product. Get that wrong and the reasoning on top of it doesn't matter.

The rule I built in — and why

Forensic reports end up in legal proceedings. That means there is a hard, non-negotiable line between what the evidence shows and what someone thinks might have happened.

I built one strict rule into the system: the agent can only report what the tools actually found. Every finding must be attributed to a specific output from a specific tool. Anything inferred is clearly labelled as inference — it appears in a separate section of the report, never mixed with verified findings.

You can see this in the screenshots above. Each finding has an Observation (what the data shows), an Interpretation (what that might mean), a Confidence rating, and a MITRE ATT&CK mapping. The observation is grounded in tool output. The interpretation is clearly the agent's reasoning. The confidence rating tells the investigator how much weight to put on the interpretation.

Language models naturally want to fill gaps and connect dots. In most applications that's useful. In forensics it can be catastrophic. Enforcing epistemic discipline — making the AI show its working and label its confidence — required deliberate prompt engineering and structural constraints, not just good intentions.

What this changes about the investigator's role

The most interesting thing I took away wasn't technical.

The forensic investigator's role doesn't disappear when you add a capable AI layer. It changes. The analyst moves from mechanical execution — running commands, switching tools, correlating data by hand — to strategic supervision. They direct the investigation at a higher level, validate findings, and apply judgement where judgement genuinely matters.

The investigator who used to spend three days on a single incident can now run three in parallel, going deeper on each rather than shallower.

That's not automation replacing expertise. It's expertise being applied at a higher level than before.

What's next

Protocol SIFT is a working proof of concept. From here, the natural path forward is:

• Connecting live threat intelligence feeds so the agent can cross-reference findings against current IOC databases in real time

• Building proper case management so multiple investigations can run, pause, and resume

• Generating court-ready reports with full chain-of-custody documentation

• Eventually running the AI on local infrastructure so sensitive evidence never leaves the building

The foundation is solid. The architectural questions are answered. What's left is building.

I'm a Cloud Architect working at the intersection of security and AI. If you're thinking about AI-assisted investigations, agentic security tooling, or anything in this space — I'd love to connect.