Drel vs. traditional threat modeling tools
STRIDE-style tools were built for AppSec — they model dataflows and trust boundaries between services. They do not model agentic graphs, autonomy gradients, MCP servers, or AI Committee dispositions. Here is where Drel fits, and where the existing tools still belong.
We are going to be unfashionably specific. Threat modeling tools as a category — the STRIDE-derived, dataflow-diagram-centred tools your AppSec team has been using for ten years — are good at the thing they were built for: enumerating threats against services and components, applying STRIDE/LINDDUN/PASTA, and producing developer-facing mitigations.
They were not built for the AI Committee's problem. The AI Committee's problem is governance over a graph of model, tools, retrieval and agency — and the artifact the Committee owes is a defensible decision record, not a per-service threat list.
Drel is not a replacement for your AppSec threat modeling tool. It is the surface that did not exist for AI governance review. Both can sit in the same organization.
What traditional threat modeling tools do well
- Dataflow diagrams between services, with trust boundaries that AppSec engineers recognize.
- STRIDE enumeration per element. A long list of threat candidates per process, store and flow.
- Per-developer assignment of mitigations into Jira.
- Integration into the SDLC: PR triggers, ADR templates, design-doc check-ins.
This category exists because application threat modeling is a continuous part of shipping software. The tools have matured around that workflow.
What they miss for AI systems
- The unit of analysis is wrong. AppSec threat modeling reasons about services, processes, and stores. AI threat modeling reasons about a graph of model, tools, retrieval surface, planner, approval boundaries, and memory. An agent is not a process; an MCP server is not a service; a retrieval surface is not a data store. The primitives mismatch.
- STRIDE alone does not cover the failure modes. Prompt injection, indirect prompt injection, tool poisoning, planner subversion, training-data inference, autonomy escalation, and unsafe tool composition do not map cleanly to Spoofing/Tampering/Repudiation/Info-disclosure/DoS/Elevation. OWASP Agentic Top 10, OWASP LLM Top 10, MITRE ATLAS and CSA AICM exist because the AppSec taxonomies were not sufficient.
- The output is not a disposition. A traditional tool produces a threat list and per-threat mitigations. An AI Committee needs a Risk Disposition memo: decision, rationale, required controls grouped by lifecycle gate, residual risk acceptance, evidence gaps, re-assessment triggers, sign-off log. Different artifact entirely.
- Framework mapping is shaped for AppSec. OWASP ASVS, NIST 800-53, SOC 2. The frameworks AI Committees are accountable to — ISO/IEC 42001, EU AI Act Article 9, NIST AI RMF, OWASP Agentic Top 10 — are not first-class.
- The reviewer is wrong. AppSec tools are built for security engineers inside the SDLC. The buyer of an AI review is the AI Committee — CISO, AI Governance, Sec Arch, DPO, Business Owner, CISO delegate. They do not ingest threat lists; they ingest dispositions.
Side by side
| Capability | Drel | Traditional threat modeling tool |
|---|---|---|
Primary unit of analysis | Agentic graph: model, tools, retrieval, planner, approval boundaries, memory. | Dataflow diagram: services, processes, data stores. |
Threat taxonomy | OWASP Agentic Top 10, OWASP LLM Top 10, MITRE ATLAS, OWASP AIVSS, CSA AICM, MAESTRO, IBM AI Risk Atlas. | STRIDE, LINDDUN, PASTA, ASVS. |
Primary output | Risk Disposition memo + audit pack. | Threat list + per-threat mitigations. |
Primary reader | AI Committee (CISO, AI Gov, Sec Arch, DPO, Business Owner). | AppSec engineers, devs in the SDLC. |
Framework mapping | ISO/IEC 42001, EU AI Act Art. 9, NIST AI RMF, OWASP Agentic Top 10, AIUC-1. | OWASP ASVS, NIST 800-53, SOC 2. |
MCP server modeling | First-class component type with tool surface, transport, auth boundary. | Modeled as a generic service if at all. |
Re-assessment triggers | Typed events (model change, tool added, autonomy increase, vendor change). | Manual re-review prompted by PR review or release calendar. |
Lifecycle gates | Controls grouped by before-pilot, before-production, ongoing. | Per-release mitigations. |
Coexists with AppSec threat modeling | Yes — Drel is not a replacement for the AppSec process. | — |
How the two should coexist
In most organizations we work with, the AppSec threat modeling tool stays where it is. Drel sits next to it, owned by AI Governance or Security Architecture, and takes the AI-system-shaped questions out of the AppSec backlog. The boundary is clean enough:
- Drel owns:the AI Committee's disposition for every assessed AI system; the framework-mapped evidence pack; the re-assessment trigger register.
- The AppSec tool keeps: service-level threat modeling, SDLC integration, per-release mitigations.
- What flows between them: Drel can reference an AppSec threat model as a source artifact in the audit pack, and conversely an AppSec ticket can cite a Drel control id.
See the disposition this produces
The Risk Disposition Drel produces for an enterprise procurement agent is public. Read it, then decide whether your current threat modeling tool gives you the same artifact.
A note on scope: Drel reviews assessed systems against documented architecture, configuration and intent. It does not ingest live telemetry from production environments. Dispositions reflect the assessed system at the time of review and the re-assessment triggers that govern when the disposition must be revisited.