Back in May, I wrote about the evolution of threat modelling in the agentic era. In particular, as code is generated faster than humans can review it, the workflows used to manage your threat models will have to step it up a gear. This post is the follow-up to pull back the curtain on how we’ve been leveraging Claude Code combined with Threatcl to threat model, well, Threatcl itself!

We’re demonstrating this loop against a side project I’ve been tinkering with, but to get started, all we needed was:

In this first video, we demonstrate the threat-for-code command against an earlier git commit in the project (we time-travelled back ⌚). This command analysed the current codebase and performed a preliminary threat analysis. It then called the MCP server to understand whether any of our centrally documented threats or controls in Threatcl Cloud related to this new model. After we reviewed the summary, we got Claude to update our .tm.hcl file.

The next phase, and the workflow we leverage more frequently, is using the threat-drift command. This command pulls apart the changes between two points in time in our git repo, then teases out any aspects of the currently documented threat model and the code changes. Finally, you can see us pushing this updated threat model to Threatcl Cloud for further review.

Here’s where the format choice (i.e. the Threatcl HCL specification for threat modelling) pays off. The proposed model changes are HCL. The Claude agent writes them the same way it writes any other code: edits the .tm.hcl file locally, validates it with the CLI, and helps push it up into the cloud.

No canvas. No export step. No “now go update the diagram in another tool.” The threat model changes in the same PR, reviewed by the same humans (or agents), merged in a similar process.

This is not about “AI writes your threat model so you don’t have to think.” The model is still yours: authored in a format you can read, reviewed by people accountable for it, versioned in your repo, exportable as needed. The agent is an input layer.

This philosophy is central to Threatcl - be AI-native, align with the tools and workflows engineers already use, don’t simply bolt on arbitrary AI features to proprietary threat modelling products.

The plugin is ready, although it may have some rough edges. If you’re using Claude Code:

If you try /threat-drift on a repo with a six-month-old threat model, I'd genuinely like to hear what it finds. That gap between what the model says and what the code does is the whole reason this exists.