AI Threat Modeling for Software Projects

Threat modeling is one of those engineering practices that everyone agrees is valuable and almost nobody actually does. The reason is simple: it takes a security engineer half a day to do it well, the output is a document rather than a feature, and the value of the output only becomes visible months later when a vulnerability that would have been caught at design time turns out not to exist in production. The skip rate is high because the immediate cost is high and the immediate reward is invisible. The result is that most software systems ship without an explicit threat model, and the vulnerabilities that should have been designed out at the beginning instead get patched out one CVE at a time over the lifetime of the system.

The /warden-threat skill changes the cost side of that equation. It applies the STRIDE framework against the actual codebase, maps the data flows and trust boundaries automatically, enumerates the relevant threat actors, and produces a threat model document with concrete mitigations and a residual risk assessment. The output is not a generic security checklist; it is a model of the specific system in front of you, with the specific attack surfaces that system actually exposes. What used to take a half-day of focused work from a security engineer takes minutes from /warden-threat, which means the practice becomes cheap enough to apply on every security-sensitive feature rather than only the ones that warrant a formal review.

Why generalist AI cannot do this

Threat modeling is not a generic security task. Asking a generalist chatbot "is this code secure" produces a list of OWASP-style platitudes that may or may not apply to the system being asked about. The platitudes are not wrong; they are just disconnected from the actual data flows in the application, the actual trust boundaries between services, and the actual threat actors who would target this specific product. A generic checklist is what a junior engineer produces on their first attempt at a security review. A threat model is what a senior security engineer produces after spending an hour reading the code and another hour thinking about how an attacker would approach it.

Cursor and Copilot are not designed for this kind of work at all. They operate at the line level, suggesting completions for the function in front of them. Threat modeling operates at the system level: it asks how data moves between components, where the trust assumptions are, where the privilege boundaries sit, and what an attacker who controls one component could do to the others. None of that is visible from a single file. The right tool needs to read the architecture, hold it in structured form, and reason about it from an adversarial perspective. That is the work /warden-threat is built to do.

What threat modeling actually requires

A useful threat model has four parts. First, a data flow diagram that shows how information moves through the system: which components send what to whom, where data crosses trust boundaries, and where it is stored at rest. Second, a list of trust boundaries: the places where one component is given authority over another, where authentication happens, where authorization is checked, and where input from outside the system is accepted. Third, an enumeration of threat actors: external attackers, insider threats, compromised dependencies, lost credentials, and the capabilities each one realistically has. Fourth, a list of threats that result from combining the data flow and the actors, classified by STRIDE category (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege), each paired with a mitigation and a residual risk note.

The STRIDE framework is the workhorse of threat modeling because it gives the analyst a structured way to look at every component and ask: how could this be spoofed, how could this be tampered with, how could this be repudiated, how could it leak information, how could it be denied of service, how could an attacker gain privilege through it. Going through the questions for each component generates a comprehensive threat list, and the threats that survive the mitigation pass become the residual risk the system carries forward. The discipline is what makes the practice valuable; the documentation is what makes the practice auditable.

How /warden-threat works

Step one: map the data flow from the codebase

When you invoke /warden-threat, the first thing it does is read the codebase to construct a data flow diagram. This is not an architecture diagram drawn in PowerPoint; it is derived from the actual entry points (API routes, queue consumers, scheduled jobs, webhook handlers), the actual data stores (databases, blob storage, caches), and the actual external integrations (payment providers, email services, third-party APIs). The diagram has nodes for components, edges for data flows, and annotations for the data shape that crosses each edge. The accuracy of the rest of the model depends on this step, so it is worth verifying the output before proceeding.

Step two: identify trust boundaries

On top of the data flow diagram, /warden-threat overlays the trust boundaries. A trust boundary is the line where a component starts trusting input from another. The boundary between the public internet and the API server is the most obvious one, but there are others: the boundary between the API server and the database, between the application code and a cron job that runs as root, between a microservice and the message queue it reads from. Each boundary is a place where authentication, authorization, or input validation needs to happen, and each boundary that lacks one of those is a candidate for a threat.

Step three: enumerate threat actors

The threat actor list is calibrated to the system. A consumer SaaS product faces external attackers (script kiddies, automated scanners, organized criminal groups), social engineers targeting customer accounts, insider threats from employees with privileged access, and supply chain risk from the dependency tree. A B2B product faces those plus targeted attackers (competitors, state actors for high-value targets) and customer-side compromise (an attacker who controls a customer account). The actor list shapes the threat enumeration: a threat from a state actor is weighted differently from a threat from an automated scanner.

Step four: STRIDE pass and mitigations

With the data flow, trust boundaries, and actors in hand, /warden-threat walks through STRIDE for each component and edge. The output is a table of threats, classified by STRIDE category, paired with a mitigation and a residual risk assessment. "Tampering with the password reset token" gets the mitigation "signed token with short expiry" and a residual risk note about token leakage in browser history. "Information disclosure in audit logs" gets the mitigation "redact PII at log time" and a residual risk about log aggregation systems. The threats that have no mitigation surface as accepted risks, which the team can then decide whether to accept or to fund mitigation work for.

Tonone's /warden-threat skill produces a STRIDE threat model from the actual codebase: data flow diagram, trust boundaries, threat actors, and STRIDE-classified threats with mitigations and residual risk.

When to use /warden-threat, and when not to

/warden-threat is the right call before designing any security-sensitive feature. The signal is when the feature touches authentication, authorization, payments, PII, admin access, data export, or anything that crosses a trust boundary. A new login flow needs a threat model. A new admin dashboard needs a threat model. A new payment integration absolutely needs a threat model. The skill is also the right call when a product brief says "the feature must be secure" without defining what that means; the threat model is the artifact that turns that vague requirement into concrete requirements.

Skip the skill for features that do not cross trust boundaries: a UI refactor that does not change data flows, a backend optimization that does not introduce new entry points, a cosmetic change to an existing form. The discipline of threat modeling has overhead, and applying it where it does not produce signal wastes the team's attention. For those cases, /warden-audit is a lighter-weight scan that catches common misconfigurations without producing a full model.

A worked example: threat modeling a password reset flow

Suppose the brief is: implement password reset for the consumer web application. Run /warden-threat against the codebase and the output looks like the following structure (abbreviated for the example).

Data flow:
  user -> POST /password/reset (email) -> rate-limited route
    -> email queue -> SMTP provider
    -> reset link in email -> GET /password/reset?token=...
    -> token validation -> POST /password/reset (token, new_password)
    -> password update -> session invalidation

Trust boundaries:
  1. Public internet -> rate-limited reset route
  2. App -> email queue (signed payload)
  3. SMTP provider -> user inbox (out of trust)
  4. Reset link click -> token validation route

Threat actors:
  - External attacker enumerating email addresses
  - Attacker with access to a victim's email
  - Attacker who can MITM email transit (rare but possible)
  - Insider with database access

STRIDE pass (excerpt):
  S (Spoofing): attacker requests reset for someone else's email
     Mitigation: rate-limit per IP and per email; do not reveal
     whether the email exists.
     Residual: timing oracle on lookup; mitigated with constant-time path.

  T (Tampering): attacker modifies token payload
     Mitigation: HMAC-signed token with secret rotation.
     Residual: secret leakage; mitigated by rotation cadence.

  R (Repudiation): user denies they reset their password
     Mitigation: audit log entry per reset with IP, UA, timestamp.
     Residual: log aggregation contains PII; redacted in storage.

  I (Information disclosure): error message reveals account exists
     Mitigation: identical response for existing and non-existing emails.
     Residual: side-channel timing; addressed in S above.

  D (Denial of service): mass reset emails to one address
     Mitigation: per-email rate limit (3/hour), per-IP rate limit.
     Residual: distributed flood; mitigated at edge with WAF.

  E (Elevation of privilege): reset to admin account
     Mitigation: admin accounts use a separate hardened reset flow
     with second factor required.
     Residual: admin email compromise; mitigated by 2FA enforcement.

The output is a real threat model, with concrete mitigations and explicit residual risk for each threat. The model becomes the input to the implementation: each mitigation is a requirement that the engineering team has to satisfy, and the residual risk list is the document the team carries forward as known accepted risk. Without /warden-threat, that artifact takes a security engineer half a day to produce. With it, the model is generated in minutes and reviewed by the team in the time it would have taken to schedule the meeting.

Related skills

/warden-threat produces the design-time security artifact. After the threats are identified, /warden-harden implements the mitigations: signed tokens, rate limiting, input validation, audit logging. /warden-audit is the lighter-weight scan for already-built systems, and /warden-iam is the right call when the threat model exposes gaps in role-based access control.

Install

/warden-threat ships with the Warden agent in the Tonone for Claude Code package. Install Tonone, invoke /warden-threat from any Claude Code session inside the repository, and the skill produces a STRIDE threat model against the actual codebase.

Threat modeling is the discipline that keeps vulnerabilities out of the design rather than catching them after the fact. The skill makes the discipline cheap enough to apply where it matters, which is most places where a feature crosses a trust boundary.