Apiiro Blog  Introducing AI Threat Modeling
Product, Technical

Introducing AI Threat Modeling

Ella Bor
Data Science Team Lead at Apiiro
Pavel Borovsky
Security Research Engineer
Published March 23 2026 ¡ 15 min. read

Threat Analysis and Prevention That Understand Your Software Architecture – From Design, Code, and Runtime.

In the modern software development lifecycle (SDLC), the distance between a concept and its deployment has collapsed. Driven by AI-assisted coding and high-velocity continuous delivery, code is now generated and shipped faster than human-led security processes can ever hope to review. This shift accelerates the evolution of application security from Detection to Autonomous Prevention — a move from reactive scanning to proactive, secure-by-design development from the first keystroke.

A few months ago we took a major step toward this vision with the launch of the Apiiro Guardian Agent. In building this agent, our core thesis was simple: AI needs a map. To provide meaningful actionable security guidance, the AI coding agent must be grounded in the context of the application’s unique data flows, architecture, and runtime environments as well as in the organization’s policies, processes and business. Since then, Guardian Agent “secure prompt” capability has helped to create thousands of code commits with no vulnerabilities or compliance violations.

However, for fulfilling the autonomous prevention promise, looking at the code implementation alone is not sufficient. The most critical security failures are often not implementation bugs, but fundamental design flaws. Traditional threat modeling — the process of identifying these threats and defining the appropriate countermeasures to avoid them — is one of the last remaining manual bottlenecks in the SDLC. It relies on manual processes, static diagrams, intermittent workshops, stale tasks, and expert-level security knowledge that cannot scale with AI-driven development.

Today, we are excited to announce a significant expansion of the Guardian Agent’s capabilities: AI Threat Modeling. By leveraging the Apiiro Data Fabric, Guardian Agent can now automatically generate contextualized, dynamic and actionable threat models directly from product specifications and implementation tickets. This capability ensures that security considerations are foundational to every project, preventing vulnerable and non-compliant code from ever being written.

The Scaling Crisis of Traditional Threat Modeling

Threat modeling has always been a high-value exercise. Identifying a security risk during the design phase is much cheaper and less risky than fixing it after it has reached production. Yet, despite its importance, the traditional approach to threat modeling is fundamentally broken in the modern enterprise:

  • It is manual and slow: A thorough threat model can take days or weeks of manual analysis. In a world where a feature is conceptualized on Monday and deployed by Friday, a threat model is often obsolete before it is even finished.
  • It relies on static diagrams: Most threat models are built on static Data Flow Diagrams (DFDs) that are disconnected from the actual code. As the system evolves, these diagrams drift, leading to security models that no longer reflect reality.
  • It lacks context: Traditional tools often rely on generic templates or developer questionnaires. Without an understanding of the existing software architecture or runtime behavior, these models either miss critical risks or flood developers with irrelevant “checkbox” requirements.
  • It is the ultimate bottleneck: As engineering teams scale, the ratio of security practitioners to developers widens. Strategic governance becomes impossible when security teams are buried under a mountain of manual design reviews.

AI Threat Modeling with the Guardian Agent

The Apiiro Guardian Agent was designed to address these challenges by operating as a “Principal Security Engineer” embedded throughout the SDLC. To do this effectively, the Agent relies on the Apiiro Data Fabric, a unified foundation consisting of our Software Graph™ and Risk Graph™.

This foundation provides the autonomous reasoning needed for AI Threat Modeling:

  1. Deep Code Analysis (DCA): Continuously mapping code architecture, data flows, and dependencies.
  2. Code-to-Runtime (C2R): Linking code components to their actual runtime performance and exposure.
  3. Organizational context: Understanding specific internal policies, compliance standards, and risk tolerances.

By adding AI Threat Modeling to its capabilities set, Guardian Agent moves the starting line of security even further “left” – from the first commit to the first keystroke of a product specification.

How AI Threat Modeling Works

1. Initiating a Threat Model

AppSec engineers or developers can initiate an on demand threat model for any new or existing design/feature by providing Guardian Agent with design documents, architectural diagrams, or even images of whiteboards. This can be done via the Apiiro portal or through the Guardian Agent chat.

In addition to manually initiating, organizations can guide the Guardian Agent to autonomously initiate threat models without an explicit human trigger:

  • Setup the Agent for “Always-on” continuous monitoring of all the design tickets opened in the organizations and autonomously trigger automatic threat model when relevant — leveraging the Apiiro Data Fabric integration with the organization’s ticketing systems, such as Jira, GitHub and Azure DevOps
  • Guide the AI coding agent (e.g. Claude, Cursor, Codex) to autonomously trigger a threat model before implementation of a new feature, as part of the planning phase, using Guardian CLI, skills or MCP server.

Setup the Agent for “Always-on” continuous monitoring
Trigger threat model through the Guardian Agent in the IDE and in the Apiiro portal

2. Contextual Design Analysis

New feature implementation rarely starts from an empty state. In the vast majority of cases, features are added to an existing application codebase, with its own unique characteristics and controls. Unlike standalone threat modeling tools that start with a blank canvas, AI Threat Modeling uses the information already present in your code. It analyzes the intent of the new feature design and cross-references it with the existing state of your software estate.

It uses the Apiiro Data Fabric for contextual grounding to understand, for example:

  • What repositories and services will be affected? (detected automatically or manually)
  • Does this service already handle Sensitive Data (PII/PHI)?
  • Is this repository internet-exposed?
  • What are the existing authentication and authorization mechanisms in place?

3. Reasoning Over a Robust Threat Library

There is no one way of conducting a threat model. Each organization and AppSec team has their own favored framework for guiding the threat model analysis. Therefore the Guardian threat modeling is grounded on a comprehensive deterministic threat library encompassing and cross-referencing the following multiple industry-standards:

Framework/ Standard
STRIDEClassifies each threat by type (Spoofing, Tampering, Repudiation, Info Disclosure, DoS, Elevation of Privilege)
CIA TriadFlags which security properties are impacted – Confidentiality, Integrity, Availability
CAPECMaps to the attack pattern used to exploit the weakness (e.g. CAPEC-125 Flooding)
CWELinks to the specific software weakness (e.g. CWE-400 Resource Exhaustion
OWASP Top 10Ties to the relevant OWASP risk category (e.g. A04:2021 Insecure Design)
MITRE ATT&CKReferences the adversary technique (e.g. T1499 Endpoint DoS)
OWASP ASVSPoints to the verification requirement for testing (e.g. V5.1.1)
NISTMaps to the applicable NIST security control (e.g. AC-3 Access Enforcement)
ISO 27001Links to the relevant ISO control clauses (e.g. A.12.1.3, A.13.1.1)

The Guardian Agent extracts all the data needed for the threat model from the design or from the code itself. No tedious questionnaire or generic assumptions on the implementation architecture. It then performs a comprehensive analysis of the proposed design, identifying  potential threats across multiple layers including:

  • Application layer: e.g., Insecure handling of PII in application logic
  • Infrastructure/Cloud layer: e.g., Cloud storage misconfigurations like missing bucket encryption
  • Third-Party integrations: e.g., Overly permissive API key configurations for external SaaS platforms

4. Generating Contextual Threats and Countermeasures

While identifying potential threats is an important first step, the real complexity – and where Apiiro’s threat modelling unique value resides – lies in the ‘last mile’ of accuracy and actionability. Thus,  for every identified threat, the Agent provides:

  • Evidence-based prioritization: Rather than a flat list, the Agent assesses the priority and potential impact of each threat by cross-referencing it with your actual architecture, existing security controls, and runtime exposure.
  • Tailored countermeasures: The Agent generates concrete, context-aware remediation blueprints – essentially “secure prompt” recipes – that developers and coding agents can use to guide their implementation when writing code.

With the Apiiro Data Fabric as critical context, the Agent will explain and provide design and code evidence for any threat selected: What is the potential vulnerability, attack path, exploitation method and technical consequences of exploitation. Moreover, instead of generic advice, the Agent will use this context to provide countermeasures implementation actionable guidance tailored to your specific architecture. It will provide all the relevant codebase context for the countermeasure implementation: What, where and how to implement, evidence why it will work and guidance on how to verify. 

To demonstrate the power of this capability, let’s look at an imaginary but common scenario: 

A platform team is building a new feature: an AI-powered chat assistant embedded in their product. The design doc describes a Claude integration and a context enrichment layer that fetches and feeds internal data into the results.

Based on the design doc, The Guardian Agent maps potential threats and suggests concrete countermeasures across all these new external data flows in a single, comprehensive pass.

Identified Contextual Threat *Example* Generic Countermeasure (Traditional tools) Contextual Countermeasure (Guardian Agent)
Direct Prompt Injection — The assistant is embedded in the internet-facing product, but the EnrichmentService brings internal data — user records, project metadata — into the LLM context for every query. The model is sitting on a cross-system internal data trove. Without adequate boundaries, any user is one prompt away from accessing it. Validate all user inputs before passing to the LLM. Implement content filtering to detect and block known prompt injection patterns. Apply prompt engineering best practices such as system prompt hardening and role-based instructions. Separate the data channel from the instruction channel at prompt assembly — user input and enrichment content are untrusted data and must never be interpretable as model instructions. Minimize the LLM’s authority to read-only inference, on relevant data only; Deny list sensitive and redundant endpoints in the internet-exposed RestSharp API using the existing ResponseMiddleware at src/Middleware/ResponseMiddleware.cs:31.
Indirect Prompt Injection via Enriched Context — The enrichment layer indexes Confluence pages, GitHub READMEs, and the internal knowledge. A malicious instruction embedded in any indexed document could potentially fire on content retrieval, while the chat prompt itself could look naive, passing validations. Sanitize and isolate all externally-sourced data before including it in LLM context. Restrict the assistant’s available actions and data access to the minimum required for its function. Apply output validation before rendering or executing LLM responses. Scope enrichment retrieval to the requesting user’s Okta permissions — not a service account with org-wide read access. Strip markup artifacts, HTML comments, invisible unicode, embedded metadata — from Confluence and GitHub API responses before they enter the prompt. Restrict indexing to approved repositories and document spaces to reduce the write surface attackers can use to plant instructions. Log enrichment retrievals through the existing Microsoft.Extensions.Logging pipeline.
Over-Privileged LLM Integration — A single shared credential powers all 108 external call sites, including the enrichment layer’s own data. A credential compromise doesn’t just expose the chat feature; it exposes every project, user, and risk assessment in the platform. Apply the principle of least privilege to all third-party API integrations. Conduct periodic access reviews to ensure credentials are scoped appropriately. Rotate API keys on a regular schedule and store them in a secrets manager. Provision the chat feature with a dedicated, minimal credential for LLM inference only — don’t use the wide access ApiCredential at src/Startup.cs:43 as is. Per-service key definitions already exist in infra/api_keys.tf; wire the scoped chat feature’s credential through the HashiCorp Vault integration.
PII Exfiltration via Chat Logs — An attacker or insider who reaches the new chat_history collection gains a cross-referenced PII trove — user records, project metadata, risk assessments. It’s a higher-value, lower-effort target than any of the source systems it draws from. Classify all sensitive data and encrypt PII at rest and in transit. Implement data loss prevention controls across storage and communication channels. Enforce retention policies and ensure compliance with GDPR, CCPA, and other applicable privacy regulations. Redact PII from enrichment payloads before they reach the conversation logger. Encrypt any fields that must be retained using the existing Cryptography .NET library already in use across 13 call sites. Restrict read access to chat_history — the aggregated collection must not grant broader access than the source MongoDB collections the data originated from.
Threat model analysis results in the Apiiro portal – targeted threats and actionable countermeasures

5. Streamlining Implementation 

The ultimate value of threat modeling lies in its translation from a theoretical exercise into proactive prevention. By leveraging the Apiiro Data Fabric, the Guardian Agent ensures that countermeasures are not abstract security requirements, but have a targeted implementation plan that matches the frameworks, file structures, and security standards already present in the code.

These implementation plans are dynamically written and adjusted to align with your specific tech stack and existing architectural logic. Because the Agent reasons over the real-world Software Graph™, rather than relying on static or “imaginary” architecture diagrams, it ensures that every security instruction is grounded in the actual state of your application. Moreover, it guides the usage of existing controls already in place in the codebase, thus reducing technical debt and the overall code hygiene and complexity.

This level of contextual precision means that whether a human developer or an AI coding agent receives these countermeasures, the process of translating them into actual secure code happens effortlessly and accurately, effectively removing the manual friction that typically follows a design review.

Threat model analysis guide the feature implementation via Guardian Secure Prompt in Cursor

6. Collecting Audit Evidence 

Traditional threat modeling often results in a static document – typically a PDF – that becomes obsolete the moment it is saved. By contrast, threat models generated by the Guardian Agent are living entities integrated directly into the Apiiro Data Fabric. Every identified risk and its associated countermeasure is stored within the platform, allowing you to manage the full risk lifecycle — including ownership, SLA tracking, and formal exception workflows — just as you would with a vulnerability found in code. This data remains accessible through the Apiiro Risk Graph and Explorer, providing a persistent, searchable history of design-stage security decisions. For organizations facing regulatory or internal audits, this information flows directly into Compliance reporting, offering a clear, evidence-based trail that proves security was considered and addressed before implementation began.

PDF report used for evidence collection
Managing the threat model finding life cycle in Apiiro

7. Continuous Validation and Drift Detection (Coming Soon)

One of the most powerful aspects of embedding threat modeling into the Data Fabric is the ability to perform continuous validation. Coming soon, the Guardian Agent will be able to compare the intended secure design (the threat model) with the actual implementation (the code) as part of the PR process, before merge. If:

  1. A developer implemented a feature in a way that deviates from the identified countermeasures, such as forgetting to apply the required encryption, or 
  2. If a new threat emerged post the implementation (such as access to unplanned external 3rd party service, not in the original design) 

Guardian Agent will flag this drift. 

Operating within the Existing Developer and AppSec Workflows

Guardian AI Threat Modeling is tightly integrated into the daily workflows of both engineering and application security teams.

For Developers: Secure-by-Default Coding

Developers often view security as a roadblock, a series of “no’s” delivered too late in the process, or vague guidelines that require heavy lifting in order to translate to actual implementation. Guardian Agent changes this by becoming a Developer-Native ally.

  • Dev tool chain Integration: Secure coding guidance and countermeasures are delivered directly within the developer’s environment — either as additional to the original implementation ticket, in the IDE (via the Guardian IDE extension or MCP server), and soon as part the relevant PR —  allowing them to move fast without “looking over their shoulder”
  • Secure prompt: When using coding assistants like GitHub Copilot or Cursor, Guardian Agent infuses the prompt with the security instructions and code patterns identified in the threat model.
Tthreat model guidance appearing in context within the original design

For AppSec: Automated Governance at Scale

Security teams are often stuck in a cycle of manual ticket-pushing. Guardian AI Threat Modeling allows them to transition to high-level strategic governance:

  • Instant visibility: Monitoring continuously the entire estate for new dangerous features, and triggering automated threat modelling and resulting risk guardrails across the organization in seconds.
  • Automated process: Shifting intermittent manual reviews to a fully automated 24/7 engine, ensuring that every architectural design and product spec is analyzed in real-time, removing security as a bottleneck to high-velocity development.
  • Audit-ready reports: Automatically generate compliant threat reports tied to the design and real code changes, providing a clear evidence trail for regulators and auditors.

How it Looks in the Real-World

To put our new AI Threat Modeling impact into perspective, let’s look at the ‘before and after’ of a development team tasked with building a new feature: embedding an AI-powered chat assistant in their product, and see how this new Guardian Agent capability helps.

The Traditional Way: The developer creates a Jira ticket and a related design document. They might search for generic integration patterns. Weeks later, during a routine security review, the AppSec team discovers that the chatbot integration handles sensitive user data but lacks proper authentication and logs PII in plain text. The code must be rewritten, delaying the feature release.

The Guardian Way:

  1. Detection: As soon as the Jira ticket is created, Guardian Agent automatically monitors and analyzes the intent of the feature –  integrating a 3rd party LLM service and handle user data – and flag is as potentially risky
  2. Context collection: It cross-references this with the Software Graph architecture and identifies that the target repository handles PII and is internet-exposed
  3. Threats analysis: In seconds, it generates a threat model identifying potential critical threats like direct and indirect prompt injection, or PII exfiltration. A full audit ready threat report is generated, and relevant risks and ownership are recorded.
  4. Fix instructions: As part of the analysis, each threat is enriched with an actionable list of  countermeasures with relevant coding guidance/samples for implementation based on the concrete target application. These are shared with the relevant developer – as comments in the original design docs, dedicated tickets, and within the IDE.
  5. Secure coding: When the developer uses an AI coding assistant to implement the feature, Guardian Agent infuses the prompt with these guidelines, ensuring the generated code is secure-by-default.
  6. Governance: Risks and their implementation status are automatically logged to manage ownership and SLAs, providing a permanent, audit-ready record for compliance and visibility.

The Apiiro Difference

By delivering AI powered Threat Modeling as a core capability of the Guardian Agent, we are moving beyond static, manual exercises toward a continuous, code-aware security design:

  • From documentation to proactive prevention: Threat modeling is no longer a paper-based exercise. Guardian translates abstract threats into actionable countermeasures mapped directly to specific code locations, ensuring security is built-in, not bolted on.
  • Architecture grounded in reality: Unlike tools that rely on “imaginary” or outdated architecture diagrams, Apiiro leverages the Software Graph™ to reason over your real-world environment. This ensures accuracy even when design documents are partial or missing.
  • Dynamic, tech-stack specific guidance: Countermeasures are not generic; they are automatically adjusted to align with your specific tech stack and existing logic. By identifying and leveraging existing security controls for reuse, Guardian reduces security debt and implementation friction.
  • Noise reduction: To solve the “noise” problem typical of security tools, Guardian automatically de-prioritizes mitigated threats and prevents the creation of redundant ones. As your codebase evolves, the threat model stays “alive,” updating automatically to reflect the current state of the application.
  • Graph-powered prioritization: Every threat is analyzed through the lens of the Apiiro Data Fabric. By combining deep multi-layered classification with graph-based blast radius analysis, the agent provides contextual prioritization that separates theoretical risks from critical exposures.
  • Methodology flexibility: The Guardian engine uses a hybrid approach — combining a deterministic library with native AI — to support all major threat modeling workflows and standards (STRIDE, OWASP, etc.), providing a single, audit-ready source of truth.

A private preview of AI Threat Modeling is available today. Schedule a demo here. We are eager to get your feedback and to further improve.