Platform · AI Assistant · AI Threat Modeling
Model with AI reads the architecture diagram you have open and proposes a whole threat model: STRIDE elements registered from the shapes, threats drawn from your library before anything new is invented, and mitigating controls mapped from the catalog you actually run. Each phase arrives as one approval card per batch, so your judgment goes on the threats, not the data entry.
The definition
AI threat modeling uses a language model to enumerate what can go wrong with a system, working from a model of that system rather than from memory. Done naively, it has a quality problem: a chatbot handed a description will invent plausible-sounding threats with no anchor to real components, no connection to your controls, and no way to track what happens next.
Alvor's studio is built against those failure modes. It starts from the actual data flow diagram, registering shapes as typed STRIDE elements: components, datastores, data flows, external entities, and trust boundaries. When it enumerates threats it searches your threat library first, reusing entries seeded from MITRE ATT&CK, OWASP, CAPEC, and NIST before inventing anything new. When it maps mitigations it uses your control library and never invents control identifiers.
And nothing lands without you. Each phase arrives as one approval card for the whole batch: readable, rejectable, audit-logged. Approved threats anchor to the elements they target, mapped controls become required, threat-driven build controls on the project, and coverage recounts live as the register grows.
How it works
Diagram shapes become STRIDE elements with display ids: components, datastores, data flows, external entities, trust boundaries.
Threats enumerated per element, reusing your threat library before inventing new entries, each with severity and a framework reference.
Mitigating controls from your control library, primary and supporting. Mapped controls become required, threat-driven build controls.
One card per batch. Statuses update, coverage recounts, and the threat library grows as you model, deduplicated automatically.
Every threat targets a registered element (C1, DS1, DF1, TB1), not a vague description. If the diagram changes, you can see what is affected.
Your threat library, seeded from MITRE ATT&CK, OWASP, CAPEC, and NIST, is searched before the model invents anything new.
Mitigations come from the control catalog you operate. The studio never fabricates a control id, and mappings become required build controls.
One approval card per phase, not one per row. Typing 'yes' in chat approves nothing; only the button does.
Element counts, threat statuses (open, mitigated, accepted, not applicable), and the unmitigated count update every turn.
Past high-level design the studio will not modify a baselined model. That change is governed and belongs to a human.
The studio proposes; you approve. Every write pauses on a batch approval card, every action is audit-logged, and a revoked permission holds mid-conversation.
Questions
Yes, with the right constraints. A model can enumerate threats methodically and tirelessly, which is exactly the part of threat modeling humans rush. What it cannot do is own the risk decision. Alvor's studio reads your actual diagram, proposes elements, threats, and control mappings in reviewable batches, and leaves acceptance, severity judgment, and design changes with your team.
Keep exploring
Get started
Whether you lead security, run IT, manage compliance, or sit in the C-suite - we'll show you your view.