Auspex: Building Threat Modeling Tradecraft into an Artificial Intelligence-based Copilot

TL;DR

Auspex presents a lightweight, modular AI-based copilot for threat modeling that encodes threat modeling tradecraft directly into prompts, enabling a two-stage process that converts system representations into a structured threat matrix. By avoiding fine-tuning and agent-based add-ons, it emphasizes transferable, prompt-driven architecture across multimodal inputs and threat frameworks, notably mapping threats to the CIA Triad and STRIDE categories. An initial evaluation with cybersecurity experts on real banking systems reports strong agreement on threat realism and low labeling corrective needs (Hamming loss $0\text{-}0.23$), suggesting practical usefulness in accelerating and standardizing threat modeling. The work also discusses limitations and future directions, including back-end augmentations, grounding methods, and shift-left integrations to broaden adoption beyond traditional threat modeling teams.

Abstract

We present Auspex - a threat modeling system built using a specialized collection of generative artificial intelligence-based methods that capture threat modeling tradecraft. This new approach, called tradecraft prompting, centers on encoding the on-the-ground knowledge of threat modelers within the prompts that drive a generative AI-based threat modeling system. Auspex employs tradecraft prompts in two processing stages. The first stage centers on ingesting and processing system architecture information using prompts that encode threat modeling tradecraft knowledge pertaining to system decomposition and description. The second stage centers on chaining the resulting system analysis through a collection of prompts that encode tradecraft knowledge on threat identification, classification, and mitigation. The two-stage process yields a threat matrix for a system that specifies threat scenarios, threat types, information security categorizations and potential mitigations. Auspex produces formalized threat model output in minutes, relative to the weeks or months a manual process takes. More broadly, the focus on bespoke tradecraft prompting, as opposed to fine-tuning or agent-based add-ons, makes Auspex a lightweight, flexible, modular, and extensible foundational system capable of addressing the complexity, resource, and standardization limitations of both existing manual and automated threat modeling processes. In this connection, we establish the baseline value of Auspex to threat modelers through an evaluation procedure based on feedback collected from cybersecurity subject matter experts measuring the quality and utility of threat models generated by Auspex on real banking systems. We conclude with a discussion of system performance and plans for enhancements to Auspex.

Figures (9)

• Figure 1: Auspex end-to-end system threat modeling in its simplest form. Auspex takes in a system representation - an architecture diagram or a textual description - and outputs a threat model of the system.
• Figure 2: Auspex Stages Overview. Stage 1 of Auspex maps system representations to solution descriptions that capture the system components and their relations to each other. Stage 2 maps the solution description to a threat model - a list of threat scenarios for the system that are coupled with information security and threat type categorizations that facilitate threat mitigation.
• Figure 3: Top. (Left) An architecture diagram for AWS Cloud AWSCloud2025, denoted $diag_{cloud}$, used as the input to Auspex. (Right) Screenshots from the Auspex UI asking a user to provide an architecture diagram, and the outcome of uploading $diag_{cloud}$. Once the diagram is uploaded, the user clicks the "decompose diagram" button. Bottom. (Left) Clicking "decompose diagram" results in $diag_{cloud}$ saturating the depicted prompt, which is fed to a generative AI model to yield a long-form architecture description. (Right) The architecture description covers all the components in $diag_{cloud}$ as well as system entry points, data flow, security boundaries, public and private resources, system availability and fault tolerance properties, external dependencies, and storage and data security properties.
• Figure 4: Top. The architecture description is used to saturate the depicted prompt (left), which is passed to a generative AI model that yields the application details (right) - a concise version of the architecture description. Middle. Afterward, the architecture description and application details are used to saturate a prompt (left) that yields a list of key features (right) - aspects of greater consideration for threat modeling. Bottom. Finally, the architecture description, application details, and key features are used to saturate a prompt (left) that yields a list of in-scope components (right) - components that are required to be included in the threat modeling process. The the architecture description, application details, key features, and in-scope components together represent a full textual solution description of $diag_{cloud}$.
• Figure 5: Top. After the solution description for $diag_{cloud}$ is generated, the user selects a cybersecurity role for the next processing stage in Auspex. The three available roles are shown in the UI screenshot. The selection determines which corresponding prompt is used to generate threat scenarios for $diag_{cloud}$. Bottom. The depicted prompt corresponds to the baseline threat modeling role. The prompt is saturated by the solution description and used to generate a list of threat scenarios (left-most column in the threat matrix in Figure \ref{['fig:tmwalk']}).