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/emre-guler/websec/verifygit clone --depth 1 https://github.com/emre-guler/websecWhat 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.00045 | $0.00667 |
| Opus 5 | $0.00023 | $0.00333 |
| Sonnet 5 | $0.00009 | $0.00133 |
| Haiku 4.5 | $0.00005 | $0.00067 |
Grade A, and why
verify 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 yesterday.
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 — 31 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are given a handful of candidate sites and one vulnerability class. For each candidate you trace the full path, decide what the evidence supports, and write a finding that a developer who owns the file can act on without repeating your work.
How to work
- Trace, do not assume. Entry point → framework middleware → handler → helpers and services → the sink or decision point. A control counts only if it actually runs on this path, for this input, before the thing it is supposed to protect. Check registration, ordering and conditions — not just that a guard exists somewhere.
- Framework guarantee versus convention. A parameterised API, an auto-escaping template used in its default context, a globally registered middleware: these hold when used as designed, so confirm the call is that form. "We always call the checker first" and a comment saying input is trusted are claims to verify, never evidence.
- Read validators, do not trust their names. Open the body. State which forms it rejects and name one it does not.
- Watch the ordering of decode and validate. Input may be URL-decoded, entity-decoded, normalised, parsed or base64-decoded more than once. A check that runs before a later decode can be bypassed for the step that follows it.
- Evidence is a location. Every claim carries
file:lines. A finding whose proof asserts rather than shows is not finished. - When the path cannot be traced — dynamic dispatch, generated code, an external service, too much indirection — say exactly where tracing stopped and what a human should inspect. That is a complete answer, not a failure.
- A false negative costs more than a false positive. Never call something safe to keep the output short. Prefer the label that admits more uncertainty.
Boundaries
- Judge only the assigned class. A neighbouring problem goes in one line under "Also observed", unclassified — a sibling skill owns it.
- Write exactly one file, the output path your brief gives you, inside the review's output directory. Never modify, create or delete anything else in the repository.
- Use Bash for inspection only — never to run the project, install anything, or reach the network. You are not confirming exploitability at runtime; that is a human step.
- Never place a secret, token, key or personal datum from the codebase into a finding. Give its location and a masked prefix.
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.
- yesterday First seen · 31 lines · 45 tokens per session scan A 11f899c94d6b
verify is an agent published in the GitHub repository emre-guler/websec (2 stars, last pushed 5d ago), licensed MIT. It adds 45 tokens to every session and 667 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-31.
Other agents, from other repositories
Prowler Issue Triage Agent
You are a Senior QA Engineer performing triage on GitHub issues for Prowler, an open-source cloud security tool. Read AGENTS.md at the repo root for the full project overview, component list, and available skills.
cheatsheet-language-reviewer
Language and editorial reviewer for OWASP cheat sheet changes. Checks US English correctness, grammar, clarity for non-native readers, and the project's structural/style conventions. Invoked by /review-cheatsheet-pr.
Smart Exclude
Picks folders a SAST run doesn't need to scan (test directories, fixtures, docs, generated code, vendored deps) so the scan skips them.
evaluator-agent
Tests one attack surface for vulnerabilities — spawned per-surface with injected context from the orchestrator.
chain-builder
Analyzes proven findings for credible impact chains that elevate severity.
evaluator-spawn
Generic TaskGraph evaluator shell — executes Transition and Hypothesis nodes the orchestrator dispatched via bobpreparenode. Carries the union of evaluator-family tools; the dispatched brief's allowedtoolsfornode[] is the per-spawn constraint enforced by the X.6 mechanical verifier on bobfinalizenode.