Open Investigator · AI incident tool safety
Give AI an investigation toolbox, not production-changing authority.
AI can help responders move from weak clues to a concrete evidence plan. It also becomes risky quickly if it can improvise on a production host.
Why it matters
Use this article as a discussion starter for teams evaluating AI-assisted incident response boundaries.
Why the boundary matters
Incident response starts under uncertainty: a suspicious IP, a Java service anomaly, a possible WebShell, unusual root login, or a server that simply looks wrong. Before the team understands the case, the AI should not remediate.
What sealed tools allow
Open Investigator exposes named tools for IOC search, authentication, accounts, process, network, persistence, services, web logs, Java, memory clues, recent files, containers, packages, Linux, Windows, and command history.
What it refuses to do
The product does not isolate hosts, block IPs, kill processes, delete files, disable users, restart services, change firewall rules, edit the registry, install agents, or replace EDR, SIEM, or SOAR.
A practical trust checklist
Before using any AI incident investigation tool on a real host, ask whether the AI can mutate the host, whether arbitrary shell is exposed, whether denials are logged, whether evidence records are preserved, and whether another responder can reproduce the findings.
Try it
git clone https://github.com/SEc-123/open-investigator.git
cd open-investigator
cargo build --release
./target/release/oi scan -s 7dOpen Investigator writes case artifacts such as evidence.jsonl, commands.log, report.json, and report.md so another responder can review the investigation path.