Approval Gates: hermes-jev-approvals and jev-security-scan

An approval gate only works if it's fast enough to actually run on every decision, not just the ones someone remembers to check. Two projects apply Jev's typed-output design to two different approval moments: whether an agent's next command should execute, and whether an Agent Skill or MCP configuration is safe to install in the first place. Neither is a large project — 14 and 10 stars respectively — and both authors describe their own work as early-stage. What's worth reading closely is how each one structures the decision itself, because that structure is the reusable part, independent of how mature the code is.

For the wider approval and evaluation pattern, see jevals: an evals platform built around typed judges and how to evaluate Jev projects honestly.

Key Takeaways

• hermes-jev-approvals replaces a prose-parsing reviewer with six parallel typed questions, feeding a deterministic decision tree that outputs APPROVE, DENY, or ESCALATE.
• Its own benchmark claims 8.7x faster and 4.4x fewer prompts, measured on 153 real commands — a real number, from a small sample, not independently retested.
• jev-security-scan screens Agent Skills, MCP configs, and source code across nine risk categories before you install or run them, combining local static checks with Jev's semantic analysis.
• Both tools require dual-threshold confidence before flagging anything as high risk — jev-security-scan requires paired probabilities of 0.85 or higher plus contextual confirmation.
• Both authors are explicit that neither tool is a guarantee. hermes-jev-approvals calls itself "a reviewer, not a sandbox"; jev-security-scan calls itself "an auxiliary review tool, not security certification."

hermes-jev-approvals: six questions instead of one paragraph

hermes-jev-approvals (MIT, 14 stars as of September 2026, /skills/hermes-jev-approvals-anpicasso) is a plugin for Hermes Agent, a framework where commands that need review get sent to an auxiliary model for one of three verdicts: approve, deny, or escalate to the user. By default that auxiliary reviewer writes prose the framework has to parse. This plugin replaces it for the auxiliary.approval task specifically, when approvals.mode: smart is set.

Instead of one free-text judgment, it asks Jev six parallel typed questions: an overall verdict (a choice), policy_allows (a probability), blast_radius (a score), self_advocating (a probability — is the command trying to talk its way past review), reads_secrets (a probability), and sends_outbound (a probability). A deterministic decision tree then converts those six answers into a final APPROVE, DENY, or ESCALATE, rather than trusting the model to state a verdict directly.

The project's own benchmark reports being 8.7x faster and requiring 4.4x fewer prompts than the prose-based reviewer it replaces, measured on 153 real commands. That's a specific, checkable number — and also a small sample from a single author's test run, not independently reproduced here. The README is direct about its own limits: this is "a reviewer, not a sandbox," and a truncated command is never auto-approved regardless of how the six questions score. It requires Python 3.10+ and has no third-party dependencies, which keeps its own attack surface small.

jev-security-scan: screening before install, not after

jev-security-scan (MIT, 10 stars, /skills/jev-security-scan-win4r) addresses a different moment entirely — before you install an Agent Skill or an MCP server, or run unfamiliar source code, not while an agent is already mid-task. It runs in two modes. Local mode does offline static checks with no network calls. Jev mode adds semantic analysis: sanitized code snippets go to TypeSafe's API, screened against nine independent risk categories, with a verification pass that re-questions anything flagged before it's reported.

The scope is broad by design. It looks for prompt injection and hidden directives inside SKILL.md files and their scripts, tool-description poisoning and unexpected credential access in MCP server source, suspicious startup commands or remote addresses in MCP config manifests (JSON, TOML, YAML), install hooks and download-and-execute patterns for supply-chain risk, and signs of covert persistence or auth bypass at the system level.

Findings require dual probabilities of 0.85 or higher plus additional contextual confidence before the tool reports something as high risk — a deliberately conservative threshold meant to cut down false positives on a scan that runs before code has even executed. The author's own test run, dated September 2026 against Jev 1.13.0 on known-malicious samples, reports 0.96 probability on credential theft detection, 0.93 on exfiltration, and 0.93 on supply-chain risk detection — again, the author's numbers, on the author's samples, not reproduced independently. Exit codes are explicit: 0 for clean, 1 for needs-review or high risk, 2 for a configuration error, 3 for an incomplete scan. The README states plainly what it can't do — it doesn't fully cover cross-file data flows, obfuscated code, runtime-downloaded payloads, or transitive dependencies, and it calls itself "an auxiliary review tool, not security certification."

What the two share

Both projects make the same underlying bet as the rest of this series: that a fast, cheap, typed answer beats a slow, expensive, free-text one for decisions that happen constantly — every command in Hermes's case, every skill or MCP server you're about to trust in win4r's. And both authors resist overselling what they've built. That restraint, more than the star count or the benchmark numbers, is the more useful signal when you're deciding whether to try either one.

What to do next

1. Run hermes-jev-approvals in escalate-heavy mode first, and watch how often its six-question tree agrees with your own judgment before loosening it to auto-approve more.
2. Use jev-security-scan's local mode as a first pass on anything you install, and treat the Jev-mode semantic scan as an additional layer, not a replacement for reading the source yourself on anything sensitive.
3. Don't treat either tool's benchmark as generalizable. 153 commands and a hand-picked malicious-sample set are both real evidence, but both are small and author-controlled.
4. Remember what neither tool claims to catch — cross-file flows and obfuscation for the scanner, anything beyond the six scored questions for the approval gate.
5. Read the checklist at how to evaluate Jev projects honestly, and browse more approval and scanning tools at the Awesome Jev radar.