TUI’s AI Threat Modeling Didn’t Eliminate Security Review. It Changed the Bottleneck.

Service, Decided | An enterprise case note on standards selection, bounded agents, and accountable security judgment

Four security engineers. More than 100 digital product teams. At TUI, a manual threat-modeling session took four to six hours, and the security group could complete only three or four each month. The bottleneck wasn’t whether threat modeling mattered. It was whether an organization could require it for every new service without turning the security team into a queue.

In a November 5, 2026 AWS Architecture Blog article coauthored by TUI security leaders and AWS practitioners, TUI describes moving to an AI-assisted Threat Designer built with Amazon Bedrock, Bedrock AgentCore, and a LangGraph workflow. The noteworthy decision was not “add a model.” It was redesigning where policy is retrieved, where automated reasoning must stop, and where human reviewers can challenge a risk rating.

The constraint: 100+ teams, four security engineers

The previous process involved reading architecture diagrams, using STRIDE to identify threats, mapping findings to TUI’s security standards and ISO 27001 controls, and documenting issues in Confluence and Jira. Each assessment depended on scarce specialist time. TUI wanted the review to be a normal requirement of delivery, not an exception reserved for the highest-risk applications.

AWS and TUI report a 10-week proof of concept followed by a production rollout within 30 days of handover. The workflow accepts architecture diagrams and context, analyzes components and data flows, generates a threat catalog, runs gap checks, and exports its results. Its operating design matters more than its list of cloud services.

Figure 1. TUI’s workflow combines policy selection, enforced agent checks, and optional expert comparison. Original Decision Crafters diagram, adapted from the AWS/TUI case study (November 5, 2026).

Decision 1: Select the right policy, rather than feed the model everything

TUI initially tried loading all 192 internal standards—about 338 KB—into a prompt. That approach hit context limits and produced inconsistent recommendations, including suggestions outside the approved tools list. The repair was not simply a larger model. The team generated lightweight metadata describing each standard and used that metadata to select the 16 relevant documents for a given architecture, while preserving always-required guidance.

TUI reports reducing the loaded standards context from 338 KB to 21 KB, approximately 94%. It also evaluated retrieval-augmented generation, but found metadata-based selection easier to reason about for a bounded corpus with mandatory documents. This is an important architectural distinction: retrieval is not automatically the best control mechanism when a policy corpus has explicit applicability rules.

Decision 2: Put stopping conditions inside the agent

The agent can add threats, remove threats, inspect its catalog, and perform gap analysis. But those freedoms are bounded. After three threat-generation tool calls, the workflow forces a gap analysis. Before it can finish, validation checks that the catalog is non-empty, all six STRIDE categories were considered, and gap analysis ran at least once. Failed checks return specific feedback and trigger another pass.

That design does not prove every real threat was found. It does make an important part of the review process observable: the system cannot finish merely because its first answer sounds plausible. The six STRIDE categories become a coverage check, not a claim that a threat model is complete or safe.

Decision 3: Keep a route for expert disagreement

TUI added an optional subject-matter-expert comparison step. An engineer can provide a manually prepared assessment, and the workflow matches its findings with AI-generated threats, compares normalized severity ratings, and highlights discrepancies with the expert’s rationale. This does not establish that a human approves every model before use; it establishes a concrete mechanism for reviewing disagreement and calibrating risk estimates.

The system also searches authoritative public sources for technology-specific advisories. TUI says it sends component names, not architecture details or customer data, to external searches and uses a seven-day S3 cache to reduce repeat calls. Those are deliberate security and cost boundaries, not details to leave to the model’s discretion.

What the reported results show—and what they don't

TUI’s internal production measurements show assessment time falling by up to 70%, with throughput rising from three or four sessions to 10–12 per month. Its AWS case study reports roughly 40–60 threats identified per architecture, versus 30–40 in the prior manual process. By October 2026, TUI reported 255 registered users, 86 threat models, and 43 active creators, compared with 64 registered users and 34 models created by 19 unique creators during the first four weeks after launch.

These are meaningful indicators of throughput and adoption. They are not an independent quality audit. More threats may include more false positives; consistent application of mapped standards does not prove the standards are correct; and 100+ product teams served as the organizational challenge, not evidence that every team has already completed a model. The public case study does not provide independently measured false-positive rates, expert-overlap accuracy, cost per assessment, or a controlled comparison of security outcomes.

The Service, Decided pattern

The service decision was to make threat modeling accessible on demand. The design decisions were to constrain policy selection, force iterative self-checks, preserve expert comparison, and make the workflow auditable. The accountable operator is identifiable: Marvin Jordan, TUI’s Head of Technology for Security Platform and Practices, is a coauthor and supplies adoption figures; Joseph Thachil George, a TUI security engineer, is also a coauthor.

For an engineering leader designing a similar review service, the more useful questions are: Which policy documents must always be applied? What evidence can the system actually inspect? What checks stop it from issuing a shallow report? Who resolves an AI-versus-expert disagreement? And what measures review quality, not just the number of reports produced?

A practical first pilot should measure engineer-hours saved and time-to-feedback alongside expert agreement on threat relevance and severity, missed high-impact threats, and rework caused by false positives. Only then can “faster review” become a credible argument for “better security decision.”

The lesson is not that AI replaced four security engineers. It is that TUI changed the shape of the work those engineers needed to own.

Primary source and evidence note

AWS Architecture Blog, “How TUI scales threat modeling for 100+ teams with Amazon Bedrock,” November 5, 2026 (coauthored by TUI and AWS). https://aws.amazon.com/blogs/architecture/how-tui-scales-threat-modeling-for-100-teams-with-amazon-bedrock/

Performance, throughput, and adoption figures above are attributed to TUI’s internal measurements as reported in the AWS/TUI case study. Decision Crafters did not independently audit those figures.