Nous adds evidence checks and bounded testing to Hermes Security Nous adds evidence checks and bounded testing to Hermes Security

The review starts with reachability

Nous describes a process that first identifies what an attacker can reach and which inputs the application trusts. Parallel agents then inspect separate parts of the repository. Candidate issues go through code checks and attack-path analysis before the report is finished. The announcement also describes optional small reproductions in a temporary repository copy. That sequence puts a question between discovery and reporting: can the suspected behavior actually be reached? For a developer reviewing the output, the useful artifact is the chain of evidence connecting an entry point to the alleged problem.

A finding carries its proof state

The implementation contract defines separate states for candidates, source-supported findings, runtime-confirmed findings, rejected findings and inconclusive results. Severity and confidence are separate fields. Promotion to runtime-confirmed requires a successful validation receipt with paired positive and negative controls. An unrun test remains marked as not run. These distinctions preserve a difference that can disappear in a polished security report: reading suspicious code is not the same event as reproducing its behavior. They also let a reviewer retain an unresolved candidate without presenting it as demonstrated exploitation.

Execution needs a separate decision

The marketplace describes three review modes and a separate permission for testing a running application. A per-scan grant covers one origin for one hour, with a ceiling of 200 requests. Agent tools cannot issue that grant themselves. Local test confirmation is a different option: repository code runs under the user’s identity in a temporary copy after credential-like environment variables are removed. The publisher explicitly says that copy is not a sandbox. Choosing tests therefore changes the operation from reading code to executing code, even when the original checkout remains untouched.

Coverage stays visible

The README says standard review divides code into chunks of roughly 4,000 lines and permits up to ten concurrent reviewers. Its normal production-code budget covers 90 chunks; larger repositories receive risk-based prioritization. Skipped files and unfinished review work remain visible in the report. This makes a scan’s scope part of its result. A report from a small change and one from a whole repository can contain the same number of findings while representing very different amounts of inspection. The documented export formats allow that evidence to travel into other review tools.

Local reports still have a data path

The marketplace separates stored scan data from model processing. Reports remain in the active Hermes profile, while the configured model provider receives the code being reviewed. The dependency check also sends package information to advisory services and downloads a pinned scanner with a hash check. These are distinct destinations, each serving a different step of the workflow. For a team deciding whether to enable the plugin, the relevant boundary includes both code disclosure and execution permission. Keeping the report on disk describes storage; it does not describe every network interaction.