Your Threat Model Was Stale the Day You Saved It
By Arshan Dabirsiaghi
Every security team I talk to believes in threat modeling. Almost none of them do it at the scale they ship.
The reason is mechanical. A good threat model takes a skilled person days to build. It captures how an application is exposed, where its trust boundaries sit, what data it touches, and where an attacker would push. Then someone ships a change, and the document starts drifting from reality.
Six months later that threat model describes an app that has changed underneath it. So when you actually need it, during an incident or a review, you have to spend time re-validating it (and hoping the person who wrote it is still around to help).
The standard pattern is that most threat models get written once, for the handful of applications important enough to justify the effort, and then they age out. The thousands of other services in your portfolio never get one at all. For most software the workaround was a gate: a three-question intake that asks whether the change touched sensitive data, whether it was internet-facing, and whether it was anything more than an internal tool.
So comprehensive threat modeling across your entire exposed software surface was already a losing race. AI coding agents make it worse, because your developers are shipping more software, faster.
The answer is agentic threat modeling.
What we already build
Pixee has been generating threat models under the hood for a while to power our triage and fix agents.
For every repository we work in, we build two views.
- The outer view is the system as a whole: how it's exposed to the internet, how it's deployed, and where it sits on the network.
- The inner view is the specific code: the entry points, the authentication and authorization paths, and the places sensitive data moves.
We build both against STRIDE, the same framework your architecture team already uses. Understanding entry points, authN/authZ strategy, and asset sensitivity is what lets a reader (human or agent) localize on what matters, surface the threats everyone overlooked, and squash the noise around them.
These models are the working context our system reasons over every time it triages a finding or reviews a design. Starting now, that context is yours to see and use directly.
What it looks like
The model is derived from the code itself, not from a README that may or may not still be true. Point Pixee at a repository and it reads how the app is actually reached, how it authenticates, and which data is worth protecting, then keeps that read current as the code changes.
Here is the generated Threat Model tab for a public application. It opens with a System Overview, an Exposure profile, and an Attack Surface Summary, all generated by the agent and regenerated as the code moves.
The Exposure profile answers the questions you would otherwise spend an afternoon chasing: is it internet-facing, how is it deployed, where does it sit on the network. For a public, intentionally vulnerable demo app, it reads a directly exposed web application on port 3000, notes the container and cloud deployment paths, and flags that the app is meant to be reachable.
The Attack Surface Summary is where it earns its keep. It enumerates the assets that actually matter and ties each one back to the code that touches it: authentication secrets and signing material, user credentials and session data, payment and wallet records, personally identifiable information, and the configuration and keys that govern how the app behaves. Read top to bottom, it's a map of where an attacker would go and what they'd get, with the file paths already attached.
The everyday problem it solves
This is built for one situation in particular. You own security for more applications than you could name from memory. Something comes up on one of them, a pull request, an audit request, a report from a bounty hunter, and you have thirty minutes to form an opinion about an app you've never opened.
Today that starts with reading code and asking around. With a current threat model in front of you, it starts with the answers already in hand: how the app is exposed, how it authenticates, which data matters, and where to look first. You get oriented in the time it used to take just to find the right repository.
Enterprise security teams are constantly asked to parachute into an app, out of the thousands they manage, and add value fast. We built this for the agents doing that work, and for the coffee-powered intelligence sitting next to them.
Why this is more than a feature
A threat model on its own is useful. A threat model wired into the rest of your security program is a different thing.
Take two applications with the identical finding, a SQL injection in a query builder. In one app, that code sits behind three internal services and touches no regulated data. In the other, it's one hop from a public endpoint and reads customer PII. Same finding, opposite priority, and the only thing that tells them apart is the threat model.
That's why we built this as shared context, not a standalone report. The same model that lets Foresight review a design before code is written also tells our triage which findings are genuinely exploitable in your environment, and tells our remediation how to fix them in a way that fits the app. One context graph, feeding both the proactive and the reactive side of your program, and all of it compounds as your agents keep working. Every view we add is another step toward a complete AppSec context graph.
What it doesn't do
A generated threat model gets a security team oriented in minutes instead of days. It's a strong starting point, not a final verdict. Your reviewers will correct it and go deeper on the parts that matter, and it sharpens as the code it reads gets clearer. It's there to make your experts faster on their first pass, not to stand in for their judgment.
Available now
If you're managing more applications than your team can threat-model by hand, which is nearly everyone I talk to, this is live in Pixee today.
