A security approach that maps how data, trust, and authority move through systems instead of starting from static network or device boundaries. For AI-heavy environments, it helps identify prompts, agents, integrations, and identity handoffs that create exposure.
What Flow-Based Threat Modelling Focuses On
Flow-based threat modelling starts with movement, not boundaries. It asks how data, trust, privilege, prompts, and control decisions travel across services, integrations, agents, and external dependencies, then identifies where those flows can be intercepted, altered, or abused.
That framing is especially useful in systems where a single request can cross multiple trust domains. In AI-heavy environments, the important question is often not “what machine sits where?” but “what authority moved, who or what received it, and what could that recipient do next?”
Why Flow Analysis Changes the Threat Picture
Static diagrams can miss the real exposure because many failures emerge only when trust crosses a boundary in motion. A system may look segmented on paper but still expose sensitive actions through implicit trust between services, tokens, agents, or delegated workflows.
Flow-based modelling makes hidden dependencies visible. It can reveal that a prompt injection is dangerous not only because of content manipulation, but because the injected instruction may influence an agent that already has tool access, a delegated token, or a downstream integration path. The same logic applies to service-to-service calls, external APIs, token exchange, and identity handoffs.
When the subject is AI or automation, the Threat Modelling AI Agents guide is a useful companion because it treats trust boundaries and identity maps as first-class modelling inputs. For a broader breach-oriented perspective on how attackers abuse machine access and secrets, see The State of NHI & AI Agent Breach Report 2026.
What Practitioners Model in Real Systems
The core artefacts are flows, not components. Practitioners trace where data originates, where it is transformed, which actor or service is trusted to act on it, and which identity, token, or permission enables the next hop. That includes human users, workloads, APIs, bots, and AI agents when they participate in the same execution path.
Useful models often include prompts, tool calls, message queues, token exchanges, API calls, approval steps, and cross-domain callbacks. Each flow can create a different exposure: disclosure, tampering, privilege escalation, impersonation, or unintended delegation.
For delegation-heavy designs, RFC 8693: OAuth 2.0 Token Exchange is a relevant reference because it defines how delegated authority moves between actors. In cloud and enterprise environments, NIST SP 800-53 Rev 5 Security and Privacy Controls helps anchor the identity, access, logging, and configuration controls that usually underpin those flows.
Common Failure Modes and Design Trade-offs
Flow-based threat modelling is strongest when it exposes assumptions that are easy to miss in component-by-component reviews. A path may look low risk until you notice that a token is reusable, a trust decision is implicit, or an integration can forward more authority than it should.
The trade-off is that flow models can become sprawling if teams confuse every possible path with a material path. The useful model is the one that highlights meaningful authority movement, sensitive data movement, and control transfer, then drops incidental hops that do not change the threat picture.
For modern AI and agentic environments, MITRE ATLAS adversarial AI threat matrix is a strong external reference for attack patterns such as prompt injection, memory manipulation, and tool misuse. For the broader agentic control problem, the OWASP Agentic AI Top 10 helps frame identity and privilege abuse as part of the threat path rather than an afterthought.
How This Term Is Used in Practice
Flow-based threat modelling is most valuable during architecture review, AI system design, integration planning, and incident analysis. It gives teams a way to ask whether a control really protects the path where authority moves, instead of assuming that perimeter placement alone is enough.
It is also useful when a system mixes human approvals with automated execution. In those designs, the model should make clear where authority changes hands, whether the next actor can escalate beyond the original intent, and whether logging is sufficient to reconstruct what happened later.
For organisations building AI-enabled systems, NIST AI Risk Management Framework provides a governance lens for the wider AI risk context, while CSA MAESTRO agentic AI threat modeling framework gives a more agent-focused structure for analysing trust, autonomy, and orchestration.
Risk and Threat Considerations
Flow-based threat modelling is valuable because the most serious failures often happen at the handoff, where data or authority crosses from one trust domain to another. If those transitions are not explicit, attackers can exploit implicit trust, overbroad delegation, or hidden propagation of credentials and state.
Failure mechanism: Sensitive flows may carry more authority than intended, allowing prompt injection, token abuse, lateral movement, or unauthorized tool use to succeed through a trusted path.
Impact: The result can be data exposure, privilege escalation, fraudulent action, persistence across systems, or compromise that is hard to trace because the failure occurred across multiple linked components rather than in one obvious control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Flow modelling often centers on how delegated authority moves across agent steps. |
| Recommendation — Model each handoff for privilege transfer and restrict agent actions to the minimum required authority. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Flow-based modelling highlights where authority exceeds what a path needs. |
| AU-2 — Event Logging | Tracing flows requires records of handoffs, delegation, and control changes. | |
| SC-7 — Boundary Protection | The subject maps how trust crosses boundaries rather than relying on static perimeters. | |
| Recommendation — Apply AC-6 to reduce each flow to the minimum permissions required for execution. Log authority transfers and sensitive flow events so you can reconstruct cross-domain activity. Use SC-7 to define and enforce trust boundaries at the points where flows cross domains. | ||
Practitioner Guidance
What to watch for: Model the paths where authority changes hands, not just the systems involved. The most useful reviews focus on delegations, reusable tokens, cross-domain integrations, and AI or automation steps that can act on behalf of something else.
Practitioner takeaway: If a flow can carry trust, privilege, or sensitive data into a less trusted context, that flow deserves explicit modelling even when the underlying components look well secured in isolation.
Related resources from NHI Mgmt Group
- How can organisations tell whether their threat modelling is actually improving security?
- Who should be accountable when fraud occurs through an OTP-based flow?
- Who should approve policy-based recovery actions after a threat is detected?
- Who is accountable when a wallet-based verification flow is used incorrectly?