Start with the IP
Why this should be read-only
What gets collected
Follow-up with a natural-language question
What a useful result looks like
When to use deeper mode
Takeaway 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: Open Investigator is built for this first-pass loop. It runs locally on thehost, lets AI call sealed read-only investigation tools, and writes an auditablecase folder instead of giving the model raw shell access. Run an IP-focused investigation: This asks a practical set of questions: Early in triage, the responder often does not know whether the IP is anattacker, scanner, customer, proxy, admin VPN, monitoring system, or falsepositive. That is why Open Investigator keeps the default boundary narrow: The output is evidence and a report. Remediation belongs in separate,human-approved response systems. For an IP investigation, useful evidence usually spans more than one log file: Open Investigator records observations into: The report is not the source of truth by itself. The important property is thatthe report can point back to evidence records and command audit entries. If the IP appears in web logs or auth logs, ask a focused follow-up: The AI investigator can branch from observations: That loop is the reason to use AI here. It can decide the next bounded evidencerequest while staying inside the read-only tool catalog. A useful first-pass report should include: It should not pretend that one scan proves absence of compromise. Open Investigator has an investigator mode for controlled read-only commandfallback: Even then, oi_ro_run is policy-filtered and audited. It blocks commands thatdelete, modify, kill, restart, install, download, upload, edit registry, changefirewall state, change accounts, or execute interactive shells. Use this only when the team accepts the broader read-only command surface. A suspicious IP is a starting point, not a verdict. The useful first step is tocollect linked host evidence, preserve the audit trail, and produce a reportanother responder can challenge. Open Investigator tries to make that first step faster while keeping the AI
inside a local, read-only investigation boundary. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse
Where did this IP appear, what changed around that time, and what evidence is
still missing?
Where did this IP appear, what changed around that time, and what evidence is
still missing?
Where did this IP appear, what changed around that time, and what evidence is
still missing?
https://github.com/SEc-123/open-investigator
https://github.com/SEc-123/open-investigator
https://github.com/SEc-123/open-investigator
https://www.arvantacyber.com/open-investigator/local-ai-incident-response/
https://www.arvantacyber.com/open-investigator/local-ai-incident-response/
https://www.arvantacyber.com/open-investigator/local-ai-incident-response/
git clone https://github.com/SEc-123/open-investigator.git
cd open-investigator
cargo build --release
git clone https://github.com/SEc-123/open-investigator.git
cd open-investigator
cargo build --release
git clone https://github.com/SEc-123/open-investigator.git
cd open-investigator
cargo build --release
./target/release/oi ip 1.2.3.4 -s 7d
./target/release/oi ip 1.2.3.4 -s 7d
./target/release/oi ip 1.2.3.4 -s 7d
.oi/cases/<case-id>/ case.json evidence.jsonl commands.log report.json report.md
.oi/cases/<case-id>/ case.json evidence.jsonl commands.log report.json report.md
.oi/cases/<case-id>/ case.json evidence.jsonl commands.log report.json report.md
./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
./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
./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
./target/release/oi ask "Investigate 1.2.3.4 and explain any remaining evidence gaps." -s 7d -m inv
./target/release/oi ask "Investigate 1.2.3.4 and explain any remaining evidence gaps." -s 7d -m inv
./target/release/oi ask "Investigate 1.2.3.4 and explain any remaining evidence gaps." -s 7d -m inv - 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? - 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 - 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 - web hit -> suspicious paths -> recent files -> process context
- failed login burst -> successful login -> account context -> shell history
- active connection -> process owner -> service context -> persistence - 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
