Over the last year, the way software gets built has shifted in a very real way. Agents now open a meaningful share of pull requests and help ship features in an arvo that used to take a sprint. This isn’t a theoretical “future of work” conversation anymore. It’s already day-to-day for a lot of teams, including ours, and the pace isn’t slowing down.
For security teams, the question is straightforward: Does our current approach to threat assessment still hold up when humans aren’t the only ones writing the code?
In a lot of traditional approaches to threat modelling, I’d say: No, our approaches aren’t holding up.
What’s actually different about agentic development
The headline security folks are reading and worrying about is speed, but that’s not the only thing to worry about. The real shift is the delegation of design decisions.
In a traditional flow, an engineer:
Reads the ticket
Picks a library
Decides where to put the new endpoint
Chooses how to handle errors
Writes the code that reflects those choices
In an agentic flow, a lot of those calls happen inside the agent’s loop, sometimes explicitly, sometimes without anyone noticing a decision was made at all. The engineer shifts from “make the decision” to “review the decision.” That change has a few knock-on effects:
Review can’t keep up. Code lands faster than a human can properly reason about it. “LGTM” becomes a thin layer of approval over choices that nobody really interrogated.
Context becomes part of the security boundary. Prompts, retrieved docs, and tool definitions shape what the agent builds. Prompt injection, poisoned context, and tool misuse are practical problems, not hypotheticals.
Systems drift faster. Each agent-generated PR can look reasonable on its own. In aggregate, you can end up with a direction that nobody consciously picked.
This isn’t an argument to slow agents down. It’s an argument to clarify what we’re delegating and what we’re not.
What this means for the security industry
Most AppSec programs were built around a certain tempo: run SAST tools after code is submitted, perform pen testing before release, and ensure that code reviews are performed by humans before merge. Those controls still matter; they’re just increasingly downstream of where the real decisions get made.
The security industry’s centre of gravity is shifting in two directions at once:
Earlier: toward the design and intent layer, because that’s where agents are now operating.
Continuous: because release cadences that used to be weekly are now hourly.
Security-focused LLMs (particularly frontier models, or the mythical Mythos) are part of that shift. They’re starting to sit in the same loop as the agents they’re meant to secure, reading similar context, reasoning about the same diffs, flagging issues at the same speed. That’s useful. It’s also not the whole answer.
Why threat assessment still matters arguably more than ever
The point I keep coming back to is simple: threat modelling has always lived upstream of the code. It’s a design-time practice. It asks things like:
What are we building, and for whom?
What are the trust boundaries?
What’s the worst plausible thing an attacker (or a confused user, or a misaligned agent) could do?
Which of those things are we choosing to mitigate, and how?
None of those questions gets easier when an agent writes the code. If anything, they get harder because there are fewer natural pauses for a human to stop and think. The compile-debug-fix cycle that used to force reflection can now happen in seconds.
This is where threat assessment earns its keep. A good threat model is design intent made legible. It’s the artefact you can hand to a human, or agent that says: this is what the system is meant to do, these are the boundaries it must respect, and these are the threats we’ve decided matter. Without that, downstream tools, agentic or otherwise, are guessing.
Three reasons threat modelling is more valuable in the agentic era:
It gives agents better grounding. A structured threat model is a dense, high-signal context. It’s usually more useful than a wiki page that hasn’t been touched in three years.
It survives velocity. Threat models change more slowly than code. The data flow into your payments service is basically the same whether a human, an agent, or both writes the next PR.
It sets expectations for AI-native security tools. Agentic software delivery tools work best when they know what’s supposed to be true. A threat model is the closest thing to that source of truth.
Where we go from here
This isn’t a pitch to do more threat modelling. It’s a pitch to do it differently: lighter-weight, more continuous, and closer to the tools engineers (and their agents) actually use. That’s the bet we’re making with threatcl.com, and it’s the conversation we want to have with this community over the next few months.
If you’ve got war stories, good or bad, from running threat modelling in an AI-assisted dev environment, hit reply or reach out to us. We’d genuinely like to hear them.
-Christian Frichot