We Don’t Need Another Threat Modeling Framework. We Need to Run Them Efficiently With Agents.

By Julien Brouchier

Jul 2026 • 2 min read

Threat modeling has evolved by giving security teams better ways to see risk. STRIDE gave software designers six durable categories for asking what could go wrong. MITRE ATT&CK^® organized observed adversary behavior into tactics and techniques. MITRE ATLAS^™ extended that behavioral knowledge to AI-enabled systems.

Now agentic AI is driving another wave. The Cloud Security Alliance’s MAESTRO examines risk across the layers of multi-agent architectures. Adam Shostack’s PHANTOM-B provides an LLM-specific threat-elicitation tool. Vinaya Vasudevan’s emerging SAILORS technique adds to a growing body of work adapting threat modeling to agentic risk.

These approaches are not interchangeable: some are knowledge bases, others are elicitation tools or modeling frameworks. But they share an important direction, they improve how we model a new kind of system. However, they are all built with one common point: they are meant to be run by humans.

They are useful to produce a risk determination but also to provide a common language for practitioners to talk with. A threat modeling workshop is a good excuse to get a product manager, architect, developer, and security engineer in the same room and talk about security. However all of this might be a burden if all of these are actually AI agents, which lead us to the real question:

Who or what is expected to perform the threat modeling?

An agentic-system threat model is not necessarily an agent-native threat-modeling system.

The dominant interface for threat modeling is still human: a taxonomy to study, a matrix to navigate, a checklist to complete, or a workshop to facilitate. A practitioner must reconstruct the architecture, gather evidence, select relevant threats, challenge assumptions, prioritize risks, map mitigations, and remember to revisit the result later.

But software no longer changes at workshop speed. Agentic applications continuously change their models, prompts, tools, permissions, memories, data sources, and agent-to-agent trust relationships. A threat model completed on Monday can be obsolete after Tuesday’s pull request. We therefore need threat-modeling methods designed from first principles for AI security agents to execute.

This means more than putting STRIDE into a prompt. A chatbot can produce a plausible list of generic threats. An AI security engineer must determine what evidence to collect, ground its conclusions in the real system, distinguish facts from assumptions, reason across attack paths, prioritize meaningful risks, translate them into testable requirements and controls, verify remediation, and escalate decisions that require human judgment.

This is what we have built into Trent AI Security Engineer. We’ve optimized our agent to produce the same output as a human, but with a methodology optimized for the agentic system it runs on. Our agent can ask you clarifications, can reason about the code, and will talk to you in the language you understand (i.e. we talk the language of STRIDE, Attack chains etc), but we reason deeper than a human would.

Trent treats threat modeling not as a document to finish, but as a security-engineering loop to run: Model → Prioritize → Remediate → Verify → Re-model →

Humans remain accountable for business context, risk acceptance, and difficult trade-offs. The agent performs the repeatable, evidence-heavy analysis at software speed. We do not only need better threat models for agents (and this is why we did not write one more methodology to add to the bandwagon). Instead, we need threat modeling that agents can run.