Threat modeling

Threat Modeling

Rules (for AI agents)

ALWAYS

• Start a new feature/service by naming the assets (data, funds, credentials, keys, compute) and the actors (users, tenants, services, admins, attackers). You cannot secure what you have not named.
• Draw the trust boundaries — every point where data crosses from a less-trusted zone to a more-trusted one (internet→app, tenant→shared store, service→service, user-input→interpreter). Each crossing needs authentication, authorization, and input validation at the crossing.
• Treat authorization as a design decision: for every resource decide who may read/write it and enforce it at the object level (owner/tenant scoping), not just "is authenticated". Design tenant isolation as a boundary the data model enforces, not a WHERE-clause a developer must remember every time.
• Map the data flow of every sensitive datum (credentials, PII, tokens, keys, financial): where it enters, is stored, transits, and leaves, and who can read it at each hop. Apply least-privilege and encryption at rest / in transit by design.
• Enumerate the attack surface each change adds — a new endpoint, input, dependency, integration, permission, or externally-reachable component — and state the threat + the control for each before writing code.
• Design controls to fail closed / deny by default: on error, missing config, or an unhandled case, the secure outcome is to deny, not to allow.
• Put each control at the component that owns the asset, behind (not instead of) any gateway — the owning service must authenticate and authorize even when a perimeter also does. Reachability is not trust.
• Run a one-line STRIDE pass at each trust boundary: Spoofing (identity), Tampering (integrity), Repudiation (audit trail), Information disclosure (confidentiality), Denial of service (availability), Elevation of privilege (authz). Skip the categories that genuinely do not apply.

NEVER

• Push a security decision to the client / edge and treat it as enforced. Anything the client controls — hidden fields, disabled buttons, client-side role checks, a signed-but-unverified token — is advisory, never a control.
• Design a shared or global namespace (global gallery, shared catalog, org-wide list) that any authenticated user can write to without a function-level privilege gate — a low-privilege writer into a globally-visible store is a stored-XSS / malicious-link delivery vector.
• Rely on network position (private subnet, VPN, "internal-only", IP allowlist, WAF) as the only control on a sensitive component. One SSRF, one foothold, or one boundary change opens it. Network is defense-in-depth, not the auth boundary.
• Let "trusted internal service" mean "unauthenticated". Internal callers get spoofed (SSRF, a compromised peer, a new tenant on the network). Authenticate service-to-service (mTLS / SPIFFE); do not trust source IP.
• Invent a bespoke crypto, authentication, session, or access-control primitive when a vetted one exists. Design in the standard building block (OIDC, mTLS, a policy engine); do not hand-roll security mechanics.
• Add a new external integration, dependency, or webhook without a threat entry: who may call it, what it is trusted to assert, and what happens if the counterparty is compromised or spoofed.
• Decide at design time to store or log secrets/PII in a place the model did not sanction — logs, error payloads, client bundles, URL params, analytics. Name the one sanctioned home for each sensitive datum instead.
• Ship a design whose only security analysis is "we will add auth later". Retrofitting a trust boundary onto a built feature is exactly where the expensive misses happen.

KNOWN FALSE POSITIVES

• A genuinely public, read-only, non-tenant surface (marketing site, public docs, public catalog) legitimately has no auth. The model's job is to confirm it holds nothing sensitive, not to bolt auth onto it.
• Defense-in-depth network controls (mTLS mesh, NetworkPolicy, private ingress) layered on top of service-level auth are good design, not a finding — the anti-pattern is only when they are the sole control.
• mTLS / SPIFFE workload identity is authentication (a cryptographic caller identity), so service-to-service calls over it do not also need network-position distrust.
• A prototype/spike explicitly scoped as non-production with no real data does not need a full model — but "must not ship / must not touch prod data" is itself the control to state.
• Not every function needs its own STRIDE table. Apply the pass at trust boundaries and asset stores, not to pure or internal helpers with no security-relevant input.

Context (for humans)

Threat modeling is the highest-leverage security activity because it runs before code exists, when changing a decision is cheap. Its output is not a document for its own sake — it is a short list of (asset, boundary, threat, control) that tells the implementer what must be true.

For AI-assisted development the failure mode is specific: models produce clean, working code that implements an insecure design — tenant data commingled in one table behind an app-enforced filter, auth checked at a gateway the service also exposes directly, a secret whose lifecycle nobody decided. None of these appear as a "bad line" a scanner can flag; they are visible only at the altitude of the design.

Consult this skill when scaffolding a feature or reviewing an architecture/RFC: name the assets and actors, draw the boundaries, and run a one-line STRIDE pass at each. Enforcement of the individual controls lives in the code-level skills — api-security (object/function-level authz), auth-security, ssrf-prevention, secret-detection. This skill decides which controls the design requires; those skills implement them.

References

• OWASP Threat Modeling Cheat Sheet.
• Microsoft STRIDE threat model.
• NIST SP 800-154 — Data-Centric System Threat Modeling.
• Related skills: secure-code-review, api-security, auth-security, ssrf-prevention.