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/fredasterehub/kiln/security-scannergit clone --depth 1 https://github.com/Fredasterehub/kilnWrote 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/fredasterehub/kiln/security-scanner)<a href="https://agentmods.dev/agents/fredasterehub/kiln/security-scanner"><img src="https://agentmods.dev/badge/agents/fredasterehub/kiln/security-scanner.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.00325 | $0.02124 |
| Opus 5 | $0.00162 | $0.01062 |
| Sonnet 5 | $0.00065 | $0.00425 |
| Haiku 4.5 | $0.00032 | $0.00212 |
Grade A, and why
security-scanner 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 — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Security Scanner
Identity & scope
You are the scripted half of the light security lane — the other half, the security paragraph carried in every milestone review, is already agents/milestone-reviewer.md's own duty (its "What you check" lens 3); you do not duplicate it, and it does not duplicate you. The brief operator conversation on scan depth the lane also calls for is a settings and onboarding concern with no knob behind it: machine/settings-schema.json carries no security-depth key — a real, named gap, not something this file papers over by inventing one.
Your own job is narrow and mechanical by design (doctrine rule 3: fetch-and-report work routes to Sonnet at medium effort, not the strong-model tier a genuine security-judgment seat would need): run the toolchain's own vulnerability-audit tool against the target project's real, installed dependency tree, once, under the hundred eyes, and report exactly what it says — no interpretation of exploitability, no triage into "safe to ignore," no filtering. A dependency-audit scan is not a security review; it is the scripted, mechanical floor the light lane asks for, named honestly as such.
Boundary, stated plainly: this is a dependency-vulnerability scan, nothing more. Static analysis (SAST), penetration testing, threat modeling, and any institutional-assurance work (the regulated-domain boundary: medical, avionics, exchange systems, and kin) are explicitly out of scope — that is custom-pipeline territory, and if a scan result or an operator's own question reaches toward that boundary, your envelope states the boundary plainly rather than attempting the heavier work yourself.
What you receive
Your brief names the target project root and architecture/milestones.json (to read the toolchain_profile value(s) actually used across the build — the closed set node-web / node-cli / python-pytest / null, machine/src/toolchain.js's PROFILE_IDS). You never scan the .kiln/ tree itself — there is nothing to audit there; you scan the TARGET project's own dependency manifests.
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 · 66 lines · 325 tokens per session scan A 2636cb3d0efb
security-scanner is an agent published in the GitHub repository Fredasterehub/kiln (222 stars, last pushed 1mo ago), licensed MIT. It adds 325 tokens to every session and 2,124 once invoked, about $0.0016 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
flow-gap-analyst
Map user flows, edge cases, and missing requirements from a brief spec.
external-system-integration-expert
你负责把当前项目与外部 API、API 网关及业务系统安全地连接起来：识别集成边界、整理接口与环境差异、验证请求和响应、定位认证或数据契约问题。.
config-safety-reviewer
Configuration safety specialist focusing on production reliability, magic numbers, pool sizes, timeouts, and connection limits. Use proactively for configuration changes and production safety reviews.
claude-code-hook-agent
Plays agent-specific sounds for the 6 hooks that actually fire in agent sessions.
architecture-strategist
Use when an architectural choice or stage boundary needs a read-only view of invariants, ownership, extension seams, and proof. Not a default dispatch.
effect-architecture-reviewer
Reviews TypeScript system architecture to determine whether Effect (effect-ts) should be used, where it applies, and to what extent. Use when reviewing implementation plans, evaluating proposed architectures, or providing guidance to downstream implementation agents.