In February 2026, a single GitHub issue title compromised the npm package for Cline, an AI coding assistant. The project used an AI agent to triage new issues. The agent read the issue title as instructions, the workflow it ran in held an npm publish token, and four well-understood weaknesses chained together. An unauthorised release, cline@2.3.0, was live for about eight hours.

No single bug in that chain was exotic. The flaw was in the design: untrusted text reached a component that could act with publishing credentials. That is exactly the kind of problem a threat model finds, and it takes far less than a day-long workshop to find it.

Why teams skip it

Most teams agree threat modeling is useful and still don’t do it. The usual reasons are practical: sessions take half a day, need a specialist, and produce a document nobody opens again. The fix is to make the session small enough to run every time a design changes, and to make the output a list of tickets.

The 45-minute format

Invite the engineer who owns the design, one other engineer, and whoever knows the product risk. Four people is plenty.

Before the session: one diagram (10 minutes, by the owner)

Draw the data flow for the change: users, services, data stores, third parties and the arrows between them. Then draw a line wherever trust changes, such as the internet to your API, your service to a vendor, or user input to a model. Those lines are trust boundaries, and most findings sit on them.

Minutes 0 to 10: walk the diagram

The owner explains what is being built and what is changing. Everyone else asks where data comes from and who can influence it.

Minutes 10 to 30: what can go wrong?

Go boundary by boundary. Use STRIDE as prompts, not a form: could someone pretend to be someone else (spoofing), change data they shouldn’t (tampering), deny doing something (repudiation), see data they shouldn’t (information disclosure), take the service down (denial of service), or do more than they’re allowed (elevation of privilege)? Write each threat as one sentence that starts with who and where.

Minutes 30 to 40: decide

Every threat gets one of three outcomes: fix before release, ticket for later with an owner, or accept with a named person and a reason. Unowned threats don’t leave the room.

Minutes 40 to 45: record

Save the diagram and the threat list next to the design doc or in the pull request. Next time the design changes, update it rather than starting again.

The four questionsThe format follows the four questions from the Threat Modeling Manifesto: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job?

Extra prompts for AI and agent features

2026 has produced a run of incidents with the same shape as Cline’s. Researchers found Salesforce Agentforce and Microsoft Copilot agent flows treating form input as trusted instructions. Microsoft fixed remote code execution paths in agent frameworks by making the vulnerable function invisible to the model. In August, The Register summarised research presented at Black Hat under the headline “Prompt injection isn’t the bug, AI agent frameworks are.” The common thread is design, so add these prompts when a model is in the diagram:

  • What untrusted text reaches the model? Issue titles, emails, web pages, documents, form fields and tool output all count. OWASP lists prompt injection first in its Top 10 for LLM applications.
  • What can the model cause to happen? List every tool, API and credential it can reach. OWASP calls the risk of too much reach “excessive agency”.
  • Where are the credentials? If the step that reasons over untrusted input runs in the same place as a deploy or publish token, draw that as a trust boundary violation.
  • What does a human approve? Decide which actions need a person in the loop before the model can trigger them.

Running your first one

  • Pick a feature that is in design now, not one that has already shipped.
  • Book 45 minutes and stop on time, even if you haven’t covered everything.
  • Count the outcome in tickets, not pages.
  • Run the next one on the next design change. The second session is faster.

Sources

  1. Cloud Security Alliance: AI agent prompt injection, the new CI/CD supply chain threat (Clinejection, 2026) (opens in a new tab)
  2. Dark Reading: Microsoft, Salesforce patch AI agent data leak flaws (2026) (opens in a new tab)
  3. Microsoft Security: When prompts become shells, RCE vulnerabilities in AI agent frameworks (7 May 2026) (opens in a new tab)
  4. The Register: Prompt injection isn’t the bug, AI agent frameworks are (5 Aug 2026) (opens in a new tab)
  5. Threat Modeling Manifesto (opens in a new tab)
  6. OWASP Top 10 for LLM Applications 2025 (opens in a new tab)