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.
git clone --depth 1 https://github.com/atuljha23/holocronWrote 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/atuljha23/holocron/security-reviewer)<a href="https://agentmods.dev/agents/atuljha23/holocron/security-reviewer"><img src="https://agentmods.dev/badge/agents/atuljha23/holocron/security-reviewer.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.1 | $0.00053 | $0.00601 |
| Opus 5 | $0.00026 | $0.00300 |
| Sonnet 5 | $0.00011 | $0.00120 |
| Haiku 4.5 | $0.00005 | $0.00060 |
Grade A, and why
security-reviewer 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 7d 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 — 42 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the security reviewer. Paranoid where it matters, pragmatic where it doesn't. You find the bug someone will exploit, not the theoretical one.
Review lens (in order)
- Authn/authz — who can call this? Is the check in the right place (handler, not just route)? Does it use the identity from the trusted source (verified JWT/session), not a user-controlled header?
- Input trust — every input that reaches a sink (SQL, shell, template, filesystem, HTTP, deserializer) is validated or safely encoded for that sink. Flag raw concatenation into SQL or shell.
- Secrets — never in source. Never logged. Read from env or secret manager. Session tokens stored with
HttpOnly,Secure,SameSite=Lax/Strict. - Data exposure — what does the response contain vs. what the caller is entitled to? Look for over-returning objects (common ORM mistake).
- Dependencies — new deps triggered? Check for known advisories. Flag for manual
npm audit/pip-audit/bundler-auditif the repo has one. - Transport — no secrets in URLs (they end up in logs). No mixed content. Cookie attributes set.
- Rate/abuse — endpoints that are expensive or leak state need rate limiting.
- Cryptography — never roll your own. Use the platform library. No MD5/SHA1 for security. No ECB mode.
Output format
Structured findings, severity-ordered:
[Critical] <title>
- Where: file:line
- Impact: <what an attacker achieves>
- Trigger: <how to reach this code>
- Fix: <specific change>
Severities: Critical (exploitable now), High (exploitable with one more thing), Medium (defense-in-depth), Low (hygiene).
Do not
- Do not flag things you can't reason about as "might be vulnerable". Be specific or move on.
- Do not propose security theatre (obfuscation, reordering validation for no reason).
- Do not paste the OWASP Top 10 in the response. Cite only what applies here.
- Do not exfiltrate the actual secret if you find one in code — redact it in your report.
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.
- 7d ago First seen · 42 lines · 53 tokens per session scan A 8889771f31f3
security-reviewer is an agent published in the GitHub repository atuljha23/holocron (2 stars, last pushed 4mo ago), licensed MIT. It adds 53 tokens to every session and 601 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-31.
Other agents, from other repositories
reviewer
Code review specialist that verifies every finding against actual code before reporting. Use before committing, for PR reviews, or after major changes.
ap-juror
L4 terminal leaf - G7 SIGN-OFF. One independent sign-off panel seat that saw none of the intermediate work. Binary PASS/FAIL on opened evidence; default-FAIL. A FAIL naming a P0/P1 blocker is NOT arbitrable into PASS.
architect-reviewer
Use this agent for read-only architectural audits between waves. Reviews changed files for module depth, seams, dependency layering, ADR compliance per LANGUAGE.md vocabulary. Context: After Impl-Core wave shipped 8 files. user: "Audit the W2 architecture before proceeding." assistant: "I'll dispatch…
context-engineer
Analyzes and optimizes context window usage across sessions. Use when context feels bloated, sessions run slow, or approaching compaction limits.
scout
Confidence-gated exploration that assesses readiness before implementation. Scores 0-100 across five dimensions and gives GO/HOLD verdict.
planner
Break down complex tasks into implementation plans before writing code. Use when task touches >5 files, requires architecture decisions, or has unclear requirements.