AI Threat Modeling: How to Threat-Model Your App With Claude Code or Cursor

Ask most developers when they last threat-modeled their app and you'll get a guilty pause. Threat modeling has a reputation: a security specialist, a whiteboard, a day of drawing data-flow diagrams and arguing about trust boundaries, and a document nobody opens again. Valuable in theory, skipped in practice.

AI threat modeling collapses that. Instead of drawing a diagram of what your app might look like, you point an AI coding agent at the code your app actually is and let it do the enumeration. This post explains what AI threat modeling is, how to do it, and — importantly — where it beats the tools that have owned this space for a decade.

What threat modeling is, stripped down

Threat modeling is one question, asked deliberately about one area of your app: "What could an attacker do here, and are we protected?" — then written down as a list of concrete threats, each mapped to its fix and to how you'd detect it.

The classic methods (STRIDE, PASTA, LINDDUN) are frameworks for asking that question systematically. The classic tools — Microsoft Threat Modeling Tool, OWASP Threat Dragon, IriusRisk, ThreatModeler — help you draw the system as a diagram and then suggest threats against the diagram.

The catch has always been the same: the diagram is a model of your system, maintained by hand, and it drifts from the real code the moment you ship. You threat-model the architecture you designed, not the code you deployed.

What changes with AI

An AI coding agent doesn't need the diagram. It can read the code.

That's the whole shift. When you hand a modern agent (Claude Code, Cursor, Codex) a focused prompt for one threat category, it can:

1. Inventory the real code for that category — the actual routes, handlers, middleware, and config.
2. Enumerate the threats that apply to your implementation, not a generic list.
3. Audit your files against each threat and report weaknesses with a file:line and a severity.

You go from "authorization is a risk you should think about" to "line 28 of routes/projects.js reads an object ID and queries by it without checking ownership — that's BOLA, critical." That's the difference between a model of your system and an X-ray of it.

How to do it in practice

You need an AI agent that can read your repo, opened at the project root. Then install the tool that ships the prompts:

npm install securenow

Go to /threat-modeling, which publishes a free, expert-written threat-modeling prompt for each of 25 categories — each mapped to the relevant OWASP framework. Pick the category that carries the most risk for your app, click Copy prompt, and paste it into your agent.

The agent produces two reports in a local threat/<category>/ folder:

• Code findings — the audit: every weakness with its location, risk, and fix.
• Detection & mitigation — the runbook: the runtime rules that would catch each threat in live traffic.

Both are self-contained HTML you open in your browser. Nothing is uploaded — the agent reads and writes locally. (For the full step-by-step, see the AI Security Auditing series.)

Where AI threat modeling wins

It uses the real code, not a diagram. No drift. The model is regenerated from source every time you run it, so it's always current.

It's exhaustive and consistent. A human reviewer checking the fiftieth route for the same class of bug starts skimming. An agent checks all fifty the same way. For coverage-type work — "is every endpoint doing the ownership check?" — this is a real advantage.

It's fast and repeatable. Minutes per category, re-runnable on every release. You can put it in CI so any pull request that touches sensitive code gets re-modeled automatically. That turns threat modeling from a once-a-year event into a continuous practice.

It produces detections, not just threats. Traditional threat modeling ends at "here are the risks." AI threat modeling with SecureNow ends at "here are the risks, here's the code that's vulnerable, and here are the rules that catch exploitation" — the code layer and the runtime layer in one pass.

It's free and local. No enterprise license, no diagram to maintain, and your codebase never leaves your machine.

Where it doesn't (yet) replace a human

Be clear-eyed, or the audit gives false comfort:

• Deep business-logic flaws that require understanding your domain's intent still need a human — though the payment/business-logic prompt gets surprisingly far.
• Multi-step exploit chains spanning services and state are hard for a single-pass audit.
• Anything requiring live exploitation to confirm is a penetration-test job.

The right framing, and the industry consensus in 2026: a good AI threat model is the starting point for human review, not a replacement for it. It does the tireless enumeration so your scarce expertise goes to the genuinely hard problems.

AI threat modeling vs. the diagram tools, side by side

They're not mutually exclusive — a design-time diagram is still useful for greenfield architecture. But for the code you've already shipped, AI threat modeling is the faster path to answers you can act on.

Start with one category

Don't try to model everything at once — that produces a shallow report. Pick the area that would hurt most if it broke:

• Logins and sessions → authentication
• API-first product → OWASP API Top 10
• User input into queries or templates → injection
• Shipping LLM features → AI / LLM features

Copy the prompt, paste it into your agent, and you'll have a threat model of your real code before your coffee's cold. Browse all 25 free prompts →