What do security teams get wrong about using threat models for prioritisation?

Why This Matters for Security Teams

Threat models are supposed to help teams decide what matters first, not simply collect risks in a document. When they are used as a one-time workshop output, prioritisation becomes distorted: teams elevate items that are easy to name and ignore findings that are reachable, exploitable, or tied to sensitive data. NIST guidance on NIST SP 800-53 Rev 5 Security and Privacy Controls makes the underlying point clear: control selection should reflect risk context, not just inventory.

The practical mistake is assuming all threats deserve equal treatment once they appear in a diagram. That is rarely true. A low-complexity issue behind strong authentication, limited network exposure, and non-sensitive data often deserves less urgency than a similar weakness on a public-facing path to privileged credentials or regulated data. For AI-enabled environments, this problem gets sharper because prompt injection, tool abuse, and model output manipulation can alter the attack path without changing the original asset list. Current guidance suggests that threat models should be refreshed as architecture, data flows, and trust boundaries change, not only after incidents.

In practice, many security teams encounter bad prioritisation only after a high-impact path has already been exploited, rather than through intentional risk ranking.

How It Works in Practice

Effective prioritisation starts by tying each threat to three things: exposure, impact, and exploitability. Exposure asks where the path exists, such as internet-facing services, partner connections, or embedded AI tools with execution authority. Impact asks what happens if the threat succeeds, including data loss, privilege escalation, fraud, or unsafe automated action. Exploitability asks how much effort an attacker needs, which should include preconditions, trust assumptions, and control gaps. MITRE’s MITRE ATLAS adversarial AI threat matrix is useful when the system includes models or agents, because it helps teams distinguish model manipulation from ordinary application abuse.

A workable process usually includes the following:

• Map the asset, trust boundary, and attacker goal in one sentence.
• Rate whether the path is public, partner-reachable, internal-only, or admin-only.
• Tag the data or action at risk, including credentials, secrets, customer records, or tool execution.
• Identify whether an existing control breaks the path, not just whether a control exists on paper.
• Re-rank findings when architecture, model behaviour, or access scope changes.

For AI and agentic systems, the model itself is not the only target. Attackers may use the model to reach downstream systems, which means the true priority is often the privileged action, not the model prompt. That is why frameworks such as the CSA MAESTRO agentic AI threat modeling framework are increasingly relevant when tools can call APIs, issue commands, or retrieve sensitive context. Security teams should also keep an eye on active threat intelligence from CISA cyber threat advisories so prioritisation reflects observed attacker behaviour, not just theoretical abuse cases.

These controls tend to break down when teams reuse a generic threat model across very different environments because the exposure and blast radius assumptions no longer match reality.

Common Variations and Edge Cases

Tighter prioritisation often increases analysis overhead, requiring organisations to balance decision quality against speed and planning cost. That tradeoff is real, especially in fast-moving delivery pipelines where teams want a lightweight answer instead of a deep review. Best practice is evolving toward “good enough to decide” models rather than exhaustive documentation, but there is no universal standard for how much detail is enough.

One common edge case is when a threat looks severe in theory but sits behind compensating controls such as strong segmentation, short-lived credentials, or restricted tool permissions. Another is when a modest-looking flaw becomes high priority because it sits on a chain that leads to an agent, a secrets store, or a customer-facing workflow. In AI systems, the same attack class can shift in priority depending on whether the model is advisory only or can actually trigger external actions. Anthropic’s report on the first AI-orchestrated cyber espionage campaign shows why this matters: once AI is used to accelerate reconnaissance, exploitation, or social engineering, the attack path can change quickly, and the priority should follow the path, not the label.

Teams also get this wrong when they rely on static severity scoring without rechecking assumptions after code changes, new integrations, or expanded access. If the model is stale, prioritisation will be stale too. That is especially true when the threat model does not capture how credentials, tokens, or delegated permissions are actually used across the environment.

Related resources from NHI Mgmt Group

• What do security teams get wrong about using AI agents for threat hunting?
• What do security teams get wrong about threat detection in IAM?
• What do security teams get wrong about using LLMs for exact calculations?
• What do security teams get wrong about trust in zero-trust access models?