From Whiteboard Photo to Threat Model in an Afternoon

Full disclosure in one sentence: this is our workflow, in our product, and the pattern transfers to any tooling that treats diagrams as data instead of pictures.

Here is the failure mode this post is about. An architecture exists. It was designed by smart people who argued about it at a whiteboard, and the entire record of that argument is a photo in someone's camera roll, later pasted into slide 14 of a deck. The security review never happens, not because anyone objects to it, but because step one is "redraw all of this in a diagramming tool," and nobody has an afternoon to give. So the photo rots, the system ships, and the threat model joins the backlog of things everyone agrees are important.

The Threat Modeling Manifesto frames the discipline as four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job. Notice that the first question is where most teams die. Not because they cannot answer it, but because answering it in a reviewable form costs more than anyone budgeted.

What follows is one representative run of the alternative: a real afternoon's shape, not a benchmark. Timings are story beats from a typical session, and your system, your model, and your team will move at their own pace.

1:05 PM: the photo becomes shapes

The upload is the anticlimax it should be. The photo shows six boxes, some arrows, a cylinder someone labeled "PG" in marker, and a dotted line that meant something at the time. The Design with AI studio proposes a diagram from it: an API gateway, three services, a Postgres datastore, a queue, and a trust boundary where the dotted line was.

It also gets things wrong, and it is worth being specific about that. In a typical run the model merges two boxes that were drawn too close together, reads a bidirectional arrow as one-way, and has no idea that the box in the corner was crossed out because the team abandoned it mid-session. Handwriting on a glossy board photographed at an angle is genuinely hard input.

This is why the output is not an image but a proposal of real shapes on an editable canvas, delivered in an approval card. The engineer who stood at that whiteboard spends fifteen minutes accepting the right elements, splitting the merged box, reversing the arrow, and deleting the abandoned service. Correcting a mostly-right diagram is a fundamentally different task from redrawing one, and it is the difference between "this afternoon" and "next sprint."

2:00 PM: the design gets explained in writing

A diagram shows shape, not reasoning. The second studio runs a structured interview with the team: how does authentication work between the gateway and the services, where does customer data live and for how long, what happens when the queue consumer dies, who can reach the database and from where.

The answers get drafted into a design explanation, the written artefact a reviewer, an auditor, or a new hire can actually read. The team edits the draft, which is faster than writing it and, more importantly, actually happens. In the old workflow this document is the single most-skipped artefact of the review, because prose production is the least appealing work in security.

3:00 PM: threats, anchored and answered

Now the first question has an answer, so the second becomes tractable. The Threat Modeling Studio walks the corrected diagram and proposes STRIDE threats anchored to the elements they target: spoofing against the gateway's service tokens, tampering on the queue payloads, information disclosure on the analytics read path that quietly crosses the trust boundary.

Each proposed threat arrives with a suggested mapping to a control from the team's own catalog, and each batch lands as an approval card. The reviewer works through them the way an editor works through a draft: accept, adjust severity, reject. Two proposals get rejected in this run, one because the internal endpoint it targets already requires mutual TLS, one because it duplicates an accepted threat at a different element. That judgment is the review. The model widened the search; the human made the calls; the audit log recorded both.

What does not happen matters as much: nothing was written to the threat model without a person approving it, and the count of unmitigated threats is now a live number on the project instead of a guess.

4:15 PM: the record, assembled

The last step is the one that used to eat a day by itself: producing the document. The design-document export is deliberately not AI: it deterministically assembles the approved diagram, the design explanation, the threat model with its control mappings, the decisions, and the sign-off state into one PDF. Nothing in the export is model output that a human did not already review on its way in.

Sign-off requests go to named people: the security reviewer, the engineering owner, the data owner. When they approve, the design baselines, and from that point the record is not a snapshot but a reference: if the architecture drifts later, the drift is visible against the baseline instead of silently invalidating slide 14.

Why the afternoon matters

The point of compressing this work into an afternoon is not the afternoon. It is that reviews which cost an afternoon actually occur, for the second service and the tenth, not just the flagship. The whiteboard photo stops being where architecture goes to die and becomes the intake format it always secretly was.

And because the threats, controls, and decisions land in a connected system rather than a document, the afternoon keeps paying: mapped controls become build requirements, accepted risks appear in the risk register, and the next design review starts from a threat library that already knows this team's patterns. If the process itself is what you are missing, start with what a security design review contains and work backwards from the record you want.

If you would rather see the workflow than read about it, meet the assistant. Bring your own model and a photo of your worst whiteboard.