NeuroSploit 4.4 keeps rejected AI findings instead of throwing them away

An AI security tool’s rejected finding can still be worth inspecting. NeuroSploit’s new 4.4.0 release says findings rejected by its model-voting stage are now retained with review_status: "rejected", rather than silently discarded. The web console exposes candidate findings with status indicators, while rejected.jsonl remains available for compatibility.

For security reviewers, the useful change is visibility into what the system considered and rejected. A retained candidate is not a confirmed vulnerability, and a rejection is not independent proof that a target is safe. The release makes that review history available without promoting rejected claims into established results.

Choose agents from the observed target

NeuroSploit is a standalone Rust harness, not a new language model or a plugin limited to one coding assistant. Its maintainers describe a pipeline that gathers reconnaissance, selects specialist agents, checks evidence and produces reports through one CLI engine, with a terminal interface and web console on top.

Version 4.4 adds selection rules that penalize agents for technologies not detected during reconnaissance and adjust scoring to the observed stack. The release also describes broader surface detection and more context for the model selecting agents. These changes aim to spend assessment effort on relevant checks; they are not evidence of a measured increase in vulnerability detection.

Change MCP tools while a run continues

The other practical addition is MCP hot reload. The release says NeuroSploit watches mcp.servers.json, allowing servers to be added or removed without stopping the engagement. Each agent receives a fresh CLI subprocess that reads its MCP configuration from disk. The described behavior should not be read as instantly replacing a tool inside every already-running subprocess.

Maintainers also list reference methodology files that can be injected into agent prompts and four autonomy levels controlling tool installation, attack creativity and guardrail strictness. These are configurable operating choices, rather than a guarantee that every provider or CLI enforces identical permissions.

Existing credentials, separate model costs

The documented installation route supports Linux, macOS and Windows, installs Rust if needed and builds the executable. Users can supply provider API keys or use a supported local CLI that is already installed and signed in, including Claude Code, Codex, Gemini or Grok. The harness is MIT-licensed; provider billing, subscription quotas and assessment-tool dependencies remain separate.

The guide also documents local model backends. Using a remote model or a CLI connected to one can send assessment context to that provider, so running the harness locally does not by itself make the entire workflow offline. It is intended for authorized targets, and the tutorial describes explicit scope and authorization controls.

The tagged tutorial still carries a 4.3.1 heading. We used the dated GitHub 4.4.0 release for the new behavior and the tagged guides for setup context. AITrending has not run a security assessment or independently validated the project’s broader claims about eliminating invented findings. The concrete news is a more inspectable assessment workflow, with rejected output preserved and tool configuration adjustable during a run.