appsec-implementer

name	appsec-implementer
description	MANUAL-ONLY; never auto-invoke. Implement a specific, already-decided application-security control in code — input validation at a boundary, output encoding, parameterized queries, authorization checks on a resource, secure session/cookie flags, safe file handling, SSRF/redirect allowlists, or a security fix for a known finding — test-first, with the control proven by a failing-then-passing negative test and no scope creep. Use when a threat model, security review, or the user has NAMED the control to build and you are editing the codebase to add it. Side-effecting and manual-only. Do NOT use to decide WHICH controls are needed (threat-modeler), review a diff (security-pr-reviewer), harden secrets/identity broadly (secrets-identity-hardener), or author RLS policies (rls-policy-auditor).
disable-model-invocation	true

AppSec Implementer

Purpose

Turn a named security control into a small, tested, reviewable code change. The control is proven by a negative test that fails before the change and passes after — an assertion that the abuse case is now denied — not by "looks secure now". The deliverable is a scoped diff plus the test evidence (commands run and their real output), touching only the files the control requires. This skill builds one decided control at a time; it does not decide what to build and it does not opportunistically refactor.

Use When

• Use when: a threat model, security-pr-reviewer finding, or the user has NAMED the control — "add server-side authorization to this endpoint", "parameterize this query", "validate and length-cap this input", "set HttpOnly/Secure/SameSite on the session cookie", "allowlist the redirect target".
• Use when: fixing a specific known vulnerability with a regression test that pins the fix.
• Do NOT use when: it is not yet decided which controls are needed — run threat-modeler first; implementing undecided controls is guessing.
• Do NOT use when: reviewing a diff for security — security-pr-reviewer.
• Do NOT use when: the work is broad secrets/identity hardening across the app — secrets-identity-hardener.
• Do NOT use when: the control is a database RLS policy — author/audit via rls-policy-auditor.
• Do NOT use when: the ask is a sweeping "make the app secure" — that is not one control; decompose it via threat-modeler first.

Inputs to Inspect

1. The control specification: the exact threat/finding it closes, from threat-modeler, security-pr-reviewer, or the user's request. No named control → Stop Conditions.
2. The code at the boundary being hardened: the handler, query, template, session config, or file path involved — and its callers.
3. The project's existing security utilities: validators, sanitizers, the ORM / query builder, the auth/session middleware — reuse them; do not hand-roll crypto or a second validation layer.
4. The test suite and its runner: where security/negative tests live and how they run, so the new test fits the project's conventions.
5. Framework/library versions (via lockfile) for the security API being used — behavior differs across versions; consult docs-first-implementer discipline rather than assuming an API exists.

Workflow

1. Confirm the control is decided and singular. Restate the one control and the abuse case it closes. If undecided or plural, stop and route to threat-modeler.
2. Classify the change (change-classification-gate) and confirm the approval path — security-control code changes need review; production config/secret changes cross human-approval-boundary.
3. Write the negative test first. Encode the abuse case as a test that attempts the forbidden action and asserts denial/failure. Run it; confirm it FAILS for the intended reason (the vulnerability is real), not a typo or setup error. This is the tdd-engineer red step for security.
4. Implement the minimal control using existing project utilities at the correct boundary (server-side, not just the client). No unrelated edits.
5. Run the negative test; confirm it now passes. Then run the full relevant suite to confirm no regression. Record exact commands + output.
6. Add positive-path coverage if the control could over-block (a validator that rejects legitimate input is a new bug).
7. Stage exactly the intended files (reviewable-diff-discipline); verify the staged set equals the control's footprint — no drive-by changes.
8. Report the control, the before/after test evidence, the files touched, residual risk, and any follow-up the control does NOT cover, so a reviewer (security-pr-reviewer) can verify it.

Output Format

APPSEC CONTROL IMPLEMENTED — <control name>
Closes: <threat/finding id + abuse case>
Change class: <class> — approval: <path / obtained?>
Negative test (red→green):
  command: <cmd>
  before: FAIL — <intended failure reason>
  after:  PASS
Full suite: <command> — <result>
Files changed: <exact paths — control footprint only>
Boundary: <where the control sits — confirmed server-side>
Reused utilities: <existing validators/ORM/middleware used>
Does NOT cover: <residual risk / adjacent controls still open>
Handoff: security-pr-reviewer to verify the diff.

Validation Checklist

• The control was named/decided before implementation — not invented here.
• A negative test was written first and confirmed failing for the right reason before the fix.
• The same test passes after the change; full relevant suite still green; real commands and output recorded.
• The control sits at a server-side/authoritative boundary, not only the client or UI.
• Existing project security utilities reused; no hand-rolled crypto or duplicate validation layer.
• Staged set equals the control footprint; no unrelated refactors.
• Residual/adjacent risk stated for the reviewer.

Security Rules

• No security control ships without a negative test that fails before it and passes after — an untested control is unverified (master-prompt §6).
• Controls are enforced server-side / authoritatively; client-side checks are UX, never the security boundary.
• Never hand-roll cryptography, token generation, or password hashing — use the platform/library primitive; flag if none is available and stop.
• Do not weaken or delete an existing control to make a test pass; if a control conflicts with the change, surface it via human-approval-boundary.
• Fixing one instance of a class (one unparameterized query) requires noting the sibling instances for a follow-up pass — do not imply the class is closed.

Gotchas

• Adding validation only on the client leaves the server endpoint exploitable; the API is the boundary, the form is not.
• A negative test that passes on the FIRST run (before the fix) is testing the wrong thing — the vulnerability wasn't reproduced; fix the test before the code.
• Over-strict validators become availability bugs: a regex that rejects valid emails/names/unicode is a new defect — add positive cases.
• Encoding at the wrong layer (escaping in the DB instead of at render, or double-encoding) neutralizes the control or corrupts data.
• Security "fixes" that touch many files invite rubber-stamping and hide the one line that matters — keep the diff to the control.

Stop Conditions

• No specific control is named, or the ask is "make it secure" broadly → stop; decompose via threat-modeler first.
• The change touches production config, secrets, or a security policy whose blast radius is unclear → stop for human-approval-boundary.
• The negative test cannot be made to fail before the fix → stop; the vulnerability is not reproduced and the control may be unnecessary or misplaced — reconfirm the threat.
• Implementing the control requires a schema/RLS change → that is rls-policy-auditor / secure-migration-reviewer territory; hand off.
• The only correct fix is a dependency upgrade with breaking changes → stop and surface the tradeoff rather than silently pinning or forcing it.

Supporting Files

• references/control-implementation-patterns.md — per-control implementation checklists (validation, encoding, authz, session, file handling, SSRF/redirect) and the negative-test shape for each.
• evals/evals.json — trigger + behavior cases.
• evals/trigger-evals.json — discrimination against threat-modeler, secrets-identity-hardener, and security-pr-reviewer.