Using Claude Code or Codex for Forensic Investigation and Cyber Incident Response
AI coding agents like Claude Code and Codex can be extremely powerful during forensic investigations and cyber incident response. After using these tools in depth, I think they can genuinely accelerate analysis, timeline building, evidence review, and report writing.
But there is a catch.
They can also generate a lot of useless slop.
If you treat them like magic forensic analysts, you are going to get screwed. These tools are only as good as the context, constraints, evidence, and instructions you give them. In incident response, vague prompts create vague findings. Worse, they can create confident-sounding conclusions that are not actually supported by evidence.
That is dangerous.
In a real investigation, every claim needs to trace back to logs, artifacts, timestamps, commands, file paths, hashes, authentication events, network activity, or some other concrete evidence. If the agent cannot prove it, it should not say it as fact.
The Problem With AI Agents in Incident Response
The biggest issue I have seen is that the agent will sometimes act like it reviewed everything when it did not.
For example, you may give it a directory full of logs, configs, command outputs, archives, and forensic artifacts. It may inspect a few obvious files, summarize what it found, and then imply that it completed a full investigation.
That is not good enough.
In incident response, missing one log file can mean missing the initial access vector. Missing one authentication log can mean missing lateral movement. Missing one configuration file can mean missing persistence. Missing one timestamp can break the entire incident timeline.
Some of the specific issues I have run into:
The agent does not analyze every log or folder in the evidence directory.
The agent assumes it checked everything when it only reviewed a subset.
The agent follows rabbit holes that do not matter.
The agent makes broad statements without enough evidence.
The agent uses language like “the threat actor did X” when the evidence only shows that something suspicious happened.
The agent misses important context because the prompt did not explain the environment, systems, timeline, or investigation goals clearly enough.
The agent produces a nice-looking report that feels polished but is not forensically strong.
That last point is the most dangerous.
A polished report is not the same as a defensible report.
You Need to Prompt Like an Incident Commander
The best results come when you stop treating the agent like a chatbot and start treating it like a junior analyst working under a strict incident commander.
You need to give it structure.
You need to tell it what evidence exists, what systems are involved, what behaviors to look for, what claims it is allowed to make, and what evidence standard it must meet.
The prompt should force the agent to:
Search every log file.
Review every artifact.
Cite evidence paths and line numbers when possible.
Separate confirmed findings from hypotheses.
Assign confidence scores.
Build a timeline from timestamps.
Identify gaps instead of pretending the story is complete.
Avoid making unsupported claims.
Avoid saying “threat actor” unless the evidence actually supports adversary activity.
Preserve exact technical details such as IPs, users, commands, file paths, process names, hashes, and configuration changes.
This is especially important because Claude Code and Codex are very good at navigating codebases and directories, but forensic evidence is messy. Logs are noisy. Artifacts are inconsistent. Important details may be buried in plain text, JSON, CSV, Windows event exports, firewall logs, EDR telemetry, shell history, configs, or compressed archives.
The agent needs to be told not to skip anything.
The Right Way to Use Agents for IR
One of the better patterns is to create a multi-agent investigation structure.
Instead of asking one agent to “analyze the incident,” break the work into roles, here are xamples:
Incident Commander Agent
Workstation Forensic Analyst Agent
Router Forensic Analyst Agent
Firewall Forensic Analyst Agent
Domain Controller Forensic Analyst Agent
Server Forensic Analyst Agent
Each forensic analyst is responsible for one system or evidence category. The Incident Commander coordinates the investigation, tracks findings, correlates evidence, and builds the final report.
This works better because it creates separation of duties. Each analyst has a specific scope, and the commander is responsible for stitching the story together.
In a real large-scale incident, this is how serious investigations work. Analysts are assigned to different systems, where they create timelines of what occurred on the specific systems.
AI agents should follow the same model.
Example Prompt for Claude Code or Codex
Here is a stronger prompt pattern I would use for a forensic investigation:
We have collected a large amount of evidence, but the incident story is still incomplete.
Build a coordinated investigation plan using multiple agents.
Create the following agent structure:
1. Incident Commander Agent
2. Forensic Analyst Agent for workstation
3. Forensic Analyst Agent for router
4. Forensic Analyst Agent for firewall
5. Forensic Analyst Agent for domain controller
6. Forensic Analyst Agent for server 1
The Incident Commander Agent is responsible for coordinating the full investigation, assigning work, tracking findings, correlating evidence across systems, and building the final incident timeline.
Each Forensic Analyst Agent must perform a deep analysis of its assigned system using all available evidence in this directory.
Requirements:
- Search every available log file.
- Review every collected artifact.
- Do not leave any log, file, archive, config, command output, or evidence item unsearched.
- Identify signs of compromise, attacker activity, persistence, credential access, lateral movement, configuration changes, abnormal authentication, suspicious process execution, network activity, and timeline anomalies.
- Extract exact timestamps, usernames, IP addresses, commands, file paths, hashes, process names, configuration changes, and relevant log entries.
- Preserve evidence references by file path and line number whenever possible.
- Clearly distinguish confirmed findings from hypotheses.
- Do not use language like “the threat actor” unless there is direct evidence of adversary activity.
- Assign confidence scores to major findings.
- Every major statement must be supported by log evidence, artifact evidence, or a clearly marked hypothesis.
- Each Forensic Analyst Agent must produce a system-specific findings report.
The Incident Commander Agent must consolidate all agent findings into:
- Executive summary
- Incident timeline
- Affected systems
- Confirmed findings
- Hypotheses
- Indicators of compromise
- Attacker actions
- Evidence gaps
- Recommended next steps
Start by building the investigation plan, then execute the analysis agent by agent.
Store the final results in a new Markdown report.The Most Important Rule: Evidence First
The agent should not be allowed to write like a consultant trying to sound smart. It should write like an investigator trying to prove what happened.
Bad language:
The threat actor compromised the workstation and moved laterally to the domain controller.
Better language:
Evidence shows successful authentication from workstation HOST-01 to domain controller DC-01 at 2026-05-15 03:42:11 UTC using account j.smith. This activity occurred after suspicious process execution on HOST-01. Based on the sequence of events, lateral movement is suspected with medium confidence, but additional authentication logs and EDR telemetry are needed to confirm attacker control of the account.
That difference matters.
The first version sounds confident but may not be defensible.
The second version shows evidence, timestamp, source system, destination system, username, confidence level, and the remaining gap.
That is how IR reporting should work.
Give the Agent More Context Than You Think It Needs
Another mistake is assuming the agent understands the environment.
It does not.
You need to provide as much technical detail as possible. Tell it what the systems are, what each system does, what normal should look like, what time window matters, what logs were collected, and what the suspected incident is.
Useful context includes:
Threat intelligence on relevant TTPs
Known IOCs
Hostnames and system roles
IP addresses and subnets
Domain names
User accounts of interest
Known admin accounts
Time zone
Suspected compromise window
Security tools in use
Log sources collected
Known suspicious indicators
Business-critical systems
Expected authentication patterns
Network architecture
Any containment actions already taken
The better the context, the better the investigation.
Without context, the agent may spend time chasing noise. With context, it can focus on what matters.
Use Tight Constraints to Reduce Slop
The best prompts are strict.
Tell the agent exactly how to behave:
Only make statements based on evidence.
Do not speculate unless the section is clearly labeled Hypothesis.
Do not use the phrase “threat actor” unless there is direct evidence of adversary behavior.
For every finding, include:
- finding name
- affected system
- timestamp
- evidence path
- exact log entry or artifact reference
- confidence score
- reasoning
- recommended next step
If evidence is missing, say what is missing.
Do not claim that all logs were reviewed unless every file in the directory was enumerated and checked.That last line is important.
I want the agent to prove it reviewed the evidence set. It should enumerate files, track what was reviewed, and identify anything it could not parse or access.
Recommended Report Structure
A good final report should look something like this:
# Incident Investigation Report
## Executive Summary
## Scope
## Evidence Reviewed
| Evidence Item | Type | System | Reviewed | Notes |
|---|---|---|---|---|
## Investigation Methodology
## System-Specific Findings
### Workstation Findings
### Router Findings
### Firewall Findings
### Domain Controller Findings
### Server 1 Findings
## Consolidated Timeline
| Timestamp | System | Event | Evidence | Confidence |
|---|---|---|---|---|
## Confirmed Findings
## Hypotheses
## Indicators of Compromise
| Indicator | Type | Source | Context |
|---|---|---|---|
## Suspected Attacker Actions
## Evidence Gaps
## Recommended Next Steps
## Appendix: Evidence ReferencesThis structure forces discipline. It also makes the report usable by technical teams, executives, legal, compliance, and other responders.
Final Thoughts
Claude Code and Codex can absolutely help with forensic investigation and cyber incident response.
They can review large evidence directories, summarize logs, build timelines, extract indicators, correlate activity across systems, and generate structured reports. Used properly, they can save a lot of time.
But they are not magic.
They need strict instructions, strong context, defined roles, evidence requirements, and guardrails against unsupported conclusions.
The goal is not to have the agent write a beautiful story.
The goal is to have the agent help prove what happened.
In incident response, that distinction is everything.