Add security-sensitive change review checklist

.github/pull_request_template.md

@@ -21,6 +21,21 @@
 
 ---
 
+## Security-sensitive change checklist
+
+<!-- Only fill this in if this PR touches authentication, credentials, tokens, or session/connection state, AND an external user is involved. Otherwise, delete this section. -->
+
+- [ ] Ran `/security-review` (note: by design it does not check for denial-of-service or resource-exhaustion issues — those need the next steps)
+- [ ] Considered adversarial/misuse scenarios and checked the code against each (list them below)
+- [ ] Added a regression test that fails against the pre-fix code for anything found this way
+- [ ] Checked resource bounds: timeouts, cache eviction/max size, request/entry limits
+
+**Scenarios considered:**
+
+<!-- e.g. "what if this instance is shared across two concurrent sessions", "what if a client returns a value far larger than expected", "what if this token isn't verified the way we assume" -->
+
+---
+
 ## Additional Notes
 
 <!-- Include any further details, follow-up items, or decisions relevant to the reviewer. -->

docs/engineering_standards.md

@@ -56,6 +56,13 @@ global.fetch = myCustomFetch; // ❌ Don't do this
 
 - **No Secrets in Code:** Never commit API keys, tokens, or secrets. Use environment variables and `.env` files (excluded from git).
 - **Dependency Updates:** Keep dependencies up to date and monitor for vulnerabilities.
+- **Security-Sensitive Change Review:** For changes touching authentication, credentials, tokens, or session/connection state where an external user is involved, review needs more than a diff read:
+  1. Run the `/security-review` skill. It's good at authentication, authorization, injection, and crypto issues, but its own instructions explicitly exclude denial-of-service and resource-exhaustion findings, so a clean result doesn't mean those are covered.
+  2. Write down 2-3 concrete adversarial or misuse scenarios for the change (e.g. "what if this instance is shared across two concurrent sessions", "what if a client returns a value far larger than expected", "what if this token isn't verified the way we assume") and check the code against each one.
+  3. Add a regression test that fails against the pre-fix code for anything found this way — proof the issue was real, not just "looks fixed."
+  4. Get 2+ reviewer approvals as a floor, treated as a backstop rather than the primary defense.
+
+  This doesn't apply to every PR, only ones where getting it wrong could expose one user's data or credentials to another, or let a shared resource be exhausted by external input. See `mcp-devkit-server` PR #57 for a worked example: a cross-session credential-hijack bug and several resource-exhaustion gaps got past the original implementation and a full round of human review, and were only caught by later, independently-run adversarial passes.
 
 ## 7. Automation