The method, redacted honestly
The research argues threat modelling should be objective, repeatable and continuously checked. This section is the evidence that the estate does it — on a live product, naming its own unmitigated weaknesses where it is safe to. Publish the method in full; apply the disclosure rule to the findings.
Seven threat models, since February 2026
| # | What it is | Date |
|---|---|---|
| 1 | The flagship: full STRIDE, data-flow diagrams, trust boundaries, attack surfaces, zero-knowledge verification, a 37-entry risk register | 12 Feb 2026 |
| 2 | The method itself: bottom-up, file-by-file, the parallel security tree | 25 Feb 2026 |
| 3 | Two-modes analysis of an agentic workflow — six threats, a risk matrix, prioritised recommendations with named owners | 26 Feb 2026 |
| 4 | Token consumption flow | 1 Mar 2026 |
| 5 | Office document viewers and print — an attack surface | 3 Mar 2026 |
| 6 | Simple Token flow — the claim | 16 Mar 2026 |
| 7 | Simple Token flow — the check | 17 Mar 2026 |
Models 4 and 5 are catalogued here by date and subject; a full read-and-publish pass on their content has not happened yet (tracked as gap G5 on comms).
The bottom-up method, publishable in full
The framework this site can publish without redaction, because a method exposes nothing about a live system. It opens with unusual candour about why it was commissioned: the team had shipped fast, and "some access tokens have already been leaked in posts (not yet abused, but only because usage is low and assets aren't high-value yet). This won't stay true as the platform grows." The stated goal is not remediation but coverage — "to make informed, risk-based decisions about what to address and when."
The approach is bottom-up, and the reasoning is fractal:
File → Method → Class → Module → Path/Journey → Endpoint → Full Attack Surface
Against every source file sits a .security.json in a parallel tree. The schema, as a reusable artefact →
Three patterns worth their own page
.security.json
Attack surface, vulnerabilities, secrets exposure, dependencies, redundant code — and the interesting field, risk_decision, which records an explicit accept-for-now with its reasoning.
STRIDE, applied honestly
Six categories run as threat × likelihood × impact × mitigation status, with NOT MITIGATED populated as often as MITIGATED. Server-breach impact recorded as None — mitigated by design.
Two modes, not averaged
Two delivery modes "look similar from the outside... but have radically different security properties." Scoring them as one number would erase the difference that matters.
The pattern →What the practice teaches that the papers cannot
The research says threat models should be living, checkable artefacts. The practice shows what that costs and what it produces: a model written in a day, a validation that partly contradicts it the next, findings that stay open with a recorded risk decision, and named owners for each recommendation. The site publishes the mixed results, not the wins — see /validated/ — because that is both the more useful memory for an agent and the only honest way to hold the mandatory-disclosure position.