Auth change: risk analysis before the code, audit after

Authentication code fails quietly: the tests pass and the hole ships. This template puts a security pass on both sides of the implementation and tightens the release gate for the pull request it produces.

Which agents run

The Architect bounds the change: which files, which callers, what must stay compatible. The risk analysis comes before any code, so threats such as token replay, race conditions between two refreshes, or sessions that outlive a revocation shape the implementation instead of being found after it. The second Security Auditor step reviews the Builder's proposed edits, and the Tester names the cases that prove a replayed token is refused.

Then the code pass writes the change, your test command runs against it in an offline sandbox, and the findings review reads the real diff with both security steps as context.

Gates that apply

• Findings. Open high or critical findings block the pull request until triaged; security findings also appear under Secure → Security.
• Tests on this version. Failing tests block. An edit after the tests ran resets the result and the approval.
• Approval. A second person approves. Rejecting is always allowed, and a single rejection ends the request.

Block on medium findings in CI

For auth code, a medium finding is worth a conversation before merge. Lower the blocking severity in the CI check:

curl -sf -X POST "https://console.aicodeops.dev/api/release/check" \
  -H "Authorization: Bearer $WORKSPACE_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"pullRequestURL\":\"$PR_URL\",\"blockingSeverity\":\"medium\"}" \
  | jq -e '.allowed == true'

Denials list the open findings in blockingFindings. Triage each one (fixed, won't fix, false positive) from the run's Findings list, or choose Fix to start a session that fixes it. Fields are on the API page, and the review rules are in approvals and policies.

For supply-chain risk in the same service, pair this with the SBOM and license gate template.