Post Syndicated from Vushesh Babu Adhikari original https://aws.amazon.com/blogs/architecture/how-tui-scales-threat-modeling-for-100-teams-with-amazon-bedrock/
When your security team has four engineers and your organization has over 100 digital product teams, threat modeling becomes a bottleneck fast. That was the challenge TUI faced. TUI operates across the travel and tourism industry with airlines, hotels, cruise ships, and local travel experiences. Our Platform & Engineering division needs security assessments to keep pace.
At TUI, each threat modeling session took 4–6 hours of manual work: reviewing architecture diagrams, mapping threats to internal standards, researching security issues, and documenting findings in Confluence. The team could complete only 3–4 sessions per month, leaving a constant backlog.
TUI needed threat modeling to become mandatory for every new service, not a luxury TUI reserved for the highest-priority projects. TUI built an AI-powered threat modeling system using Amazon Bedrock, collaborating with the AWS Generative AI Innovation Center during a 10-week proof of concept (PoC) to develop and validate the architecture. Amazon Bedrock is a fully managed service for building generative AI applications, and TUI used the Claude Sonnet 4.5 foundation model from Anthropic. TUI chose Amazon Bedrock for managed access to Claude Sonnet 4.5 without operating model infrastructure, its extended thinking support that the workflow uses for deeper analysis, and its integration with the AWS services already in TUI’s stack. TUI deployed the agentic workflow on Amazon Bedrock AgentCore runtime, part of Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale with any framework or model. AgentCore runtime hosts the agent in production without provisioning or scaling infrastructure. After the PoC, TUI took the system to production within 30 days.
In this post, we describe how TUI built an agentic AI workflow for threat modeling, the iteration process that shaped the architecture, and the results after deployment.
The challenge
TUI’s security engineering team followed a thorough but manual process: for each application, an engineer reviewed the architecture, identified threats using STRIDE methodology, mapped them to TUI Technology Standards, P&E-specific standards, and ISO 27001 controls, and documented findings in Confluence with Jira tickets.
With 100+ digital product teams and only 3–4 sessions possible per month, most teams waited weeks for their review. Security engineers also had varying levels of expertise across technology stacks, and there was no automated way to verify these standards were consistently applied to every assessment.
Solution overview
The solution extends AWS Threat Designer with TUI-specific capabilities through a serverless architecture deployed in the eu-central-1 (Frankfurt) AWS Region. Model availability varies by Region. For model availability by Region, refer to Supported models by AWS Region in Amazon Bedrock. Together, these services replace the manual review process with an automated workflow that applies TUI Technology Standards and P&E-specific standards consistently. The system uses the following key services:
-
Amazon Bedrock for threat analysis and generation using Claude Sonnet 4.5 from Anthropic, with configurable extended thinking budgets.
-
Amazon Bedrock AgentCore runtime for hosting the agentic workflow as a managed, serverless runtime. It runs the containerized LangGraph agent without provisioning or scaling infrastructure, supports long-running sessions that exceed typical function timeouts, and provides per-session isolation for concurrent threat models.
-
AWS Lambda for serverless backend compute with LangGraph workflow orchestration.
-
Amazon DynamoDB for workflow state management with resume capability.
-
Amazon Simple Storage Service (Amazon S3) for architecture diagram storage, TUI knowledge base, and web search cache.
-
AWS Amplify for the React front end with Amazon Cognito authentication.
Figure 1: TUI Threat Designer system architecture. Users authenticate through Amazon Cognito and interact with the React front end hosted on AWS Amplify. Requests flow through Amazon API Gateway to AWS Lambda, which orchestrates the LangGraph workflow through Amazon Bedrock AgentCore. The agent uses Amazon Bedrock (Claude Sonnet 4.5 from Anthropic) for threat analysis, with Amazon DynamoDB for state management and Amazon S3 for architecture diagram storage and caching.
The core is a LangGraph-based agentic workflow that processes architecture diagrams through several specialized nodes. Engineers upload one or more diagrams (for example, a high-level architecture alongside a detailed network topology), which the workflow converts to base64 to identify components and data flows. It then loads relevant security standards and generates threats with iterative refinement. The workflow runs gap analysis, optionally compares against a subject matter expert (SME) assessment, and assembles the final threat model with export options (PDF, JSON, or Confluence).
The following screenshot shows the submission wizard. Engineers provide a title, upload architecture diagrams, add optional context and assumptions, and select a reasoning depth based on architecture complexity. The entire setup takes approximately two minutes.
Figure 2: The submission wizard guides engineers through a six-step process. The iterations slider controls the reasoning budget, from None for quick scans to High for complex architectures with 20 or more components.
Once submitted, the system processes the architecture through each workflow node with real-time progress tracking. Engineers can monitor which phase is active and return to review results when processing completes.
Figure 3: Real-time progress tracking shows the current workflow phase. The Thinking indicator on the Threats node reflects the extended thinking capability of Claude analyzing the architecture against TUI security standards.
The iteration journey: from brute force to intelligent selection
TUI’s team didn’t arrive at the final design on day one. They iterated through several approaches, and each failure pointed toward the next improvement.
Attempt 1: Load everything into the prompt. The first approach loaded all 192 TUI security standards (338 KB) directly into the foundation model context. This failed immediately. Some individual standard documents run 20+ pages, and the combined content exceeded token limits before the foundation model could begin threat analysis.
Even with a subset of standards, the foundation model struggled to follow structured instructions. When asked to recommend only TUI-approved tools for mitigations, it would ignore the approved tool list and suggest generic alternatives. Too much contradictory information from different standards confused the model.
Attempt 2: Metadata-driven selection. The breakthrough came from treating the problem as a search and selection challenge rather than a prompt-loading exercise. Instead of loading all standards, the team pre-generated lightweight metadata for each document: keywords, component types, STRIDE categories, and a relevance score.
At runtime, the foundation model reviews this metadata (about 60 KB) and selects only the 16 most relevant standards for the specific architecture being analyzed. This reduced context from 338 KB to 21 KB, a 94% reduction, while maintaining coverage. The reduction is calculated from the metadata approach versus loading all standards directly.
The metadata approach fits the structure of TUI’s knowledge base: some documents are always mandatory (security guidelines, approved tools), while others apply only to certain architectures. The team also evaluated retrieval-augmented generation (RAG), but with a bounded corpus of 192 standards, some mandatory regardless of the query, metadata-driven selection proved more predictable and easier to debug. RAG may complement it as the knowledge base grows.
Agentic threat generation: a self-correcting workflow
The threat generation node is where the agentic behavior matters most. Rather than generating threats in a single pass, the system uses a Reason and Act pattern with a LangGraph subgraph. The agent has four tools at its disposal: adding threats, deleting threats, reading the current threat catalog, and running gap analysis.
The agent autonomously decides which tools to call and in what order. It generates an initial set of threats using STRIDE methodology, then reviews its own output against the loaded TUI standards. Each threat includes a title, description, affected component, and threat vector. It also assigns likelihood and impact scores using TUI’s risk matrix. Threats include recommended mitigations with TUI-approved tools and mapped ISO 27001 controls.
A tool budget system helps prevent the agent from generating indefinitely. After three threat-generation calls, the system forces a gap analysis. The agent must step back and assess what’s missing before generating more. This mimics how human security experts work: generate, review, identify gaps, fill them.
A validation node checks three conditions before the workflow can proceed: the threat catalog isn’t empty, all six STRIDE categories are covered, and gap analysis has been performed at least once. If a check fails, the agent receives specific feedback and loops back.
Based on TUI’s production data, the combination of iterative generation and gap analysis typically produces 40–60 threats per architecture, compared to the 30–40 that manual sessions identified. It also supports configurable extended thinking budgets, from 24K reasoning tokens for standard architectures up to 64K for complex systems.
Web search for current threat intelligence
Security threats evolve regularly. A threat model generated today needs to account for issues disclosed last week. The workflow integrates web search to fill gaps where TUI’s internal standards don’t cover specific technologies.
For every technology identified in the architecture (Keycloak, Kong, Redis, and so on), the system generates two search queries: one for known issues and one for hardening best practices. These queries target authoritative sources such as OWASP, NIST, and CWE databases. Before making an API call, it checks an Amazon S3-based cache with a 7-day time-to-live (TTL). Only technology component names are used for external searches. Architecture details and customer data are not included in queries.
The cache key uses a hash of the sorted component names, deliberately excluding foundation model-generated descriptions. Those descriptions vary slightly between runs even for the same diagram, which would reduce cache effectiveness.
Based on TUI’s monitoring data, the cache achieves a 70–80% hit rate because many TUI applications share core technologies. A cache hit returns results in under 100 milliseconds, compared to 2–3 seconds for a live search. TUI’s team evaluated multiple search providers during the PoC and designed the system with a pluggable provider architecture, allowing provider switching as capabilities evolve.
SME comparison: human-in-the-loop validation
TUI’s security engineers don’t just use the system. They validate it. The workflow includes an optional node where engineers upload their own manually created threat assessment as a PDF. The workflow extracts threats using Claude, normalizes risk ratings to a standard scale (LOW, MEDIUM, HIGH, CRITICAL), and matches them against the AI-generated threats using semantic similarity.
When the AI and the SME disagree on a threat’s severity, the system flags the discrepancy with both ratings and the SME’s rationale. For example, the AI might rate a credential stuffing event (automated login attempts using unintended disclosure of credential databases) as HIGH while the SME rates it MEDIUM. Over time, these comparisons calibrate the system’s risk scoring and surface areas where the AI consistently over- or under-estimates risk.
The following screenshot shows an SME Comparison Alert for a credential stuffing threat. The system matched the AI-generated threat with a similar SME threat, compared both ratings (AI: High, SME: HIGH), and provided the SME’s rationale alongside a recommendation.
Figure 4: An SME Comparison Alert for a credential stuffing threat. The system displays both the AI and SME ratings, the matched SME threat, the expert’s rationale, and a recommendation. In this case, ratings are consistent. When they disagree, the alert highlights the discrepancy for human review.
Path to production: 30 days from handover to live
After the PoC handover, TUI’s team took the system from prototype to production-ready deployment in 30 days. The following results reflect the system’s performance in production.
Results
| Metric | Before | After |
| Time per assessment | 4–6 hours | Up to 70% reduction* |
| Sessions per month | 3–4 | 10–12 (300% increase)* |
| Standards applied | Varies by engineer | 100% consistent |
| Threats identified | 30–40 | 40–60 per architecture |
| Mandatory for all teams | No (backlog too large) | Yes (feasible at scale) |
*Based on TUI’s internal measurements comparing pre- and post-deployment performance.
The solution processes each architecture in the eu-central-1 Region, with data encrypted at rest using AWS Key Management Service (AWS KMS) and in transit with TLS. Architecture diagrams and threat models are processed within the AWS infrastructure, helping TUI meet its data residency and security requirements.
The following screenshot shows the threat catalog, a card view of completed threat models. Each card displays the original architecture diagram, an AI-generated description, completion status, and threat counts by severity (red for high, yellow for medium, green for low).
Figure 5: The threat catalog provides an overview of completed threat models. Each card shows the architecture diagram, an AI-generated summary, and threat counts grouped by severity.
Engineers can select a threat model to view a dashboard with four analytical views: threats by likelihood, threats by STRIDE category, threats by target asset, and threat sources.
Figure 6: The insights dashboard for a completed threat model. This example shows 40 identified threats (6 high, 24 medium, and 10 low) distributed across all six STRIDE categories and mapped to specific architecture components.
“In the first four weeks after launch, 64 users registered and 19 unique creators produced 34 threat models with Threat Designer. What previously took one to two weeks per assessment is now available on demand. As of October 2026, adoption has grown to 255 registered users, 86 threat models, and 43 active creators, demonstrating that teams are embracing self-service security as part of their development workflow.”
— Marvin Jordan, Head of Technology for Security Platform and Practices, TUI
Conclusion
TUI’s experience shows that agentic AI workflows can address a real operational challenge in enterprise security: making thorough threat modeling fast enough to be mandatory. The combination of metadata-driven context selection, self-correcting threat generation, and intelligent caching allowed a four-person security team to support over 100 digital product teams. TUI achieved consistent, standards-aligned assessments at scale.
Looking ahead, TUI plans to expand the system with automated Jira ticket creation for mitigation tracking and integration with CI/CD pipelines for pre-deployment security checks.
You can get started with Amazon Bedrock to build AI-powered security workflows and Amazon Bedrock AgentCore to deploy agentic applications in production. For hands-on guidance with your specific use case, connect with the AWS Generative AI Innovation Center. To explore the open source foundation that this solution extends, see the Threat Designer project on GitHub and the AWS blog post Accelerate threat modeling with generative AI.
We welcome your feedback and questions in the comments.