Hermes Agent gains code vulnerability scanning with an official Security plugin

Anyone who has tried handing code to an LLM with the instruction “find vulnerabilities” knows how it ends. The model produces a long list of “potential issues,” half of which are invented or unreachable from a real entry point. Reviewing that report takes longer than finding the bugs yourself. Nous Research is trying to solve precisely this problem: Hermes Agent now has an official Security plugin, written by @mark_s.

What we know about how the plugin works

According to the announcement, Hermes starts with reconnaissance rather than jumping straight into bug hunting. The agent first maps what an attacker can access in the project and which inputs the code trusts. This is standard threat-modeling logic. A vulnerability in a function that cannot be reached from outside and the same flaw in a public request handler carry different financial consequences.

The code is then divided among parallel subagents. Each examines its own section, so a large repository is not constrained by a single model’s context window. Judging by the announcement, the third step is the most important: the agent checks every finding against the code before including it in the report. The end of the post is cut off, so the source does not establish exactly what happens after that verification.

Why the approach makes sense

Imagine a typical web service. An endpoint accepts a filename from a user and reads the file from disk. A simplistic review prompt might flag a dozen occurrences of open across different files. The workflow described in the announcement takes a different approach. It first identifies the parameter as coming from untrusted input. The agent then traces where it goes and only afterward reports a possible path traversal vulnerability. The finding is tied to a specific data flow, making it easier for a human to verify.

Parallel subagents address an engineering challenge here. Auditing a monolith sequentially takes a long time and quickly fills the context window. Splitting the work into sections speeds up the process and reduces the risk of the model losing track of details midway through.

What we still do not know

The post is short, and its reach is modest: around 15,000 views. That makes it important not to read more into it than the evidence supports. The source provides no figures on false-positive rates, supported languages, the cost of running the plugin on a large repository, or comparisons with static analyzers. It also offers no examples of actual vulnerabilities found. For now, this is a stated approach, not a demonstrated result.

There is also a risk common to all auditing agents: verification “against the code” is still performed by a model. It can confidently confirm an incorrect finding or miss a real one. Such a tool does not replace SAST, penetration testing, or human review.

What to do in practice

If you already use Hermes Agent, try the plugin on a small service whose weak spots you know. Seed it with a couple of known issues beforehand and see whether the agent finds them and how much noise it adds. This is the fastest way to assess its quality without taking the announcement on trust.

For teams without a dedicated security specialist, a sensible role for this kind of tool is an initial pass before a release or a full audit. It should catch obvious issues and generate hypotheses with evidence showing where they came from. For product managers and founders, the takeaway is straightforward: agent-based security reviewers are moving from generating lists toward a workflow of “reconnaissance, division of work, verification.” Those three capabilities are what competing solutions should be compared on.

The arrival of an official plugin from the Nous team also signals something else. The ecosystem around Hermes Agent is growing through extensions, as well as through the model itself. Independent tests will show how useful this particular plugin is, rather than a post on X.