TUI usa Amazon Bedrock para escalar threat modeling a mais de 100 times de produto

Com só quatro engenheiros de segurança para mais de 100 times de produto, a TUI construiu um agente sobre Amazon Bedrock e AgentCore que gera, valida e audita modelos de ameaça, reduzindo o tempo de avaliação em até 70% e passando de semanas de espera para disponibilidade sob demanda.

A TUI opera companhias aéreas, hotéis, cruzeiros e experiências locais de viagem. Sua divisão de Platform & Engineering sustenta mais de 100 times de produto digital, mas a equipe de segurança responsável por avaliar a arquitetura de cada serviço tinha apenas quatro engenheiros. O AWS Architecture Blog publicou o relato de como a empresa resolveu esse gargalo construindo um fluxo agêntico sobre Amazon Bedrock e Amazon Bedrock AgentCore, em parceria com o AWS Generative AI Innovation Center.

Para quem trabalha com compliance e LGPD, o caso interessa menos pelo modelo de linguagem em si e mais pelo que ele resolve: tornar a avaliação de risco um processo obrigatório, padronizado e rastreável, ao invés de uma etapa manual que só acontecia para os projetos mais críticos.

O problema

O processo manual da TUI era rigoroso, mas lento. Para cada aplicação, um engenheiro revisava o diagrama de arquitetura, identificava ameaças pela metodologia STRIDE, mapeava cada uma aos TUI Technology Standards, aos padrões específicos de P&E e aos controles da ISO 27001, e documentava tudo no Confluence com tickets no Jira. Uma sessão completa consumia de 4 a 6 horas de trabalho manual.

Com mais de 100 times de produto e capacidade para apenas 3 a 4 sessões por mês, o backlog era permanente e times esperavam semanas por uma revisão. Dois problemas adicionais preocupavam quem responde por conformidade:

• Inconsistência entre avaliadores: o nível de expertise variava por engenheiro e por stack tecnológica, então o mesmo tipo de risco podia ser tratado de formas diferentes dependendo de quem fazia a análise.
• Nenhuma verificação automatizada: não havia como confirmar que os padrões internos e os controles ISO 27001 tinham sido aplicados de forma consistente em cada avaliação, o que é exatamente o tipo de lacuna que uma auditoria de segurança ou uma fiscalização de proteção de dados cobra.

A meta da TUI não era só acelerar: era tornar o threat modeling mandatório para todo serviço novo, não um luxo reservado aos projetos de maior prioridade.

A arquitetura

O sistema, batizado de Threat Designer, estende um projeto open source da própria AWS com capacidades específicas da TUI. Ele roda inteiramente na região eu-central-1 (Frankfurt), escolhida pelos requisitos de residência de dados da empresa. O fluxo, do usuário ao dado, funciona assim:

1. O engenheiro se autentica via Amazon Cognito e abre o front-end em React hospedado no AWS Amplify.
2. Na tela de submissão, ele dá um título ao projeto, envia um ou mais diagramas de arquitetura, adiciona contexto e premissas opcionais, e escolhe a profundidade de raciocínio num slider que vai de nenhuma iteração até alta, conforme a complexidade do sistema.
3. A requisição passa pelo Amazon API Gateway até o AWS Lambda, que orquestra um workflow em LangGraph.
4. O Lambda delega a execução ao Amazon Bedrock AgentCore runtime, que hospeda o agente containerizado sem exigir provisionamento de infraestrutura e isola cada sessão, permitindo processar vários threat models em paralelo.
5. O agente carrega, via seleção orientada por metadados, apenas os padrões de segurança relevantes para aquela arquitetura específica (mais detalhes na próxima seção).
6. O Amazon Bedrock, com o modelo Claude Sonnet 4.5 da Anthropic, gera as ameaças seguindo STRIDE, com orçamento de raciocínio estendido configurável entre 24 mil e 64 mil tokens dependendo da complexidade.
7. Um nó de validação confere se o catálogo de ameaças não está vazio, se as seis categorias de STRIDE foram cobertas e se uma análise de lacunas (gap analysis) já foi executada; se algo falhar, o agente recebe feedback e repete o ciclo.
8. Opcionalmente, o engenheiro sobe em PDF uma avaliação feita manualmente por um especialista (SME), e o sistema compara as duas por similaridade semântica, sinalizando discordâncias de severidade.
9. O estado do workflow fica no Amazon DynamoDB, com capacidade de retomar sessões interrompidas, enquanto diagramas, base de conhecimento e cache de busca na web ficam no Amazon S3.
10. O resultado final é exportável em PDF, JSON ou direto para o Confluence, com um dashboard que mostra ameaças por probabilidade, por categoria STRIDE, por ativo e por origem.

Os serviços envolvidos

Trade-offs

A primeira tentativa da TUI foi carregar os 192 padrões de segurança da empresa, 338 KB de texto, direto no contexto do modelo. Falhou: documentos individuais passam de 20 páginas, o conteúdo combinado estourava o limite de tokens, e mesmo com um subconjunto o modelo ignorava listas de ferramentas aprovadas e sugeria alternativas genéricas.

A solução foi tratar o problema como busca e seleção, não como carregamento de prompt: metadados leves (palavras-chave, tipo de componente, categoria STRIDE, score de relevância) para cada documento, e o modelo escolhe em tempo de execução apenas os 16 padrões mais relevantes. Isso reduziu o contexto de 338 KB para 21 KB, uma queda de 94%, sem perder cobertura. É um trade-off clássico de eficiência de desempenho: menos contexto custa menos tokens e responde mais rápido, mas exige manter a camada de metadados atualizada à mão conforme novos padrões entram.

A equipe também avaliou RAG e descartou, por ora: com um corpus fechado de 192 documentos, alguns obrigatórios independente da consulta, a seleção por metadados se mostrou mais previsível e mais fácil de depurar. É uma escolha de excelência operacional que troca escalabilidade automática por rastreabilidade, algo que pesa a favor de quem precisa explicar numa auditoria por que um padrão específico entrou ou ficou de fora de uma avaliação.

O orçamento de ferramentas do agente, que força uma análise de lacunas a cada três chamadas de geração de ameaças, evita que o modelo gere indefinidamente, mas também limita quanto ele explora antes de parar para revisar. É um trade-off de confiabilidade: previne loops descontrolados, ao custo de depender de um limiar arbitrário que pode não ser ideal para toda arquitetura.

O cache de busca na web, com TTL de 7 dias, atinge de 70% a 80% de acerto segundo os dados de produção da TUI, retornando em menos de 100 milissegundos contra 2 a 3 segundos de uma busca ao vivo. Isso melhora otimização de custos e desempenho, mas abre uma janela de até sete dias em que uma vulnerabilidade recém-divulgada pode não aparecer na busca em cache, um ponto que times de segurança devem monitorar.

Por fim, a execução inteira roda em eu-central-1, com dados criptografados em repouso via AWS KMS e em trânsito via TLS, atendendo aos requisitos de residência de dados da TUI na Europa. Para quem opera no Brasil sob LGPD, o pilar de segurança pede a mesma pergunta: os dados do projeto (diagramas de arquitetura, descrições de sistemas internos) precisam ficar em sa-east-1, e isso exige confirmar antes se o modelo Claude Sonnet 4.5 está disponível na região escolhida, já que a disponibilidade de modelos no Amazon Bedrock varia por região.

Custo estimado

O post da AWS não publica valores em dólar para o projeto, nem detalha consumo de tokens por avaliação, então não há como transformar isso num número confiável de custo mensal. O que dá para afirmar, a partir do que a fonte descreve, é a estrutura de custo: trata-se de uma pilha inteiramente serverless, paga por uso, em que o gasto variável está concentrado no consumo de tokens do Amazon Bedrock (o raciocínio estendido de 24 mil a 64 mil tokens por avaliação, dependendo da complexidade), nas sessões do AgentCore runtime, nas invocações do Lambda e no armazenamento no DynamoDB e no S3.

O ponto relevante para quem aprova orçamento é outro: o modelo de custo migrou de horas de engenheiro sênior (4 a 6 horas por sessão, 3 a 4 sessões por mês) para consumo de computação sob demanda, escalando com 10 a 12 sessões mensais sem aumento de headcount. Esse é um trade-off de otimização de custos que troca um teto fixo de capacidade humana por um custo variável atrelado a uso, o que para times de compliance significa que o custo de "fazer mais auditorias de segurança" deixa de ser uma decisão de contratação.

Como adaptar

A base do sistema é o projeto Threat Designer, disponível em código aberto no GitHub e descrito originalmente num post anterior do AWS blog sobre threat modeling com IA generativa. Antes de replicar a solução completa, alguns passos fazem sentido para um time brasileiro:

1. Verificar disponibilidade do Claude Sonnet 4.5 (ou modelo equivalente) na região sa-east-1 antes de desenhar a arquitetura, já que a TUI optou por eu-central-1 por motivos próprios de residência de dados.
2. Começar a seleção de padrões pela via de metadados, não por RAG: catalogar os controles internos (incluindo os que mapeiam para a LGPD, como os do Art. 46 sobre medidas de segurança) com palavra-chave, tipo de componente e categoria STRIDE, mesmo que o corpus inicial seja pequeno.
3. Manter o nó de comparação com especialista (SME) como etapa obrigatória, não opcional, nos primeiros meses: é o que gera a trilha de calibração e o registro auditável de que um humano revisou a decisão da IA, algo que áreas de compliance tendem a exigir antes de aceitar o resultado como evidência de conformidade.
4. Tratar o orçamento de ferramentas do agente (o limite de chamadas antes de forçar uma análise de lacunas) como parâmetro ajustável por arquitetura, não como constante fixa, revisando-o conforme o time acumula avaliações reais.

O resultado reportado pela TUI, segundo o post, veio de uma citação de Marvin Jordan, Head of Technology for Security Platform and Practices:

Nas primeiras quatro semanas após o lançamento, 64 usuários se registraram e 19 criadores únicos produziram 34 modelos de ameaça com o Threat Designer. O que antes levava de uma a duas semanas por avaliação agora está disponível sob demanda. Em outubro de 2026, a adoção já chegava a 255 usuários registrados, 86 modelos de ameaça e 43 criadores ativos, demonstrando que os times estão adotando segurança self-service como parte do fluxo de desenvolvimento.

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

Os números finais da TUI resumem o ganho:

Os próximos passos da TUI, segundo o post, incluem criação automática de tickets no Jira para rastrear mitigações e integração com pipelines de CI/CD para checagens de segurança antes do deploy, o que fecharia o ciclo entre threat modeling e enforcement automatizado.

Fonte

AWS Architecture Blog, "How TUI scales threat modeling for 100+ teams with Amazon Bedrock" (https://aws.amazon.com/blogs/architecture/how-tui-scales-threat-modeling-for-100-teams-with-amazon-bedrock/).

Fonte: AWS Architecture Blog