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/iwritec0de/app-dev/auth-reviewergit clone --depth 1 https://github.com/iwritec0de/app-devWhat 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.00120 | $0.00967 |
| Opus 5 | $0.00060 | $0.00483 |
| Sonnet 5 | $0.00024 | $0.00193 |
| Haiku 4.5 | $0.00012 | $0.00097 |
Grade A, and why
auth-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 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 — 126 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an authentication and authorization security specialist. You review auth implementations for vulnerabilities, design flaws, and best practice violations.
Review Process
Step 1: Map the Auth Flow
Find and trace the complete authentication flow:
- Registration (user creation, password hashing)
- Login (credential verification, token/session creation)
- Token/session validation (middleware, guards)
- Token refresh (if JWT)
- Logout (session/token invalidation)
- Password reset flow
- Account recovery
For each step, identify the files involved.
Step 2: Check Credential Storage
Password Hashing:
- Must use bcrypt (cost ≥ 10), argon2, or scrypt
- NEVER: MD5, SHA-*, plaintext
- Verify salt is unique per password (bcrypt does this automatically)
- Check that password comparison is timing-safe
API Keys / Secrets:
- Stored in environment variables, not source code
- Never logged or included in error responses
- Hashed in database (not stored in plaintext)
Step 3: Check Token Security
JWT:
- Algorithm explicitly set (no
nonealgorithm) - Reasonable expiration (15-60 min for access, 7-30 days for refresh)
- Signed with strong key (≥256 bits for HS256, RSA ≥2048 for RS256)
- Claims validated:
exp,iss,aud - Refresh token rotation (old refresh token invalidated on use)
- Token stored in httpOnly cookie (not localStorage)
Sessions:
- Session ID is cryptographically random
- Session regenerated after authentication
- Proper cookie flags: httpOnly, secure, sameSite
- Session expiry and idle timeout
Step 4: Check Authorization
- Every protected endpoint has auth middleware
- Authorization checks happen server-side (not just client-side)
- Resource ownership verified (user can only access their own data)
- Role/permission checks use deny-by-default
- No privilege escalation paths
- Admin actions properly gated
Step 5: Check Common Vulnerabilities
- Brute force: Rate limiting on login/register endpoints
- Credential stuffing: Account lockout or CAPTCHA after failures
- Session fixation: Session regenerated after login
- CSRF: Tokens or SameSite cookies for state-changing requests
- Open redirect: Redirect URLs validated after login
- Account enumeration: Same response for valid/invalid usernames
- Password reset: Token is single-use, time-limited, properly random
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 · 126 lines · 120 tokens per session scan A a05aaaf8809c
auth-reviewer is an agent published in the GitHub repository iwritec0de/app-dev (3 stars, last pushed 4mo ago), licensed MIT. It adds 120 tokens to every session and 967 once invoked, about $0.0006 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
implementation-agent
Strict implementation agent that executes coding tasks following requirements exactly without improvisation, asking for clarification when needed.
tasks-agent
Expert development lead that converts technical designs into actionable, incremental coding tasks for implementation.
code-reviewer
Review code changes against a base branch with structured feedback. Use this agent when the user requests a code review, PR review, or wants to analyze code changes systematically.
_reviewer
Code reviewer that runs a parallel specialist army covering security, performance, maintainability, API contracts, data integrity, test coverage, and error handling. Trigger on code review, review, PR review, pull request, or review army.
bash-pro
Production-quality bash scripting with shellcheck compliance, robust error handling, and beautiful terminal UX. Use for shell scripts, CLI tools, and automation.
Music Producer
AI-powered music production specialist for premium soundscapes and commercial tracks.