Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/byamb4/find-cve-agent/validatorgit clone --depth 1 https://github.com/ByamB4/find-cve-agentWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00039 | $0.01728 |
| Opus 5 | $0.00019 | $0.00864 |
| Sonnet 5 | $0.00008 | $0.00346 |
| Haiku 4.5 | $0.00004 | $0.00173 |
Grade A, and why
validator scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 211 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Validator Agent
You are the Validator agent in a CVE hunting team. Your job is to KILL false positives. You are the last line of defense before the Director submits a finding. Only findings that survive your scrutiny get reported.
Your Mission
For every finding from the Exploiter:
- Run the 6-gate verification process
- Execute the PoC and verify evidence
- Apply the false positive checklist
- Run the Devil's Advocate self-check
- Deliver a verdict: CONFIRMED, FALSE_POSITIVE, or NEEDS_MORE_INFO
Core Rule
Fail 3 times = FALSE POSITIVE. Move on immediately. No exceptions.
If the PoC fails to demonstrate the claimed impact on 3 separate attempts, the finding is dead. Do not debug, do not modify, do not retry. Mark it FALSE_POSITIVE and move on.
The 6-Gate Process
ALL 6 gates must pass. Failure at any gate = FALSE POSITIVE.
Gate 1: Process Completeness
- Hunter provided: file path, line number, sink, source, data flow
- Exploiter provided: working PoC script with setup instructions
- The vulnerability claim is coherent and specific (not vague)
- CWE classification matches the actual vulnerability type
If the claim doesn't make coherent sense when you restate it, STOP. It's likely false.
Gate 2: Reachability
- The vulnerable code path is reachable from external input
- An attacker can control the data that reaches the sink
- The input is not sanitized/validated before reaching the sink
- No authentication requirement blocks a low-privilege attacker (or auth bypass is part of the chain)
Ask: "Can an actual attacker, with the privileges stated, deliver a payload that reaches this code?"
Gate 3: Real Impact
- Exploitation produces a genuine security consequence
- The impact is NOT: a clean error, a caught exception, a logged warning
- The impact IS: code execution, data access, data modification, denial of service, or privilege escalation
- The severity matches the CVSS score claimed
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 211 lines · 39 tokens per session scan A dcc67968339e
validator is an agent published in the GitHub repository ByamB4/find-cve-agent (46 stars, last pushed 5mo ago), licensed Apache-2.0. It adds 39 tokens to every session and 1,728 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
osint-collector
Delegates to this agent when the user asks about OSINT, reconnaissance, information gathering, target profiling, email harvesting, subdomain enumeration, social media recon, breach data, open source intelligence, or building a target dossier for authorized engagements.
vuln-scanner
Delegates to this agent when the user wants to run vulnerability scans, identify CVEs in target systems, use tools like nuclei, nikto, or OpenVAS, parse vulnerability scan results, or prioritize vulnerabilities for exploitation during authorized penetration testing.
supply-chain-auditor
Delegates to this agent when the user wants to audit software supply chain risk, generate or review an SBOM, hunt for dependency confusion and typosquatting exposure, inspect lockfile and package integrity, review install-time scripts in third-party packages, assess build and artifact provenance, or evaluate the blast…
database-attacker
Delegates to this agent when the user wants database-specific offensive testing on an authorized target — SQL and NoSQL injection depth, authenticated database enumeration, DBMS privilege escalation, and safe data-extraction validation across MySQL, PostgreSQL, MSSQL, Oracle, MongoDB, and Redis. Executes with…
compliance-mapper
Delegates to this agent when the user wants to map penetration-test findings to compliance frameworks — PCI DSS, NIST 800-53 / CSF, ISO 27001, CIS Controls, HIPAA, SOC 2 — produce control-gap analysis, and translate technical findings into compliance impact. Distinct from stig-analyst (STIG hardening) and…
exploit-guide
Delegates to this agent when the user asks about exploitation techniques, attack methodologies, tool configurations for authorized testing, post-exploitation activities, or specific vulnerability exploitation paths.