Hermes Agent releases a security plugin with exploitability checks

• Hermes Agent now reviews code for attacker-reachable security bugs, using threat modeling, parallel subagents, and candidate checks described in NousResearch's announcement.
• Optional reproduction tests run in a temporary repository copy with user-level permissions and no sandbox isolation, according to the linked plugin documentation.
• Reports retain rejected candidates alongside findings and export to SARIF, as NousResearch explained, preserving more than a list of suspected bugs.

The nicest detail is the negative-control requirement: both the reproduction and a matching negative test must behave as expected before a finding earns “Confirmed by test.” The agent cannot authorize its own live-app testing. Standard reviews also have a 90-chunk budget, roughly 360,000 lines.

Security is an official Hermes plugin, built by @mark_s using his security-review experience. The installation requirements are Hermes 0.21.5 or later and Python 3.11 or later.

After installation and a Hermes restart, it exposes three entry points:

• Chat: request a security review; /security provides scan-management commands.
• CLI: hermes security-review or python -m hermes_security.
• Desktop: a Security page, enabled separately under Capabilities → Plugins.

Repository paths refer to the machine running Hermes. A remotely installed backend plugin alone leaves its Desktop page unavailable; the Desktop install dialog fetches the page too.

Hermes follows three stages in its documented review workflow:

1. Threat model: identify attacker-reachable surfaces and trusted inputs.
2. Parallel review: divide code by folder into chunks of about 4,000 lines. Up to 10 reviewers run concurrently, and a cross-scope reviewer examines entry points and trust boundaries.
3. Candidate checks: check suspected findings against the code and trace whether an attacker can reach the vulnerable behavior.

The scan defaults to the current chat model. Reviewer routing through the advanced-delegation plugin is also supported, as Teknium confirmed; the Desktop controls expose model routes or Hermes profiles for subagents.

Standard and deep scans allocate substantially different reading budgets:

• Standard scope: production source, configuration, CI, infrastructure as code, and migrations. Tests, fixtures, docs, examples, translations, generated files, assets, and lockfiles are excluded unless they contain a committed secret.
• Within 90 chunks: all production code in scope is read.
• Beyond 90 chunks: files are ranked by security-relevant behavior, including request input, shell commands, SQL, deserialization, authentication, and webhooks. The highest-risk files consume the available budget first.
• Deep scope: three independent repository passes by default, including categories standard scans skip, but still subject to a fixed budget.
• General exclusions: vendored code, symlinks, special files, and files larger than 8 MB are skipped and listed in the report.

Unreviewed code and reviewers that return no result remain visible as coverage gaps. Agentic review still needs strong prompting from security experts, TheWholeDaisy argued.

“Run tests to confirm findings” adds an execution step rather than merely asking the model for greater confidence:

• The agent writes small reproductions and executes them in a temporary repository copy using the normal toolchain.
• “Confirmed by test” requires a passing reproduction and a matching negative test behaving as expected.
• A test that never executes is recorded as NOT_RUN, providing no proof either way.
• Tests run as the current OS user. Credential-looking environment variables are removed, but execution has no sandbox isolation.

Testing a running application requires a separate, human-issued grant for that scan:

• One exact origin.
• One hour.
• At most 200 requests.
• Redirects restricted to the same site.
• Stop revokes permission early.

The agent's tools cannot issue that grant.

Hermes preserves the review trail in its findings and reports:

• Findings quote exact code from the scanned snapshot and retain a record of code actually read.
• Rejected and inconclusive candidates remain available, including why they were ruled out.
• Proof gaps and counter-evidence appear separately from severity.
• Suggested patches are displayed for reading only; the plugin never applies them.
• Exports support Markdown, JSON, CSV, and SARIF.

Finished reports are sealed against later triage edits. Repository text is treated as data rather than agent instructions, Git hooks and filters do not run, and detected secrets are represented by type, location, and a one-way fingerprint rather than their value.

The review also includes a conventional scanner step, detailed in the dependency-check documentation:

• Scanner download: the first scan fetches a pinned osv-scanner release from GitHub, about 55 MB, and rejects it if its SHA-256 differs from the pin.
• External lookups: package names and versions go to api.osv.dev, with api.deps.dev used for manifests lacking lockfiles. Declared runtime versions are checked against endoflife.date.
• Advisory grouping: dependency advisories become one finding rated at the worst included severity. A separate finding requires the review to establish that application code reaches vulnerable behavior.
• Disable switch: HERMES_SECURITY_DEPENDENCY_CHECK=off turns off the dependency check.

Scan data and reports stay in the active Hermes profile, while the configured model provider receives the code under review. Nothing is automatically uploaded to a findings service or ticket system.