clear and avoids unnecessary complexity.

AI System Architecture Threat Modeling In selecting a

threat modeling methodology, we highlight some primary approaches for riskcentric framework
that aligns technical analysis with business impact such as PASTA, MITRE ATLAS as chosen
framework includes or can easily integrate adversarial test case design and STRIDE & STRIDE AI
for developer-friendly threat taxonomies. Regardless of the methodology chosen, the essential
desired outcome remains the same: to systematically map threats to the reference AI
architecture defined by the SAIF Risk Map, covering the core components of application, data,
model, and infrastructure. The goal is to conduct a comprehensive threat analysis that leverages
both STRIDE threat categories and AI-specific threats. These identified threats serve as the
foundation for designing threat- and attack-driven testing, which is used to uncover control
gaps, weaknesses, and vulnerabilities. The likelihood and impact of these vulnerabilities, both
technical and business, form dimensions of risk that must be evaluated and mitigated
accordingly. When adopting a risk-based methodology like PASTA, the process begins with
defining the business objective: securing AI-powered services that deliver critical functionality
(e.g., personalized recommendations, predictive analytics, autonomous decision-making) while
mitigating risks such as loss of customer trust, regulatory penalties, and competitive threats
from model compromise. Using the SAIF risk map, Stage 2 of PASTA establishes a
comprehensive technical scope, covering users, applications, models, data, and infrastructure.
At stage 3 of PASTA we seek to decompose the architecture into four key layers and map high-
level data flows. During PASTA stage 4 we seek to conduct a detailed threat analysis for AI-
specific threats. PASTA stages 5 and 6 focus on identifying vulnerabilities through targeted
testing and simulating realistic attack scenarios. Finally, during PASTA stage 7 assesses the
severity of unmitigated risks and outlines mitigation strategies based on industry best practices.
Alternatively, if STRIDE is adopted directly as the primary threat modeling approach, the process
differs, as STRIDE serves as a threat classification framework rather than a full endto-end risk
centric threat modeling methodology like PASTA. In this approach, the six OWASP AI Testing
Guide Version 1.0 Page 19 of 250 STRIDE threat categories can still be systematically applied
across the SAIF architecture components, application, model, data, and infrastructure, to ensure
comprehensive threat coverage. However, using STRIDE alone requires additional steps to
incorporate risk scoring, simulate realistic attack scenarios, and align threats with business and
operational context, capabilities that PASTA integrates inherently into its methodology. In
PASTA’s seven-stage process, we’ll enhance the Threat Analysis phase by incorporating MITRE
ATLAS’s database of AI-specific adversarial tactics, such as evasion, poisoning, model extraction,
and inference attacks, into our threat mapping. This integration ensures our risk- centric model
aligns with business priorities and technical scope, while directly informing a targeted suite of
offensive AI tests against the most critical attack vectors. AI-specific adversarial tactics such as
evasion, poisoning, and model extraction are prime targets for specialized AI security
assessments like red teaming. This focus is formally captured in the OWASP AI Red Teaming
Framework [14], which defines how to simulate and evaluate these attack vectors against AI
systems. Effective threat modeling begins by scoping the analysis around the critical assets you
must protect. To do this, you first decompose the system’s architecture into its essential
components, services, data stores, interfaces, and supporting infrastructure. You then map out
how these pieces interact by drawing data flow diagrams that trace information end-toend,
highlight entry and exit points, and establish trust boundaries. By visualizing where data is
stored, processed, and transmitted, you can pinpoint the exact assets at risk and systematically
identify potential threats and vulnerabilities against each component and boundary. This
structured approach ensures your threat model remains focused, comprehensive, and aligned
with the organization’s security priorities. These scoping and decomposition activities,
identifying critical assets, breaking the system into core components, and using data flow
diagrams to map end-to-end interactions and trust boundaries are foundational steps shared by
many threat-modeling methodologies, from STRIDE to PASTA and beyond, ensuring a consistent,
thorough approach to identifying and prioritizing risks. By focusing on the SAIF-aligned layers,
Application, Data, Model, and Infrastructure, we intentionally keep our threat analysis at a high
architectural level. This ensures broad coverage of AI-specific risks without delving into every
sub-component of the system. In this AI threat model, we map threats, including AI-specific
threats across the application, data, model, and infrastructure layers to ensure comprehensive
coverage. Threat mitigations are defined as testable requirements, with validation activities
documented in this guide. The goal is to provide a complete set of tests to assess the AI system’s
security posture against the identified threats (Note). Note: It’s important to note that the
OWASP AI Testing Guide is scoped to post-deployment security assessments and does not cover
the broader MLOps lifecycle. For teams seeking guidance on embedding adversarial robustness
tests earlier during data preparation, model training, and CI/CD pipelines, we recommend the
white paper in ref [16] Securing AI/ML OWASP AI Testing Guide Version

decomposition in threat modeling is the process of breaking down a system into its key
components, data flows, assets, and trust boundaries. It helps identify where threats can occur,
supports systematic threat enumeration (like STRIDE), highlights the attack surfaces allowing to
identify all potential entry points and exposure surfaces. Following PASTA Stage III, we perform a
decomposition of the AI architecture, organizing it into the four layers and component groups
defined by SAIF: Data, Model, Infrastructure, and Application, enabling a structured and
comprehensive threat analysis. The SAIF (Secure AI Framework) model provides a high-level
architectural view of AI systems, designed to capture the broad categories of components, such
as data, model, application, and infrastructure that are critical to securing the AI lifecycle. While
this abstraction is valuable for establishing a common baseline for AI security, it is not intended
to offer detailed decomposition of every specific implementation pattern. The approach we
recommend for AI threat modeling begins with a high-level architectural view, such as the one
provided by frameworks like Google’s SAIF or OWASP AI Security Matrix to establish
comprehensive coverage across data, model, application, and infrastructure layers. From there,
the model should be refined to a level of detail that reflects the specific deployment context of
the AI system, including the technologies, data flows, and integration points involved. This
deeper level of modeling is essential for identifying the actual attack surface, tied to the specific
AI use case. For example, in a Robotic Process Automation (RPA) workflow for automated
employee expense reimbursement, threat modeling should capture exposures in third-party
integrations, data handling, and business logic as covered in [21]. In more complex architectures
such as multi-agent systems (MAS) or Retrieval-Augmented Generation (RAG) (Note) pipelines,
threat modeling must e