Threat modelling has a reputation for being valuable in theory and skipped in practice, because doing it properly, systematically walking through a system's trust boundaries, data flows, and attack surface, takes real time that competes directly with shipping features. Most teams that do threat model at all do it once, at a big design review, and never revisit it as the system actually evolves, which means the threat model quietly stops reflecting reality within a few months, sometimes well before the next formal review is even scheduled.
Where an agent genuinely helps with threat modelling
The strongest use case isn't asking Claude Code to invent a threat model from nothing, it's using it to systematically walk a codebase and surface the actual trust boundaries and data flows that exist right now, which is exactly the kind of thorough, methodical, genuinely tedious cross-referencing work that's easy to do incompletely once real time pressure sets in. Point it at a service's entry points (API routes, message queue consumers, scheduled jobs) and have it trace what data flows in, what's trusted implicitly versus explicitly validated, and where a boundary crossing happens without an explicit authorisation check in place.
Mapping actual entry points and data flows as they exist in the code today, not as a design doc claims
Flagging trust boundary crossings that lack explicit validation or authorisation checks
Cross-referencing against a standard framework like STRIDE to make sure common threat categories aren't skipped
Producing a structured threat model document a human security reviewer can start from rather than build from scratch
Why grounding it in the actual code matters more than the framework
A threat model built from a design document describes the system as intended; a threat model built from the actual code describes the system as it actually is, and those two things drift apart over time in every codebase that's been under active development for more than a few months. The genuinely useful version of this workflow reads the real code, not the architecture diagram, because the architecture diagram is exactly the artefact most likely to be stale.
A Canberra govtech vendor working toward an ISM-aligned security assessment had a threat model last properly updated 18 months earlier, well before three major feature additions had shipped. Running Claude Code across the current codebase to rebuild the trust-boundary map from actual code, rather than starting from the stale document, surfaced two genuinely new attack surface areas the original model had never covered, including an internal API endpoint added six months prior that had inherited weaker authentication than the team intended. Catching that ahead of the formal assessment rather than during it saved what the security lead estimated would have been a costly remediation cycle under assessment deadline pressure, conservatively valued at $25,000 in vendor and internal time.
The limits of what an agent can actually assess
An agent reviewing code can surface structural issues, missing validation, unclear trust boundaries, inconsistent authorisation checks, but it can't replace a human's judgement on business-context risk, like whether a particular data exposure actually matters given what that data is and who could plausibly access it. Treat the output as a well-organised starting point for a human security reviewer, not a finished risk assessment; the output still needs someone with real security judgement applying business context to what's flagged.
How often to rebuild the model
A threat model rebuilt once and never revisited drifts stale just as surely as the design-doc version it was meant to replace. The practical cadence most genuinely security-conscious teams settle on is tied to release cycles rather than an arbitrary calendar date, rebuilding or at least reviewing the trust-boundary map whenever a new external-facing entry point or a new class of data flow gets introduced, rather than waiting for an annual review to catch months of accumulated drift all at once.
What this isn't
This is not a penetration test and doesn't replace one; static review of trust boundaries catches a different class of issue to active testing against a running system, and a mature security programme needs both, not either in isolation. It's also not a substitute for genuine security expertise reviewing the output; an agent-assisted threat model still needs a qualified human signing off on what it found and what it might have missed.
Automata AI helps Australian engineering and govtech teams keep threat models current using Claude Code, grounded in actual code rather than stale design docs. Get in touch via /contact if your last threat model predates your last three feature releases.
