Details

Most developers are already threat modeling. They just don't call it that.

Mike Shema (Application Security Weekly) joins FusionAuth's Dan Moore for a casual conversation about what threat modeling looks like once you strip away the industry jargon. They'll use MCP as a topical entry point. MCP was a spec that shipped fast, without security fully baked in, and is already on version 2.0. But MCP leads to a bigger question: Did LLMs and agentic systems meaningfully change the threat landscape or just give old problems new names?

From there the conversation moves into the parts of threat modeling that tend to get skipped: What happens after the exercise is documented (the “Day 2” problem), how threat modeling identity differs for customers versus employees, and why business logic — who can act as whom and what those actions entail — matters more than chasing the next CVE.

This is a security-101-level conversation for a developer audience who works with security every day but doesn't think of themselves as security people.

What You'll Learn

• The four-question approach to threat modeling and why you're probably already doing it informally, without the vocabulary to describe it
• Did AI actually change the threats? Mike's take on whether agents and LLMs introduced new risks or just relabeled familiar ones
• The “Day 2” problem: Why most threat models get written once, filed away, and ignored — and how to keep them actionable across a feature's lifetime
• Identity isn't one threat model: Why modeling threats to customer identity (CIAM) looks different from modeling threats to employee/enterprise identity
• Business logic over chasing CVEs: How to threat model workflows, impersonation, and unexpected actions instead of over-indexing on technical vulnerabilities like SQL injection and XSS
• What the specs don't solve for you: What OAuth's security guidance and HTTP request smuggling reveal about the limits of “the spec already handled it”

‍