Agent-Engineer-Master Security Mindset Master
Overview
Security is a design constraint. Not a checklist. Not a phase. Not someone else's job.
Core principle: Think like an attacker during implementation. Reasoning about threats after the code is written is too late — you've already chosen the unsafe path.
Violating the letter of this rule is violating the spirit of this rule.
The Iron Law
NO ENDPOINT, DATA ACCESS PATTERN, OR USER INPUT HANDLER SHIPS WITHOUT A SECURITY ANALYSIS FIRST
The insecure path must never be the path of least resistance.
When to Use
Always — before writing code that touches:
- API endpoints (new or modified)
- Authentication or authorization logic
- Database queries or ORM calls
- User input of any kind
- Session tokens, JWTs, API keys
- File uploads or downloads
- Webhooks or callbacks
- Any feature that stores or transmits user data
Not for:
- Read-only documentation changes
- Infrastructure config unrelated to data flow
- Dependency version bumps with no logic changes
Thinking "this is a small change, security analysis is overkill"? That's rationalization. Small changes to auth logic have caused the largest breaches.
Phase 1: Threat Surface Analysis
Complete before writing any code.
Answer these questions explicitly — not in your head, in the response:
- Who can call this? — authenticated users only? anonymous? other services? what roles or permissions?
- What data does it touch? — classify sensitivity: PII, credentials, financial, internal-only, public
- What trust boundaries does it cross? — user → server, server → DB, server → external API, internal → internal
- Worst-case malicious caller — if an attacker controls this input, what's the most damaging thing they could make the system do?
- What if inputs are malformed? — empty, null, max-length exceeded, unexpected type, Unicode edge cases
- What if a request is replayed? — is the same request sent twice dangerous? is there idempotency protection?
- What if the caller substitutes another user's identifier? — can they access or modify another user's data?
Minimum acceptable output: at least one named threat and its mitigation documented. "No threats identified" is not an acceptable output for any code path touching user data.
Phase 2: Secure Defaults Checklist
Read references/secure-defaults.md. Each gate must be verified present — not assumed.
These are non-negotiable. There are no exceptions, only tradeoffs that must be explicitly documented:
- Parameterized queries — no string-concatenated SQL, LDAP, or OS commands anywhere in this code path
- Secrets in environment variables — no credentials, tokens, or keys in source code, comments, or log statements
- Auth check explicit in this handler — not inherited, not assumed from middleware — verify it is present in the code being written
- Input validated server-side — regardless of what client-side validation exists
- Sensitive data absent from logs — no passwords, tokens, PII, or session identifiers in any log call site this code touches
- HTTPS enforced, CSRF tokens present — on all state-changing endpoints
- CORS policy explicit and minimal — no wildcard origins on authenticated endpoints
Phase 3: Attacker's Eye Pass
Read references/attacker-patterns.md. Before writing any code, reason through each attack class for this specific feature:
| Attack | Question to answer |
|---|---|
| IDOR | Can a user modify an ID parameter to access another user's object? Is there a per-object ownership check? |
| Privilege escalation | Can a lower-privilege user reach this through a different code path? Is the role check on the resource, not just the route? |
| Replay attack | Is a valid request replayable? Are tokens/nonces single-use? |
| Timing attack | Does a timing difference between success and failure leak information (e.g., valid vs invalid username)? |
| Mass assignment | Does this endpoint bind request parameters to a model? Are bindable fields explicitly allowlisted? |
| Insecure deserialization | Does this code deserialize user-supplied data? Is the deserialization format safe? |
| Error leakage | Do error responses reveal stack traces, internal paths, DB structure, or version strings? |
Not every attack applies to every feature. Document which you considered, which apply, and how each applicable one is mitigated.
Phase 4: Structural vs Behavioral Check
After writing code, before marking done.
For every security control implemented, ask:
"If every future developer who touches this code ignores all comments, all docs, and all institutional memory — does this control still hold?"
Structural — the unsafe action is syntactically or architecturally impossible: parameterized queries, framework-level CSRF middleware, DB constraints, type system enforcement. Prefer these.
Behavioral — the control works only if developers remember to use it: a function that must be called manually, a comment saying "always check auth here." These accrue debt.
If a control is behavioral: either redesign it to be structural, or document the explicit risk acceptance with the reason redesign isn't feasible.
Red Flags — Stop Execution
These patterns require an immediate stop. Do not work around them. Fix them or escalate.
| Pattern | Stop Reason |
|---|---|
| String concatenation in any query | SQL / LDAP / command injection. Parameterize it. |
password, secret, token, or key in a log statement |
Credentials in logs. Remove unconditionally. |
| Endpoint handler with no visible auth/session check | Unauthenticated access. Add the check before continuing. |
CORS: * or equivalent wildcard on an authenticated endpoint |
Cross-origin credential theft. Specify allowed origins explicitly. |
| User-supplied data in a file path or shell command | Path traversal or command injection. Restrict and sanitize. |
| Error response includes stack trace or internal state | Information leakage. Return generic errors; log detail server-side. |
| "I'll add auth after the feature works" | This is how auth never gets added. Add it now. |
Common Rationalizations
| Rationalization | Reality |
|---|---|
| "It's an internal endpoint" | Internal endpoints get compromised. Supply chain attacks, SSRF, and misconfigured VPCs hit internal services routinely. Defense in depth means internal = untrusted. |
| "The client validates it" | Clients can be bypassed. Any attacker posts directly to the API. Server-side validation is non-negotiable regardless of frontend logic. |
| "We're behind a VPN / firewall" | Perimeter security fails. Assume breach. Zero-trust is the baseline, not the advanced model. |
| "It's just test data" | Test environments get used with real credentials. They share code paths with production. Treat them identically. |
| "I'll harden it before launch" | Security bolted on after is weaker, slower to ship, and requires revisiting every data access path. The debt compounds. |
| "Automated scanners would catch it" | IDOR, business logic flaws, and timing attacks are routinely missed by scanners. They find known patterns. You are writing the unknown pattern. |
| "UUIDs prevent IDOR" | Non-guessable IDs are defense-in-depth, not access control. If an ID leaks through any related endpoint, the vulnerability is exploitable. Per-object ownership checks are required regardless. |
Verification Checklist
Run after code is written, before marking the task complete. See also superpowers:verification-before-completion.
- Completed Phase 1 threat surface analysis before writing any code
- Documented at least one named threat and its mitigation — "no threats found" is not acceptable
- All Phase 2 secure defaults present and verified by reading the code — not assumed
- Completed Phase 3 attacker's eye pass — documented which attack classes apply and how each is mitigated
- Phase 4 check done — security controls are structural where possible; behavioral controls have explicit risk documentation
- No sensitive data in logs — verified by reading every log call site in the code written
- Auth check is explicit in this handler — not inherited from hope, verified present in the code