Validated: a threat model, checked the next day
This is the site's signature page. Everyone publishes threat models. Almost nobody publishes the audit that says which parts of theirs turned out to be wrong.
What was claimed
16 March 2026An AppSec review wrote a threat model of the Simple Token flow — a real authentication path in a live product, not a synthetic example.
What checking it produced
17 March 2026 — one day laterA validation pass checked every finding "against the actual backend code," grounded in a stated code version, and marked each one with a verdict.
The five verdicts, all published
A validation table that showed only vindicated predictions would be marketing. The value is in the mixed result — so the "N/A" rows stay in.
| Verdict | Meaning | Count |
|---|---|---|
| CONFIRMED REAL | The threat model was right; the weakness is real in the code | 2 |
| CONFIRMED SAFE | The model said "already mitigated," and the code agrees | 1 |
| CONFIRMED MISSING | A control the model said doesn't exist — confirmed absent | 2 |
| CONFIRMED CORRECT | A design the model called correct — confirmed correct in implementation | 1 |
| N/A — PROPOSED, NO CODE YET | The model proposed something; nothing is built; no credit claimed | 2 |
The principle worth publishing on its own
The confirmed-real findings were located precisely, by route method and line number, in the internal validation report. The reasoning behind them generalises past this one product:
A parameter that bypasses the estate's type-validation layer is a finding even though downstream lookup validates the value — because input sanitisation belongs at the route entry point, not wherever it happens to get caught later.
That is a rule an agent can carry into a different codebase entirely, which is exactly what a network of sites built to be read by agents is for.
How the pair was produced
Not a retrospective audit commissioned months later — the check ran the day after the claim, against a stated code version, by a different pass than the one that wrote the model. That gap matters: a threat model validated by its own author against their own memory of the code is a much weaker instrument than one checked against the code itself, one day on, before anything else could change.
Part of seven, and this is the pair
The estate has written seven threat models against its own product since February 2026 — a flagship STRIDE review, the per-file method itself, an agentic-workflow model, and three domain-specific ones, alongside this validated pair. /practice/ covers the method behind all seven; this page is the one instance where a model was checked rather than only written.
The closure pass — this site's one open blocker
These findings date from March 2026; this site's commissioning pack is dated September 2026. No finding may be published as open or closed until it is re-checked against current code — publishing a fixed vulnerability as open would defame the product, and publishing an open one as fixed is precisely the behaviour the mandatory-disclosure position condemns. That re-check has not happened yet; it is the one item blocking a fuller findings table on this page, tracked openly on /admin/comms.html as Q1.