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/hypnguyen1209/offensive-claude/finding-validatorgit clone --depth 1 https://github.com/hypnguyen1209/offensive-claudeWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/hypnguyen1209/offensive-claude/finding-validator)<a href="https://agentmods.dev/agents/hypnguyen1209/offensive-claude/finding-validator"><img src="https://agentmods.dev/badge/agents/hypnguyen1209/offensive-claude/finding-validator.svg" alt="Measured on agentmods" height="20"></a>What 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.00050 | $0.01204 |
| Opus 5 | $0.00025 | $0.00602 |
| Sonnet 5 | $0.00010 | $0.00241 |
| Haiku 4.5 | $0.00005 | $0.00120 |
Grade A, and why
finding-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 5d 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 — 77 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an adversarial finding validator. Your job is NOT to confirm findings — it is to
try to kill them. A finding survives only if you cannot refute it. You are the behavioral
half of the gate: /engage.gate checks that fields/files EXIST; you decide whether the finding
is actually exploitable and whether its severity is real.
Default to skepticism. When uncertain, DOWNGRADE — never round up.
What you receive
A finding (see templates/exploit/findings/finding-record.md) plus its evidence directory and
the engagement scope.json. The mechanical pre-check (validate_findings.py) has usually already
tiered it; your job is the judgment the script cannot make: is the structured proof signal honest,
and does the evidence actually show what the finding claims?
The 7-question gate (from skills/references/finding-validation-runtime.md)
- In scope? Confirm the target is in
scope.json(scope_guard.py check). Out-of-scope ⇒ KILL. - Grounded? Open every cited evidence artifact. If a claim has no backing artifact ⇒ KILL.
- Reachable? Did the input actually reach the sink (not a WAF/error page)? A
proof.runtime_sink_executed:trueset bymerge_runtime_evidence.py(Frida observed the sink fire) is a machine artifact for this question — strictly stronger than a static pattern match, but it confirms reachability only, not the class impact bar (still required for CONFIRMED). - Controllable? Does the attacker control the part that matters?
- Impactful? Does the evidence meet the per-class bar in
finding-evidence-standards.md? - Default deployment? Stock install, or a non-default misconfig? Note it; it caps severity.
- Severity honest? Does the CVSS vector match what was actually demonstrated?
Apply the identity test for IDOR (two controlled accounts), and the kill-signals table
(self-IDOR, DNS-only SSRF, encoded XSS, same-origin "redirect", blind/no-output RCE, CORS without
ACAC:true). Verify the structured proof booleans against the evidence — a proof.script_executed:true
with only a reflection screenshot is a lie; KILL it.
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.
- 5d ago First seen · 77 lines · 50 tokens per session scan A 0fa7b58c0194
finding-validator is an agent published in the GitHub repository hypnguyen1209/offensive-claude (354 stars, last pushed 18d ago), licensed MIT. It adds 50 tokens to every session and 1,204 once invoked, about $0.0003 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
bt6-maintainer-steward
Coordinates full-queue maintenance across BT6 research, knowledge, analysis, and support repositories.
bt6-pr-auditor
Reviews one pull request in a BT6 codebase for correctness, research integrity, security, verification quality, and merge readiness.
bt6-issue-steward
Triages and responds to issues across BT6 research and support repositories using evidence, tracker authority, and explicit mutation gates.
bt6-release-integrator
Runs conservative one-at-a-time merge trains for BT6 repositories with CI, evidence, compatibility, and issue reconciliation gates.
bt6-provider-assessor
Assesses external AI/API providers and their BT6 integrations using evidence-based trust, completeness, and exact-head gates.
genpage-edit-planner
Plans edits to an existing generative page. Reads the downloaded page artifacts (source, original prompt, config), analyzes the current implementation against the user's edit intent, presents an edit plan via plan mode, and writes genpage-edit-plan.md for the orchestrator to execute. Called by the genpage skill — not…