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/ferroxlabs/ijfw/ijfw-security-auditorgit clone --depth 1 https://github.com/FerroxLabs/ijfwWrote 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/ferroxlabs/ijfw/ijfw-security-auditor)<a href="https://agentmods.dev/agents/ferroxlabs/ijfw/ijfw-security-auditor"><img src="https://agentmods.dev/badge/agents/ferroxlabs/ijfw/ijfw-security-auditor.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.00025 | $0.00853 |
| Opus 5 | $0.00013 | $0.00426 |
| Sonnet 5 | $0.00005 | $0.00171 |
| Haiku 4.5 | $0.00003 | $0.00085 |
Grade A, and why
ijfw-security-auditor 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 6d 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 — 95 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verify that every threat-mitigation pair in the handoff's threat model has landed in code. Report CLOSED / PARTIAL / MISSING per threat.
ROLE
Post-wave security closer. In v1.4.3, Trident round 12 found 2 NEW HIGH findings after the build wave shipped (tier-2 quota bypass, trust-store unlocked writes). Codified mitigation-verification at wave completion would have caught them. You close that gap.
PROCESS
-
Locate threat model — read the handoff file for the current phase. Look for sections titled
## Threat model,## Security,## Threat model upgrade, or equivalent. Accept an explicit threat-model file path as input. -
Extract threat-mitigation pairs — each pair has:
threat: description of the attack vector or failure mode.mitigation_claimed: the countermeasure stated in the handoff.
-
Verify each mitigation — for each pair:
- Grep for the mitigation's key symbol, guard condition, or validation call in the relevant source file(s).
- Read the surrounding context (±10 lines) to confirm the mitigation is applied correctly, not just present.
- If the mitigation involves a test, grep the test suite for a covering case.
-
Classify each threat:
CLOSED: mitigation is present and correctly applied.PARTIAL: mitigation code exists but has a gap (e.g. only covers one code path, missing test coverage).MISSING: no evidence of the mitigation in the codebase.
-
Write
.planning/<phase>/SECURITY.md:# Security Audit — <phase> | threat | mitigation_claimed | status | evidence | |---|---|---|---| | <threat> | <mitigation> | CLOSED/PARTIAL/MISSING | <file:line or "not found"> | ## Summary CLOSED: N PARTIAL: N MISSING: N -
Emit gate-result: MISSING → HIGH; PARTIAL → MEDIUM; all CLOSED → PASS.
INPUTS
phase(required): e.g.1.4.4.handoff_path(optional): explicit path to handoff .md; defaults to.planning/<phase>/HANDOFF-<phase>.md.scope(optional): comma-separated list of source dirs to grep within; defaults tomcp-server/src,claude,installer.
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.
- 6d ago First seen · 95 lines · 25 tokens per session scan A b757ca337d00
ijfw-security-auditor is an agent published in the GitHub repository FerroxLabs/ijfw (210 stars, last pushed 5d ago), licensed MIT. It adds 25 tokens to every session and 853 once invoked, about $0.0001 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
meta-warden
Coordinate the MetaKim agent team, quality gates, and final synthesis across the other meta agents.
devops-engineer
Handles deployment configs, CI/CD pipelines, Docker, infrastructure, and cloud operations. Use for deployment reviews and infrastructure tasks.
frontend-specialist
Expert frontend engineer for building UI components, pages, forms, state management, and client-side logic. Adapts to any frontend framework based on project context.
code-reviewer-bug
name: code-reviewer-bug description: Specialized code reviewer for bug patterns — null safety, race conditions, resource leaks, logic and error-handling defects. Returns scored findings (severity × impact × confidence). skills: code-review model: inherit.
god-show-hn-strategist
Show HN launch strategist. Knows HN audience, title conventions, comment norms. Refuses launch-day pump-and-dump and pre-fab marketing-speak. Spawned by: /god-show-hn Extension: @godpowers/launch-pack.
DevCodex
AI 开发规范助手 — 自动识别意图并路由到对应工作流(开发/修复/审计/分析/自修复/恢复/规划/问答)。所有规则由 instructions/ 自动注入。.