DEV Community: Qimin Zhao

Turning first-pass host evidence into a DFIR handoff report

Qimin Zhao — Fri, 29 May 2026 15:03:48 +0000

Most incident-response writeups focus on the detection moment: a suspicious IP, a strange login, a web-root file, a Java service behaving oddly, or a process listening on a port it should not expose.

That first clue matters, but the next problem is usually more operational:

How do you turn the first 15-30 minutes of host triage into something another responder can trust, review, and continue?

A useful first-pass handoff is not just a paragraph that says "probably compromised." It should preserve the evidence trail, the commands or collectors used, the confidence level, the gaps, and the next manual checks.

Here is the handoff shape I like for AI-assisted host investigation.

Start with a bounded question

Instead of giving an AI agent a production shell, start with a narrow investigation question and a time window.

For example:

oi ask "Investigate this server for suspicious login, web, process, network, persistence, and recent-file clues over the last 7 days. Do not remediate." -s 7d

Or if the alert starts from one external address:

oi ip 203.0.113.77 -s 7d

The important part is not the exact command. The important part is the boundary: collect and correlate host evidence, but do not mutate the host.

Collect evidence by category, not by vibes

For a server case, a first pass should usually cover at least these areas:

authentication events and failed/successful login patterns
local accounts, groups, sudoers, and authorized keys summaries
process snapshots and suspicious command lines
listening sockets and active network connections
systemd, cron, startup items, and other persistence points
web logs and recent web-root file changes where relevant
Java process and memory-shell perimeter clues where relevant
recent files, packages, containers, and shell history clues

The goal is not to prove the whole incident in one pass. The goal is to avoid handing off a vague summary with no supporting trail.

Keep the case directory as the handoff object

Open Investigator writes every run into a case folder like this:

.oi/cases/<case-id>/
  case.json       # investigation input and mode
  evidence.jsonl  # evidence records with evidence_id
  commands.log    # allowed/denied command audit
  report.json     # structured report
  report.md       # human-readable report

That structure is useful because different responders need different artifacts.

The analyst reading quickly wants report.md.

The person validating claims wants evidence.jsonl.

The reviewer checking what the tool did wants commands.log.

The team integrating the result into a ticket, case system, or downstream tool wants report.json.

What should go into report.md

A good first-pass report should separate conclusions from evidence. I would expect sections like:

executive summary
observed signals
timeline or chain of suspicious activity
key evidence IDs
confidence and risk level
evidence gaps
recommended manual follow-up
explicit non-actions taken by the tool

The phrase "explicit non-actions" matters. If the tool did not block an IP, kill a process, delete a file, disable an account, restart a service, change firewall state, or isolate the host, the report should make that clear.

That is not just legal caution. It helps the next responder understand that the system was used for investigation, not remediation.

What should go into commands.log

If an AI system can ask for host checks, the audit trail should show what was allowed and what was denied.

For example, I want to know whether the run used only sealed read-only collectors, whether a policy-filtered read-only command fallback was used, and whether anything was denied because it looked destructive or outside scope.

A useful command audit answers:

Which collector or command ran?
Why was it allowed?
Was anything denied?
Which case did the action belong to?
Did it write only to the case directory?

This is one of the places where AI incident tooling should be boring on purpose.

Do not let the summary outrun the evidence

The report should not pretend to know what it did not inspect.

Examples of honest gaps:

outbound traffic was not proven
EDR telemetry was not correlated yet
cloud control-plane logs were not reviewed
packet captures were not available
application-level impact was not validated
Java deep diagnostics were not enabled
heap or JFR artifacts were intentionally not collected

Those gaps are not failures. They are the checklist for the next responder.

Why read-only matters for handoff

In an incident, the first tool that touches the host can accidentally change the evidence story.

For a first-pass AI investigator, I want the default boundary to be:

read logs, metadata, process snapshots, network state, persistence config, and relevant file metadata
write only case artifacts and audit records
avoid remediation authority by default
require explicit flags for heavier diagnostics
preserve enough raw evidence for a human to challenge the summary

That boundary makes the result more useful to a real DFIR/SOC workflow because another person can pick up the case without guessing what the AI changed.

A practical handoff checklist

Before sending the case to a teammate, I would check:

Is the original question and time window clear in case.json?
Does report.md cite evidence IDs instead of unsupported claims?
Does evidence.jsonl include the raw or summarized observations needed to challenge the conclusion?
Does commands.log show allowed and denied actions?
Are gaps written as follow-up tasks?
Are heavy artifacts, if any, explicitly requested and stored under the case directory?
Is the report clear that investigation happened but remediation did not?

That is the difference between "AI wrote a summary" and "the team received a case they can work."

Where Open Investigator fits

I maintain Open Investigator at Arvanta Cyber. It is an Apache-2.0 local AI server investigator for Linux and Windows incident response.

The design goal is narrow: let AI collect and correlate host evidence through sealed read-only tools, then produce reviewable case artifacts. It is not an EDR replacement, not a SIEM/SOAR replacement, and not an automated remediation system.

Useful starting points:

Product overview: https://www.arvantacyber.com/open-investigator/
AI DFIR report page: https://www.arvantacyber.com/open-investigator/ai-dfir-reporting-tool/
Open-source repo: https://github.com/SEc-123/open-investigator

I would be interested in how other DFIR, SOC, SRE, and security engineering teams structure first-pass handoff reports. The report format is often where tooling either becomes operationally useful or turns into one more summary to distrust.

How to triage Java memory-shell clues without unsafe default heap dumps

Qimin Zhao — Fri, 29 May 2026 13:05:06 +0000

Disclosure: I maintain Open Investigator at Arvanta Cyber.

A suspected Java memory shell is an awkward incident-response starting point. You may not have a clean IOC. You may only have a strange request path, a servlet that should not exist, a web process that opened an unexpected connection, or a Java service that suddenly behaves differently after a deploy window.

The risky move is to jump straight to heavy production diagnostics. Heap dumps and flight recordings can be useful, but they can also be large, sensitive, and disruptive if a team treats them as the first button to press.

For a first pass, I want a safer question:

What read-only evidence can I collect before asking for heavier JVM inspection?

The first-pass Java triage loop

I would start with low-impact context:

Identify Java processes and service owners.

Look at process command lines, working directories, users, service managers, and how the JVM was launched.

Review JVM flags and attach-style clues.

Useful clues include unexpected -javaagent, -agentlib, JDWP, Xbootclasspath, suspicious classpaths, unusual temp directories, and command lines that do not match the expected service unit.

Correlate with web and app evidence.

A memory shell often matters because it is reachable through a web surface. I want nearby web logs, request paths, status codes, user agents, reverse proxy logs, app logs, and recent changes under web roots or application directories.

Expand to process and network context.

Which ports are listening? Are there new outbound connections from the Java user? Are there child processes that should not exist? Did the Java service touch files or directories at the same time as the suspicious request?

Check persistence around the same window.

Systemd units, cron entries, startup scripts, modified service files, package changes, and recently changed files can explain whether this looks transient or durable.

Where AI can help safely

AI is useful here when it correlates many small pieces of evidence. It is less useful, and more dangerous, when it gets broad production-changing authority.

For this type of investigation, I want the AI to ask for bounded read-only checks and produce a report a human can challenge. I do not want it to kill the Java process, delete files, restart the service, block IPs, disable accounts, or start dumping memory without approval.

With Open Investigator, the low-impact starting point looks like this:

oi java -s 14d
oi mem -s 14d

Those checks focus on Java process metadata, JVM launch clues, related web/app evidence, process context, network context, recent files, and persistence evidence.

If the production owner approves deeper JVM inspection, the deeper path is explicit:

oi mem -s 14d -m inv --java-deep
oi java -s 14d -m inv --java-deep

And heavy artifacts are separate decisions:

oi mem -s 14d -m inv --java-deep --heap-dump
oi mem -s 14d -m inv --java-deep --jfr-dump

That separation matters. A first-pass report should not quietly turn into a heap dump workflow.

What the output should achieve

The goal is not AI says this is a memory shell. The useful output is a case folder with evidence and uncertainty preserved:

evidence.jsonl for individual evidence records
commands.log for commands and denials
report.json for structured handoff
report.md for responder review

A good report should say what was observed, what is suspicious, what looks normal, what evidence is missing, and what needs manual confirmation.

That is the practical value: faster first-pass triage without pretending the tool has finished the incident.

Where Open Investigator fits

Open Investigator is an Apache-2.0 local AI server investigator. It runs on Linux and Windows hosts and gives the model sealed read-only tools for auth, accounts, processes, network, persistence, services, web logs, Java clues, recent files, packages, containers, and history.

The boundary is deliberate: it investigates, but it does not remediate.

Related Arvanta page on Java memory-shell investigation:
https://www.arvantacyber.com/open-investigator/java-memory-shell-investigation/

Open Investigator overview:
https://www.arvantacyber.com/open-investigator/

Open-source repo:
https://github.com/SEc-123/open-investigator

I would be interested in feedback from Java operators, SREs, DFIR teams, and blue-team engineers: what evidence would you require before approving deeper JVM inspection on a production service?

How to investigate suspicious SSH logins without giving AI a shell

Qimin Zhao — Fri, 29 May 2026 12:37:46 +0000

A lot of Linux incident response starts with a login question, not a malware sample.

Someone sees a spike of failed SSH attempts. A root login appears in the wrong time window. A service account logs in from an address nobody recognizes. A helpdesk ticket says "the server looks weird" and the only concrete clue is a username or IP address.

At that point, the useful question is not "is this host compromised?" It is more boring and more important:

Did anyone actually authenticate?
Which account was involved?
Was it password, key, sudo, su, or a scheduled task?
Was the same IP seen in web logs, current sockets, process context, or command history?
Did persistence, services, packages, or recent files change near the same time?
Can another responder review exactly what evidence was collected?

That last point matters. If you let an AI assistant freely run shell commands during the first pass, you can get speed, but you also create a new risk: the model may over-collect, mutate the host, or produce a confident answer that nobody can audit later.

For a login anomaly, I prefer a read-only evidence loop.

A practical first pass

Start with the narrow clue if you have one.

If the alert names a user:

oi login --user root -s 7d

If the alert names an IP address:

oi login --ip 203.0.113.44 -s 7d

If the alert is vague, start wider:

oi login -s 7d
oi scan -s 7d

The goal of the first pass is not to prove every detail. The goal is to build a timeline that a human responder can challenge.

For a suspicious SSH login, I want the initial report to answer five things.

1. Authentication pattern

Look for the difference between noise and access.

A server can receive thousands of failed SSH attempts from the internet. That is useful background, but it is not the same as a successful session. The first split should be:

failed attempts only
successful login after many failures
accepted key from an unusual source
login by an account that normally should not be interactive
root login where root SSH should be disabled

A good report should show the exact log lines or normalized evidence behind that assessment, not just say "suspicious login observed."

2. Account context

The username is only one part of the story.

For the involved account, collect read-only account facts:

UID and groups
shell
home directory
recent password or account metadata if available
sudo-related context
whether the account looks like a human, service, or automation identity

This helps separate a noisy brute-force event from a potentially meaningful access event.

3. Session and process context

If the login was successful, ask what was active around the same time.

Useful read-only checks include:

current sessions
process snapshot
parent/child process hints
network sockets
command history if available and appropriate
recent files in likely working directories

None of these alone prove compromise. Together, they can show whether the login became a shell, touched a web root, started a process, connected outbound, or did nothing observable.

4. Persistence and service changes

For the same time window, check persistence surfaces:

cron and timer entries
systemd services
shell startup files
recently modified files
unusual listeners
package changes
container changes if the host runs containers

The first pass should be explicit about gaps. For example: "auth logs show a successful login, but no matching persistence change was found in the collected window" is much more useful than a dramatic conclusion.

5. Reviewable output

The output should not be an opaque chat answer.

For a real handoff, I want a case folder that contains:

evidence.jsonl for normalized observations
commands.log for what was collected
report.json for structured findings
report.md for the human-readable narrative

This lets a second responder inspect the evidence, rerun missing checks, disagree with the conclusion, or attach the report to a ticket.

Why the AI boundary matters

An AI assistant is useful for correlation. It can connect login times, accounts, IPs, files, services, and network state faster than a tired human staring at separate terminals.

But during first-pass incident response, the assistant should not have authority to remediate by default.

It should not:

kill processes
delete files
disable accounts
restart services
block IPs
change firewall rules
install packages
upload or download tools

Those actions may be appropriate later, but they belong in an approved response step, not in evidence collection.

The safer pattern is: collect bounded evidence, write an auditable report, then let the responder decide what to do next.

Where Open Investigator fits

I maintain Open Investigator at Arvanta Cyber. It is an Apache-2.0 local AI incident investigation CLI for Linux and Windows hosts. The project is built around this read-only first-pass model: AI gets sealed investigation tools, not arbitrary remediation authority.

For login anomalies, WebShell clues, suspicious IPs, Java service issues, and vague server alerts, the point is to turn a loose signal into a reviewable case folder.

Project:
https://github.com/SEc-123/open-investigator

Overview:
https://www.arvantacyber.com/open-investigator/

Related read-only AI incident response guide:
https://www.arvantacyber.com/open-investigator/articles/local-ai-server-incident-response/

How to triage a suspected WebShell without giving AI a shell

Qimin Zhao — Fri, 29 May 2026 12:03:23 +0000

A suspected WebShell is awkward because the first clue is often weak.

You may have one odd request in an access log, one newly modified file under a web root, a process running as the web user, or an outbound connection that does not fit the service.

The dangerous move is to jump straight into cleanup. Before deleting files or restarting services, a responder needs a small evidence map:

what request or path started the suspicion
whether related files changed recently
whether the web user has unusual processes
whether those processes have network connections
whether persistence or scheduled tasks changed nearby
whether auth logs show a related login or privilege event
what evidence is still missing

That is the point where local, read-only AI can be useful.

Start from the web root, not a verdict

A practical first pass can start with the web root and recent time window:

oi web --root /var/www -s 7d

The goal is not to ask AI to decide whether the host is compromised. The goal is to collect enough context that a human can challenge the next step.

For a suspected WebShell, I would want the first-pass collector to look at:

recently changed files under the web root
suspicious script extensions or unexpected upload locations
web access/error log entries around those paths
requests with unusual parameters, encodings, or user agents
processes owned by the web service user
listening sockets and outbound connections
persistence files, services, cron entries, and recent auth activity

None of those require remediation authority.

Correlate weak clues

A single clue is noisy. A PHP file changed yesterday may be a normal deploy. A POST request to an upload directory may be normal application behavior. An outbound connection may belong to a legitimate integration.

The value comes from correlation.

For example:

A new file appears in an upload directory.
Web logs show a POST to that file shortly after creation.
A process owned by the web user opens an outbound connection.
The same time window shows a service or cron change.

That chain is not a final incident report, but it is much more useful than a vague alert.

Keep the AI boundary boring

If an AI investigation tool can run arbitrary shell on a production host, it is too easy for the model to cross from investigation into response.

For this workflow, I want the model to request sealed read-only checks instead of improvising commands:

web log checks
recent file checks
process snapshots
network snapshots
persistence snapshots
auth/account context
package and container context when relevant

The tool should log every command and every denial. It should write evidence separately from the summary, so a responder can reproduce or reject the conclusion.

What a useful output looks like

A useful first pass should produce a case folder, not just a paragraph.

The artifacts I want are:

evidence.jsonl for structured observations
commands.log for the audit trail
report.json for machine-readable handoff
report.md for human review

The report should say what was found, why it matters, what is missing, and what a human responder should verify next. It should not delete the suspected file, block the IP, kill the process, or restart the web service.

Where Open Investigator fits

I maintain Open Investigator at Arvanta Cyber. It is an Apache-2.0 local AI server investigation CLI for Linux and Windows hosts.

The WebShell use case is one of the scenarios it is designed for: start from a weak web clue, collect read-only host evidence, and produce a reviewable evidence bundle.

WebShell investigation page:
https://www.arvantacyber.com/open-investigator/webshell-investigation-tool/

Project overview:
https://www.arvantacyber.com/open-investigator/

GitHub:
https://github.com/SEc-123/open-investigator

If you do incident response, blue-team work, web operations, or SRE on Linux servers, the design question I care about is this: what evidence would you require before trusting an AI-assisted first pass on a suspected WebShell?

What safety boundary should an AI incident investigation tool have?

Qimin Zhao — Fri, 29 May 2026 11:01:16 +0000

Disclosure: I maintain Open Investigator at Arvanta Cyber. Open Investigator is Apache-2.0 open source.

AI can help incident responders move from a weak clue to a concrete evidence
plan. It can also become dangerous quickly if it is allowed to improvise on a
production host.

Open Investigator takes a narrow position: AI should start as a local,
read-only investigator.

Repository:

https://github.com/SEc-123/open-investigator

Relevant page:

https://www.arvantacyber.com/open-investigator/read-only-ai-server-investigation/

The problem

Incident response starts under uncertainty:

a suspicious IP appears in logs
a Java service looks strange
a WebShell may exist
root logged in at an unusual time
a server "looks wrong" but nobody has a full hypothesis

This is exactly where AI planning can help. The model can decide that the next
useful evidence is auth context, process context, recent files, web logs,
network state, persistence, or Java process metadata.

But the same uncertainty makes mutation risky. Before the team understands the
case, the AI should not delete files, restart services, kill processes, disable
accounts, or block IPs.

The boundary

Open Investigator gives the model sealed investigation tools:

oi_ioc_find
oi_auth_check
oi_acct_snap
oi_proc_snap
oi_net_snap
oi_per_snap
oi_svc_snap
oi_web_check
oi_java_check
oi_mem_check
oi_file_recent
oi_container_check
oi_hist_check
oi_linux_deep
oi_windows_deep
oi_pkg_check

In safe mode, the AI cannot call raw OS commands.

In investigator mode, it can request oi_ro_run, but that command path is
filtered by a read-only policy and logged. Commands that mutate the host are
blocked.

What this enables

The model can still do useful work:

start from an IP, user, path, process, web root, Java service, or vague clue
collect evidence across multiple host surfaces
branch based on observations
record evidence IDs and command audit entries
produce report.md and report.json
explain which evidence is missing

The point is not to replace a responder. The point is to shorten the first-pass
evidence collection loop while keeping every action reviewable.

What this refuses to do

Open Investigator does not:

isolate hosts
block IPs
kill suspicious processes
delete WebShells
disable users
restart services
change firewall rules
edit the registry
install agents
replace EDR, SIEM, or SOAR

Those are response actions, not first-pass investigation actions.

Java memory-shell example

Java investigations show why the boundary matters.

Default Java checks are low impact:

oi java -s 14d
oi mem -s 14d

They inspect process command lines, JVM options, -javaagent, -agentlib,
JDWP, Xbootclasspath, jps, jcmd VM.command_line, web logs, recent
Java/web file changes, and related process or network context.

Deeper JVM inspection is explicit:

oi mem -s 14d -m inv --java-deep

Heavy artifacts are separate approvals:

oi mem -s 14d -m inv --java-deep --heap-dump
oi mem -s 14d -m inv --java-deep --jfr-dump

Ordinary oi sh and AI oi_ro_run cannot bypass those gates to create heap or
JFR dumps.

A practical trust checklist

Before using any AI incident investigation tool on a real host, ask:

Can the AI mutate the host?
Can it run arbitrary shell?
Are commands and denials logged?
Are evidence records preserved separately from the summary?
Are heavy diagnostics explicit?
Does the report show evidence gaps?
Can another responder reproduce or challenge the findings?

If the answer is unclear, the tool is not ready for production triage.

Takeaway

AI incident response tooling should earn trust from the boundary inward. Start
with local evidence collection, sealed tools, audit logs, and explicit
non-goals. Add broader capabilities only when the team can reason about the
risk.

How to investigate a suspicious IP on a Linux server with read-only evidence

Qimin Zhao — Fri, 29 May 2026 10:40:11 +0000

Disclosure: I maintain Open Investigator at Arvanta Cyber. Open Investigator is Apache-2.0 open source.

When an alert starts with only an IP address, the first response question is not
"is the host compromised?" It is narrower:

Where did this IP appear, what changed around that time, and what evidence is
still missing?

Open Investigator is built for this first-pass loop. It runs locally on the
host, lets AI call sealed read-only investigation tools, and writes an auditable
case folder instead of giving the model raw shell access.

Repository:

https://github.com/SEc-123/open-investigator

Relevant page:

https://www.arvantacyber.com/open-investigator/local-ai-incident-response/

Start with the IP

Build the tool:

git clone https://github.com/SEc-123/open-investigator.git
cd open-investigator
cargo build --release

Run an IP-focused investigation:

./target/release/oi ip 1.2.3.4 -s 7d

This asks a practical set of questions:

Did the IP appear in auth logs?
Did it hit web access logs?
Is it connected now?
Is it tied to a listening service or process?
Did suspicious files, persistence entries, or account activity appear nearby?
Which evidence categories were unavailable because of permissions or platform differences?

Why this should be read-only

Early in triage, the responder often does not know whether the IP is an
attacker, scanner, customer, proxy, admin VPN, monitoring system, or false
positive.

That is why Open Investigator keeps the default boundary narrow:

no raw shell for the AI in safe mode
no host isolation
no IP blocking
no process killing
no file deletion
no account disabling
no firewall or registry changes

The output is evidence and a report. Remediation belongs in separate,
human-approved response systems.

What gets collected

For an IP investigation, useful evidence usually spans more than one log file:

IOC search across readable logs and text surfaces
authentication events and login anomalies
process and network context
services and persistence entries
web logs and recent web-root changes
package and container context when available
recent files and command history signals

Open Investigator records observations into:

.oi/cases/<case-id>/
  case.json
  evidence.jsonl
  commands.log
  report.json
  report.md

The report is not the source of truth by itself. The important property is that
the report can point back to evidence records and command audit entries.

Follow-up with a natural-language question

If the IP appears in web logs or auth logs, ask a focused follow-up:

./target/release/oi ask "Investigate 1.2.3.4 on this host. Focus on auth logs, nginx access logs, related processes, outbound connections, recent web-root changes, and persistence over the last 7 days." -s 7d

The AI investigator can branch from observations:

web hit -> suspicious paths -> recent files -> process context
failed login burst -> successful login -> account context -> shell history
active connection -> process owner -> service context -> persistence

That loop is the reason to use AI here. It can decide the next bounded evidence
request while staying inside the read-only tool catalog.

What a useful result looks like

A useful first-pass report should include:

where the IP appeared
timestamps and source files where possible
related users, processes, services, files, and network connections
severity and confidence for findings
evidence gaps and permission issues
recommended manual confirmation steps

It should not pretend that one scan proves absence of compromise.

When to use deeper mode

Open Investigator has an investigator mode for controlled read-only command
fallback:

./target/release/oi ask "Investigate 1.2.3.4 and explain any remaining evidence gaps." -s 7d -m inv

Even then, oi_ro_run is policy-filtered and audited. It blocks commands that
delete, modify, kill, restart, install, download, upload, edit registry, change
firewall state, change accounts, or execute interactive shells.

Use this only when the team accepts the broader read-only command surface.

Takeaway

A suspicious IP is a starting point, not a verdict. The useful first step is to
collect linked host evidence, preserve the audit trail, and produce a report
another responder can challenge.

Open Investigator tries to make that first step faster while keeping the AI
inside a local, read-only investigation boundary.

How I would use local read-only AI for first-pass server incident response

Qimin Zhao — Fri, 29 May 2026 10:05:52 +0000

Disclosure: I maintain Open Investigator at Arvanta Cyber.

Most server incident response does not start with a clean incident narrative. It starts with a weak clue:

one suspicious IP
a weird login
a possible WebShell
a Java service behaving strangely
a host that simply "looks wrong"

The risky part is jumping from that clue straight to remediation. Before killing processes, blocking IPs, deleting files, or restarting services, I want a local, reviewable evidence package.

The first-pass workflow I like

1. Search for the clue across local evidence

For an IP, that means auth logs, web access logs, reverse proxy logs, application logs, current network connections, and nearby timestamps.

2. Expand from evidence, not guesses

If the IP appears in web logs, look at paths, status codes, user agents, recent web-root changes, web-user processes, and outbound connections. If it appears in auth logs, look at failed and successful logins, account state, sudo activity, and shell history.

3. Keep the model inside a bounded tool catalog

The AI should not get raw production-changing authority. It can ask for investigation tools, but those tools should be read-only and audited.

4. Write artifacts a human can review

The output should not just be "the AI says this is compromised." I want:

evidence.jsonl
commands.log
report.json
report.md

That lets another responder challenge the conclusion, inspect evidence IDs, and continue the case.

Where Open Investigator fits

Open Investigator is my Apache-2.0 implementation of this pattern. It runs locally on Linux and Windows hosts, exposes sealed read-only investigation tools for auth, process, network, persistence, services, web logs, Java clues, recent files, containers, packages, and history, and then writes a case report.

Example:

oi ip 1.2.3.4 -s 7d

Or a broader first pass:

oi scan -s 7d

The boundary is deliberate. It investigates, but it does not isolate hosts, block IPs, kill processes, delete files, disable accounts, restart services, or change firewall/registry state.

Practical walkthrough:
https://www.arvantacyber.com/open-investigator/articles/local-ai-server-incident-response/

Open-source repo:
https://github.com/SEc-123/open-investigator

Product page:
https://www.arvantacyber.com/open-investigator/

I would be interested in feedback from incident responders, Linux admins, SREs, and blue-team engineers: what evidence would you require before trusting a first-pass AI-assisted investigation report?