Read the Blast Radius, Not the Badge: How to Vet an Agent-Marketplace Plugin Before You Install It

"Being Listed Is the Trust Signal" — and that is the problem with every agent marketplace.

For solo operators and small-team builders running an agent — Hermes, or any agent platform that has shipped or is shipping an extension store — who are about to browse a marketplace and install something in a few clicks, and who have been reading "listed," or the Official/Verified badge, as "vetted, therefore safe."

---

The result, up front

You can keep using the marketplace and still know what you said yes to. The thing that makes that possible is a six-question blast-radius review, run before you install — not after:

  • Surfaces.** What does it change — the model, the memory store, the command executor, the messaging apps, the desktop UI? A plugin that can change the model or the memory backend is the agent's identity, not a tool.
  • Disclosure.** What does the entry actually admit — network access, a local server or open port, credential or account inheritance, arbitrary code execution?
  • Provenance.** Which tier and which maintainer — official, verified, community? Remember: tier is provenance, not safety.
  • Capabilities.** Do the declared tools, hooks, and env vars match what it registers — and is there anything it needs that it did not declare?
  • Blast radius.** If this is buggy or malicious, what can it reach? It runs with your agent's full authority.
  • Install tier.** Which security-scan tier did it land in? In Hermes, "caution" installs without a prompt; only "dangerous" blocks.

The decision rule that falls out: install the least-capable thing that does the job — and if a prompt or a skill can do it, a plugin is a privilege grant you did not need. Be most suspicious of the extension that "does more than a prompt or a skill could," because that is exactly the one with the largest blast radius.

That is the whole reader outcome. The rest of this article is why it is the right check — why "listed" answers a different question than the one you think it does, why an agent plugin is close to a change of identity rather than an add-on, and why a prize-driven hackathon is a supply shock aimed at a human review gate. And it is careful about what the review does prove, because the mistake is easy to make in the other direction too.

---

The claim as it is usually stated

Here is the sentence, or the thought, that runs on nearly every small team that adopts an agent extension:

"It's in the marketplace — it's listed, or it's Official — so it's been vetted and it's safe."

Nous Research, which runs Hermes Agent, says a version of the quiet part out loud. Its plugin-catalog documentation states the trust model in one line: "The plugin catalog is a human-reviewed directory of Hermes plugins. Being listed is the trust signal: users install a catalog plugin by name, at the exact commit a maintainer read." (Nous Research — Submitting to the Plugin Catalog.)

And the marketplace this describes is real and growing. On November 4, 2026, Nous announced that "Plugins, connectors, and skills for Hermes Agent are now unified in a single marketplace so you can easily browse and extend your Hermes experience in a few clicks." (@NousResearch on X.) The storefront describes itself as "Built by the community, for the community," lists tiers — Official, Verified, Community — and, at fetch on November 6, showed 1,063 plugins. (Hermes Marketplace.) About two hours later, Nous launched a 7-day Plugin Hackathon with $20,000 in prizes and a line that ties the two together: "We'll list accepted entries in the new Hermes Marketplace, where every Hermes user can install them." (@NousResearch on X.)

So "it's listed" feels like an answer. The rest of this piece is about why it is the answer to a different question.

---

What the evidence actually says

1. The review verifies what a plugin *is*, not what it *does*

Read the admission rules next to that "being listed is the trust signal" line and the scope of the review becomes clear. It is a provenance-and-integrity gate, and the vendor is explicit that it is one:

  • "Human-merged gate. Entries are added only via a PR to the hermes-agent repository, reviewed and merged by a maintainer. There is no self-serve registry, no automated ingestion."
  • "Exact SHA pins are mandatory. Every entry pins a full 40-character commit SHA. Branches, tags, and short SHAs are rejected by the loader."
  • "No self-updating code. ... The exact SHA pin is the trust model; a self-updater lets an installed copy move to a commit nobody reviewed."
  • Declared capabilities "must match what the plugin actually registers at the pinned commit ... undeclared capability creep is treated as a security issue."
  • The install scanner "runs at admission ... dangerous fails the entry; caution findings appear as warnings in the CI log and the reviewer reads them before merging. In exchange, installs at the pinned SHA accept caution without a prompt (dangerous still blocks)."
  • "No runtime overrides of Hermes core."

(Submitting to the Plugin Catalog.)

Every one of those rules answers a question of the form is this the thing it claims to be? It is the artifact the author says it is, at the commit a maintainer read, with the capabilities it declared, and it will not move underneath you or override core. That is a real filter — materially stronger than a self-serve registry. It is also not a question about what the code does once it runs.

The same documentation concedes the gap in a single line. Of Desktop extensions it says: "A desktop/plugin.js runs in the Desktop renderer with the app's full authority (the loader isolates errors, not capabilities)." (Submitting to the Plugin Catalog.)

Being listed is the trust signal. And: the loader isolates errors, not capabilities. Both sentences are true, and they are in the same vendor's own docs. Together they are the whole problem with every agent marketplace: the badge tells you what the code is, not what it will do.

2. A plugin's blast radius is the agent's whole privilege set

The reason the gap matters more here than in, say, a browser theme is what a plugin can reach. Nous defines it directly, in the same post that launches the hackathon:

"A plugin can change anything from the model Hermes runs on, where it stores its memory, where it runs commands, which messaging apps it works in and what Hermes Desktop shows." (@NousResearch on X.)

That is not an add-on. It is the agent's identity and its infrastructure. The developer guide backs it with the extension surfaces a plugin can register: model and inference providers, memory backends, gateway platform adapters, computer-use drivers, secret-manager backends, web-search and browser backends, image/video generation backends, context-compression engines, and more. (Build a Hermes Plugin.)

Put those two together and the sentence "install a plugin" stops being a feature decision. It is a privilege grant wearing the costume of a feature decision — a grant of the agent's own authority, which on a personal agent is a lot: the model that answers, the memory that persists, the shell that executes, and the chat surface that reaches your contacts.

3. The marketplace's own disclosures show the surface — even on Official entries

You do not have to take this as abstract. The marketplace publishes disclosure fields per entry, and the Official ones already admit real exposure:

  • Blender (Official):** "tools execute arbitrary Python in Blender with your privileges ... and the add-on's local server on port 9876 has no password, so any program on this computer can use it while Blender is open."
  • Claude Subscription (Official):** "every turn is billed against your Claude subscription's Agent SDK allowance, and the provider inherits whatever account claude is logged into."

(Hermes Marketplace.)

Neither of these is a scandal — both are disclosed, both are the price of the useful thing. That is the point. "Official" is a provenance label, not a safety label. It means Nous maintains it, not that it is bounded. (Plugin Catalog, user guide.) An Official plugin can still open a passwordless local port; an Official plugin can still inherit a logged-in account. The disclosure told you; the badge did not.

4. The hackathon is a supply shock aimed at a human review gate

Now put the timing back in. The contest pays $20,000, runs seven days, and funnels "accepted entries" straight into "the new Hermes Marketplace, where every Hermes user can install them." And it tells builders what wins: "Judges score it on usefulness, reliability, polish and creativity, and they favor plugins that do more than a prompt or a skill could." (@NousResearch on X.)

That judging bar is the mechanism. "Do more than a prompt or a skill could" points builders toward exactly the extensions with the largest blast radius — the ones that touch the model, the executor, the messaging layer. It rewards maximum capability at precisely the moment least privilege is the safe default. Meanwhile the only filter is a maintainer reading a pull request, and Nous says it reviews "entries every few days." (@NousResearch on X.)

The claim here is narrow and is an inference, so label it as one: no source states how many entries are expected or how review capacity scales. The evidence is the prize pool, the 7-day window, the stated cadence, and the direct pipeline from contest to storefront. What that describes is a supply shock aimed at a human review gate — discovery and capability being maximized faster than a human review can be deepened. When that happens, the operator's own policy becomes the load-bearing control, because it is the only part of the chain that scales with the number of entries.

---

Where the claim is roughly right, and where it falls apart

Be fair to "it's listed, so it's vetted," because it is not stupid — it is incomplete.

Where it is roughly right:

  • The review is a real filter.** A human-merged PR gate, mandatory 40-character SHA pins, a no-self-updater rule, a declared-capabilities rule, a no-core-override rule, and an install scanner are genuine friction, and stronger than an uncurated registry. (Submitting to the Plugin Catalog.)
  • The tiers are worth using.* Official/Verified tell you who stands behind* a plugin — Nous maintains it, or the Nous team verified it comes from the company whose product it integrates. That is provenance, and provenance is useful. (Plugin Catalog, user guide.)
  • A pinned commit is the right instinct.** Locking to a reviewed SHA is exactly what you want. The catalog does it for you, and rejects branches, tags, and short SHAs — better than most ecosystems. (Submitting to the Plugin Catalog.)

Where it falls apart:

  • The badge answers a provenance question and you are asking a capability question.** "Listed" = "this is the artifact a maintainer read, at a reviewed commit, with the capabilities it declared." It is not "this is safe to run with my agent's authority." (Submitting to the Plugin Catalog.)
  • The review cannot bound runtime capability at all** — by the vendor's own words, "the loader isolates errors, not capabilities." (Submitting to the Plugin Catalog.)
  • The scan tier is not a safety tier.* "Caution" findings are read by the reviewer and then installed without a prompt* by everyone downstream; only "dangerous" blocks. (Submitting to the Plugin Catalog.)
  • "Listed" does not extend to the plugin's dependencies.** The same doc notes a plugin's python_dependencies / pyproject.toml "install under the plugin's policy (no age check)" — so Hermes's own 3-day release-age check does not cover a plugin's transitive supply chain; that is the author's to secure. (Submitting to the Plugin Catalog, admission rules.)

What the evidence does not prove — and the packet is explicit about this:

  • It does not show the marketplace is uncurated or negligent. The gate is real.
  • It does not show any specific plugin is malicious, and there is no public incident tying a listed Hermes catalog plugin to harm. Do not imply one.
  • It does not show listed plugins are riskier than unlisted ones — the opposite is true; the review is a filter. The claim is about what the label guarantees, not a ranking of risk.
  • It does not show Hermes plugins are uniquely risky. The mechanism — an extension inherits the host's privileges, so install is a privilege decision — is general to browser extensions, editor extensions, VS Code, MCP servers, and every agent platform that ships a store. Hermes is the case study, not the exception.

---

The better version of the claim

Stated the way it survives contact with the evidence:

"Listed" is a provenance claim about a reviewed commit, not a safety check. It tells you a plugin is the artifact a maintainer read, at a pinned SHA, with the capabilities it declared — not that it is safe to run, because the review cannot bound what the code does once it executes with your agent's authority. So run the capability question yourself, before you install: what may this extension change, and what is its blast radius?

That sentence keeps everything that is true about the marketplace — the gate, the pins, the tiers are real and worth using — and drops only the thing that was never true: that the badge did the capability review for you.

---

What changes if you act on it: the blast-radius review

Six questions, asked before install. None of them requires reading source code, and each one maps to something the catalog or the entry already publishes.

  • Surfaces — what does it change?** Model, memory, executor, messaging, desktop. A plugin that registers a model provider or a memory backend is not a tool; it is a change to the agent's identity. (Build a Hermes Plugin.)
  • Disclosure — what does the entry admit?** Look for the words that cost you something: network access, a local server or port, credential/account inheritance, arbitrary code execution. Blender and Claude Subscription are the worked examples — both Official, both disclosed, both a real surface. (Hermes Marketplace.)
  • Provenance — which tier, which maintainer?** Official is Nous-maintained; Verified is Nous-verified to come from the company it integrates; Community is everything else. Use it to decide who stands behind the artifact — and remember it is not a safety tier. (Plugin Catalog, user guide.)
  • Capabilities — declared vs. registered.** Does what it registers at the pinned commit match what it declared? Undeclared capability creep is the failure mode the catalog itself polices, so check the declared tools/hooks/env vars against what you were told. (Submitting to the Plugin Catalog.)
  • Blast radius — if it is buggy or malicious, what can it reach?** Because it runs with the agent's full authority, the honest answer is "the agent's whole privilege set" — the model, the memory, the shell, the messaging apps. That is the number to rank plugins by. (@NousResearch on X; Submitting to the Plugin Catalog.)
  • Install tier — which scan tier did it land in?** "Caution" installs without a prompt; only "dangerous" blocks. (Submitting to the Plugin Catalog.)

The decision rule. Install the least-capable thing that does the job. If a prompt or a skill can do it, a plugin is a privilege grant you did not need — the catalog's own framing is that the marketplace adds "discovery and a review layer" on top of a plugin system that already exists. (Plugin Catalog, user guide.) And be most suspicious of the extension that "does more than a prompt or a skill could" — that is the vendor's own description of what the hackathon judges favor, and it is a precise description of the largest blast radius. (@NousResearch on X.)

Worked example, kept small. You want the marketplace's Blender plugin to let the agent drive 3D renders. Run the review. Surfaces: it runs Python inside Blender — a tool surface, not the agent's identity, so far so contained. Disclosure: "arbitrary Python in Blender with your privileges" and "a local server on port 9876 with] no password, so any program on this computer can use it while Blender is open." Blast radius: the passwordless port is the one that reaches beyond Blender — anything on the machine can talk to it while Blender is open. Decision rule: keep the plugin if the job needs it, but treat the open port as the thing to bound — a firewall rule, or don't run it on a machine where "any program on this computer" is a real set. Same plugin, same convenience; you now know the one line in the disclosure that decides your exposure, and it was never the badge. ([Hermes Marketplace.)

---

Where you will get stuck

  • "So the marketplace is broken."** No — and this is the overcorrection the whole piece is written against. The human-merged gate, the exact SHA pins, the no-self-updater rule and the declared-capabilities rule are real filters, stronger than a self-serve registry. The claim is narrower: "listed" is a provenance claim about a reviewed commit, not a capability guarantee. (Submitting to the Plugin Catalog.)
  • "It says Official, so it must be safe."** Tier is provenance. Official = Nous maintains it; Verified = Nous verified the source company. Neither bounds the plugin. An Official plugin opened a passwordless local port; an Official plugin inherits a logged-in account. (Hermes Marketplace; Plugin Catalog, user guide.)
  • "The install scanner cleared it, so I'm fine."** Only "dangerous" blocks; "caution" installs without a prompt after a reviewer reads the log. A clean install prompt is not a safety verdict. (Submitting to the Plugin Catalog.)
  • "I'll just check the plugin's dependencies myself."** The catalog's age check covers Hermes's own dependencies, not the plugin's — "a plugin's python_dependencies / pyproject.toml install under the plugin's policy (no age check)." That supply chain is the author's to secure, not the catalog's. (Submitting to the Plugin Catalog, admission rules.)
  • "This is a Hermes-specific problem."** It is not. The mechanism generalizes to every extension store. Hermes is the sharpest example only because the trust model is written down and the blast radius is stated plainly — which is what makes it teachable. (Build a Hermes Plugin.)
  • "While I'm at it, isn't this just gateway permissions?"* Keep the distinction. An open Hermes issue asks for role-based gateway tiers — "who may use which tools on a shared bot" — where authorization is currently binary (fully authorized, or blocked). That is a different* ask: who may use the agent, not what a plugin may reach. They are adjacent, and conflating them is the easy mistake. (NousResearch/hermes-agent issue #527.)

---

The compressed ending

  • A listing is a provenance claim, not a safety check.** "Being listed is the trust signal" tells you the plugin is the artifact a maintainer read, at the exact commit, with the capabilities it declared. It does not tell you what the code will do. (Submitting to the Plugin Catalog.)
  • A plugin is the agent's identity, not an add-on.** It can change the model, the memory, the executor, the messaging apps, and the desktop — and "the loader isolates errors, not capabilities." So install is a privilege grant. (@NousResearch on X; Submitting to the Plugin Catalog.)
  • Tier is provenance, not safety.** Official and Verified tell you who stands behind it. The disclosure tells you what you are taking on. Read the disclosure. (Hermes Marketplace.)
  • A prize-driven hackathon is a supply shock against a human gate.** A $20k, 7-day contest that favors plugins which "do more than a prompt or a skill could" and pipes accepted entries straight into the storefront maximizes capability exactly where least privilege is safest. (@NousResearch on X.)

None of this is an argument to distrust the marketplace or to stop installing plugins. It is an argument to stop reading "listed" as the answer, and to run the capability question yourself — six questions, asked before you click.

Ask what the extension may change before you ask whether it is listed. Prefer the least-capable plugin. And when the badge says "listed," remember what it actually said: this is the commit a maintainer read.

---

Sources

  • @NousResearch on X — the Hermes Marketplace launch (Nov 4 2026): "Plugins, connectors, and skills for Hermes Agent are now unified in a single marketplace ... in a few clicks": <https://x.com/NousResearch/status/2118058453415371119>
  • @NousResearch on X — the Plugin Hackathon (Nov 4 2026): the plugin-blast-radius definition ("A plugin can change anything from the model Hermes runs on ..."), "$20,000 in cash prizes," 7-day window, "We'll list accepted entries in the new Hermes Marketplace, where every Hermes user can install them," and "favor plugins that do more than a prompt or a skill could": <https://x.com/NousResearch/status/2118094256438936062>
  • Nous Research — "Submitting to the Plugin Catalog" (developer guide) — "Being listed is the trust signal ..."; the human-merged gate; mandatory 40-character SHA pins; no-self-updater rule; declared-capabilities rule; "dangerous fails the entry; caution findings appear as warnings ... installs at the pinned SHA accept caution without a prompt"; "a desktop/plugin.js runs in the Desktop renderer with the app's full authority (the loader isolates errors, not capabilities)"; and the dependency policy: <https://hermes-agent.nousresearch.com/docs/developer-guide/plugins/catalog-submission> (admission-rules anchor: <https://hermes-agent.nousresearch.com/docs/developer-guide/plugins/catalog-submission#admission-rules>)
  • Nous Research — "Plugin Catalog" (user guide) — install-by-name, tier meanings (official / verified / community), and the entry schema (name, description, repo, sha, capabilities, platforms): <https://hermes-agent.nousresearch.com/docs/user-guide/features/plugin-catalog>
  • Nous Research — "Build a Hermes Plugin" (developer guide) — the extension surfaces that constitute the blast radius (model/inference providers, memory backends, gateway platform adapters, computer-use drivers, secret-manager backends, web-search/browser backends, and more): <https://hermes-agent.nousresearch.com/docs/developer-guide/plugins>
  • Hermes Marketplace — the storefront: "Built by the community, for the community," 1,063 plugins at fetch (Nov 6 2026), Official/Verified/Community tiers, and the per-entry disclosures (Blender: "arbitrary Python in Blender with your privileges" and a passwordless local server on port 9876; Claude Subscription: "inherits whatever account claude is logged into"): <https://hermes-agent.nousresearch.com/marketplace>
  • Nous Research — "Plugin Catalog" browse page — the visual shelf, tier filters, capability chips and copyable install commands: <https://hermes-agent.nousresearch.com/docs/plugins>
  • NousResearch/hermes-agent issue #527 — gateway role/permission tiers (Owner/Admin/User/Guest): a related but DISTINCT ask about who may use which tools on a shared bot, not a plugin-capability gate: <https://github.com/NousResearch/hermes-agent/issues/527>
  • @MichaelGannotti on X (Nov 5 2026, secondary) — the "about two hours later" ordering of the marketplace launch and the hackathon: <https://x.com/MichaelGannotti/status/2118315279406989571>

Editor flags before publish (do not ship without re-checking):

  • Snapshot.** The 1,063-plugin count, the Official/Verified/Community tiers, the exact admission rules, and the Blender/Claude Subscription disclosures are an early-November-2026 snapshot of a fast-moving catalog ("Updated 2 hours ago"). Write and date the piece "as of early November 2026."
  • Not claimed.* The marketplace is not* uncurated — the human-merged gate, exact SHA pins and no-self-updater rule are real filters, stronger than a self-serve registry. Do not say it is insecure, and do not imply any specific listed plugin is unsafe: no public incident ties a listed Hermes catalog plugin to harm.
  • Inference, labelled.** The hackathon's effect on review load is an inference from the prize pool, the 7-day window, "we review entries every few days," and the contest-to-storefront pipeline. No source states an expected entry count or how review capacity scales. The draft frames it as a supply shock the gate must absorb, not a measured backlog.
  • Decay.** Low for the tension and the mechanism (a listing is a provenance claim; an extension's blast radius is the host's privilege set) — it generalizes to every agent/editor/browser store. Low-to-medium for the anchors (the count, tiers, exact rules, disclosures). Medium for the hackathon date. The durable claim is the trust model, not the contest.
  • Distinct from agent-plugin-trust (Oct 9).* That piece owns the act of installing (extension = untrusted code with your privileges; verify provenance, inspect, pin AND verify, kill auto-update, contain the agent). This piece owns the storefront's trust claim ("being listed is the trust signal") and the blast radius* (a plugin is the agent's identity, not an add-on), plus the hackathon as a supply shock. If a revision drifts into "here is how to vet an install," it has become a re-argument — send it back.
  • Not conflated with issue #527.** #527 is gateway RBAC (who may use the agent), not a plugin-capability gate. The draft labels the distinction.

---

X entryway list (from the approved angle)

Distribution entryways named in the angle brief. Hooks are not yet written as posts — this names each post's type, the one claim or mechanism it carries, and whether it links.

  • Hook type: surprising proof.* Nous's own catalog doc says "Being listed is the trust signal" — and the same doc says a desktop plugin "runs in the Desktop renderer with the app's full authority (the loader isolates errors, not capabilities)." Both sentences are true, and together they are the whole problem with every agent marketplace: the badge tells you what the code is, not what it will do*. → Links to article (the pair of vendor sentences is the entry; the article develops why the badge answers a different question and gives the check).
  • Hook type: mechanism.** A Hermes plugin "can change anything from the model Hermes runs on, where it stores its memory, where it runs commands, which messaging apps it works in and what Hermes Desktop shows." That is not an add-on — it is the agent's identity and infrastructure. So "install a plugin" is a privilege grant wearing the costume of a feature decision. → Links to article (the mechanism stands alone; the article is the least-capability rule it forces).
  • Hook type: workflow.** Run the blast-radius review before you install any agent extension: (1) which surfaces does it change (model/memory/executor/messaging/desktop); (2) what does the disclosure admit (network, local port, credentials, arbitrary code); (3) tier + maintainer (provenance, not safety); (4) declared capabilities vs what it registers; (5) blast radius if it is buggy or malicious; (6) install-scan tier — "caution" installs silently. Prefer the least-capable plugin, or a prompt/skill when they suffice. → Links to article (the checklist is the actionable unit; the article is why each line holds and the worked example).
  • Hook type: risk.** A $20,000, 7-day hackathon whose accepted entries get listed for every user is a supply shock aimed at a human review gate — and the judging bar ("favor plugins that do more than a prompt or a skill could") rewards maximum capability at exactly the moment least privilege is the safe default. → Links to article (names the incentive mechanism in one line; the article shows why the operator's own policy becomes the load-bearing control).
  • Hook type: result.** "Official" is a provenance label, not a safety label. The marketplace's own disclosures: an Official Blender plugin runs arbitrary Python with your privileges and opens a local server on port 9876 with no password; an Official Claude Subscription plugin "inherits whatever account claude is logged into." Read the disclosure, not the badge. → Links to article (the disclosure-not-badge reframe is the post; the article carries the full review and the decision rule).

Hook-type map: 1 = surprising proof; 2 = mechanism; 3 = workflow; 4 = risk; 5 = result. All five link, and each link is a bonus — every post carries a claim that stands alone. These are the five entryways the angle brief named; none was invented and none repeats another's hook.