Threat Model: $ARGUMENTS

Principle

/audit-security finds the holes after they're built; this skill prices them before, when a mitigation is one AC-line instead of a refactor. The method is an attacker's walk over the design: every new entry point, every trust boundary crossed, every data class touched — asked "how would I abuse this?" while it's still paper. Output is never advice — every threat lands as a spec AC, a plan step, or a named accepted risk with the user's sign-off.

Phase 0 — Load context

Read .claude/PROJECT.md (Architecture, Integrations, Domain → roles), the installed code.md + stack security rules, and the input artifact — an /analyst spec, a /prepare plan, or a described feature ($ARGUMENTS). Missing/TEMPLATE profile → fall back to the root CLAUDE.md (always in context) when it carries the architecture/integrations/roles (note you're running without a kit profile); STOP for /bootstrap first only if neither has them. Skim how the codebase already does auth/authz/validation (grep the enforcement points) — mitigations must reuse the house mechanism, not invent a parallel one.

Phase 1 — Map the surface (the model)

For the feature, enumerate — a table each, cited against spec/plan items:

1. Entry points — endpoints, forms, webhooks, file uploads, CLI/jobs args, messages consumed. New AND changed.
2. Trust boundaries crossed — internet→app, app→DB, app→third-party, tenant→tenant, user-role→admin-surface. Each crossing is where validation/authz must live (code.md).
3. Data classes touched — credentials/tokens, PII, money/ledger, user content, internal config. Class sets the stakes.
4. Actors — the role matrix from the spec, plus the two the spec forgot: the unauthenticated stranger and the authenticated-but-wrong-tenant/role user. Most real-world holes belong to those two.

Phase 2 — STRIDE-lite walk

Per entry point, five questions — pragmatic, not ceremonial (skip a row only with a written "n/a — why"):

Ground every YES/RISK in the artifact or codebase (path:line / spec item) — a threat with no concrete avenue is noise; this table feeds engineers, not compliance.

Phase 3 — Abuse cases (the attacker's user stories)

Three deliberate inversions beyond STRIDE:

• The hostile power user: scripts the feature at 1000× — what breaks, what gets scraped, what costs money (per-request LLM/API calls behind a free endpoint)?
• The curious insider: same-tenant low-role user exploring — what do IDs enumerate to, what do "hidden" UI actions actually enforce server-side?
• The supply path: what enters from the third-party side — webhook forgery (is the signature verified?), uploaded file content (parsed by what?), callback/redirect URLs.

Phase 4 — Land the mitigations

Every threat gets exactly one disposition — the table is the deliverable:

• Mitigations reuse the house mechanisms found in Phase 0.
• Accepted risks are the user's to accept — one AskUserQuestion listing them with your recommendation, never silently self-accepted (core.md).
• Route the additions: back into the spec (/analyst numbering — append, never renumber) or the plan (/prepare); the artifact's stage gate should fail until the rows land.
• Offer to write the model to the Plans location (<slug>-threat-model.md) when the surface is big enough to outlive this session.

Hard rules

• Design-time only; read-only on code — you change specs/plans, never source.
• No threat without an avenue; no mitigation without a landing place (AC / step / accepted-with-sign-off). A threat model whose findings changed nothing was theater.
• The forgotten actors are mandatory: unauthenticated + wrong-tenant walked at every entry point — that's where IDOR lives.
• Per-object authz, not per-endpoint — the elevation row always asks about the object.

See also

• /audit-security — the post-build counterpart (code-level sweep); security-reviewer agent — diff-level check; /analyst / /prepare — where the mitigations land; rules/_generic/code.md — the always-on floor.