Como pedir um threat model ao Gemini 4 Carbon antes de escrever código (e o que fazer enquanto o acesso é restrito)

Fala aí, beleza? O Google anunciou o Gemini 4 Carbon em 28/10/2026 e chamou ele de seu modelo mais forte, com capacidades de ponta em cibersegurança e em tarefas de longo horizonte

O que este post ensina é um método pra pensar a segurança ANTES da primeira linha de código: descrever a arquitetura, as fronteiras de confiança e os dados sensíveis, e depois transformar a resposta da IA em backlog que um humano revisa

E o detalhe importante: o método não depende do Carbon, tu consegue rodar ele hoje com um modelo que já está aberto 🙂

Quem pode usar o Gemini 4 Carbon agora e quando ele chega aos desenvolvedores

Agora, só um grupo pequeno de defensores cibernéticos

O acesso está restrito a organizações selecionadas pelo Fairwind Program, sem API pública, sem ID de modelo e sem data publicada pra Gemini API, Vertex AI ou app Gemini, segundo a VentureBeat

Que Fairwind Program?

É o canal pelo qual o Google DeepMind libera antes os modelos mais capazes pra organizações que defendem infraestrutura crítica, como governos, saúde e telecomunicações

E mesmo lá dentro tem limite: os parceiros só podem executar tarefas de uso duplo permitidas, como simulação de ameaças autorizada, engenharia reversa e análise de malware para defesa ou pesquisa acadêmica

A ordem de liberação é essa:

• primeiro um subconjunto de defensores
• depois mais parceiros confiáveis, aos poucos
• só mais tarde desenvolvedores, empresas e consumidores

O Google diz que vai levar o Carbon pra esse público "o mais rápido possível", depois de coletar feedback e refinar as proteções (guardrails), mas não publicou data nenhuma

O que o Google divulgou de números e preço?

No anúncio oficial, o Google publicou estes resultados de cibersegurança do Carbon:

Benchmark	O que mede	Resultado divulgado pelo Google
SEC-bench Pro	encontrar vulnerabilidades	88,2%
ExploitGym	exploração	54,8%
CWE-bench	correção	71,0%

O Google também relata que equipes internas viram o Carbon trabalhar por dias em tarefas de engenharia longas e com várias etapas, como achar a causa raiz e corrigir bugs sutis em bases de código grandes

Se liga: são números e relatos do próprio Google, e nenhum deles mede a qualidade de um threat model de arquitetura

O preço anunciado é o mesmo introdutório do Argon: US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de tokens de saída, com 95% de desconto na entrada em cache

O que você precisa antes de pedir o threat model

Você precisa de três coisas: um modelo disponível hoje, o conceito claro na cabeça e um rascunho da arquitetura em texto

Qual modelo usar enquanto o Carbon não abre?

O Gemini 4 Argon, modelo anterior, já está aberto ao público desde 13/10/2026 (fonte):

• Gemini API, no plano pago, com o ID gemini-4-argon
• Google AI Studio
• app Gemini, nos planos Pro e Ultra
• Antigravity, no plano Ultra

Preço introdutório da API do Argon: US$ 2 / US$ 10 por milhão de tokens (entrada/saída) até 30/11/2026, e depois US$ 4 / US$ 20

O que é threat modeling, em uma frase?

É o processo que identifica e enumera ameaças possíveis e indica quais controles são necessários, considerando a natureza do sistema, o perfil provável do atacante, os vetores de ataque e os ativos mais visados

Repara que essa definição já é praticamente a lista do que o modelo precisa receber de você… e é exatamente isso que os passos abaixo montam

Alternativa pronta: STRIDE GPT

Se tu prefere uma ferramenta em vez de montar o prompt na mão, existe o STRIDE GPT, open source, que gera threat models com LLMs usando prompts baseados na metodologia STRIDE por elemento e é compatível com modelos Gemini

Não há relato verificado de como ele se comporta com o Gemini 4 (Argon ou Carbon), então trate como opção a testar, não como atalho garantido

Passo a passo: do desenho do sistema ao threat model

Os prompts abaixo são exemplos didáticos de um sistema fictício simples: um app web de pedidos com frontend, API, banco de dados e um gateway de pagamento de terceiros

Troca os componentes, fluxos e dados pelos do teu sistema e roda 😀

Passo 1: Descreva a arquitetura como lista de elementos

Modelo bom não adivinha o que tu não contou

Então a arquitetura entra como lista: componentes, fluxos de dados e quem chama quem

Sistema: app web de pedidos

Componentes:
C1. Frontend web (SPA no navegador do cliente)
C2. API de pedidos (backend próprio)
C3. Banco de dados relacional (pedidos, clientes)
C4. Gateway de pagamento (serviço de terceiro)
C5. Painel administrativo (acesso interno da equipe)

Fluxos de dados:
F1. C1 chama C2 via HTTPS com token de sessão
F2. C2 lê e grava em C3
F3. C2 envia dados da cobrança para C4
F4. C4 chama um webhook em C2 com o status do pagamento
F5. C5 chama C2 com credenciais de administrador

Erro comum deste passo: descrição vaga tipo "tenho um app com backend e pagamento"

Aí o modelo preenche os buracos sozinho e analisa um sistema que não é o teu

Passo 2: Marque as fronteiras de confiança

Fronteira de confiança é onde o dado muda de "dono" ou de nível de confiança: de usuário pra servidor, de serviço interno pra terceiro, de rede pública pra privada

É justamente nesses pontos que mora a maior parte das ameaças, então deixa elas explícitas

Fronteiras de confiança:
T1. Internet pública / API (fluxo F1): navegador do cliente não é confiável
T2. API / gateway de pagamento (fluxos F3 e F4): serviço de terceiro
T3. Rede pública / rede privada do banco (fluxo F2)
T4. Painel administrativo / API (fluxo F5): acesso privilegiado

Passo 3: Liste dados sensíveis, ativos e perfil do atacante

Esses são insumos da própria definição de threat modeling, então não pula essa parte

Dados sensíveis e ativos mais visados:
A1. Dados pessoais dos clientes (nome, e-mail, endereço)
A2. Tokens de sessão
A3. Credenciais de administrador
A4. Status de pagamento dos pedidos

Perfil provável do atacante:
P1. Usuário externo anônimo tentando acessar pedidos de outros clientes
P2. Atacante tentando forjar o webhook de pagamento
P3. Conta interna comprometida usando o painel administrativo

Passo 4: Peça a análise STRIDE por elemento com formato fixo

STRIDE por elemento é a mesma metodologia usada pelo STRIDE GPT: pra cada componente e fluxo, tu olha as seis categorias de ameaça

E aqui vem o ponto que mais quebra o resultado: o formato da saída

Se tu curte essa ideia de estruturar o pedido antes de pedir a resposta, o conceito de meta-prompting no GSD conversa bastante com isso

Com base na arquitetura, nas fronteiras de confiança, nos ativos e nos
perfis de atacante acima, faça um threat model usando STRIDE por elemento
(Spoofing, Tampering, Repudiation, Information disclosure,
Denial of service, Elevation of privilege).

Regras:
1. Analise TODOS os componentes (C1 a C5) e TODOS os fluxos (F1 a F5).
2. Para cada ameaça, responda SOMENTE em uma tabela Markdown com as colunas:
   elemento | categoria STRIDE | ameaça | fronteira envolvida | controle sugerido
3. Use os códigos (C1, F3, T2, A1, P2) para referenciar os itens.
4. Se uma categoria não se aplica a um elemento, escreva "não se aplica"
   e justifique em uma frase.
5. Não inclua texto fora da tabela.

Erro comum deste passo (comprovado): avaliações anteriores de threat modeling com o Gemini 2.5 Pro relataram saídas inconsistentes em Markdown e JSON quando o prompt era fraco (fonte)

Por isso o formato vai EXPLÍCITO no prompt, com colunas nomeadas e regra de "nada fora da tabela"

Passo 5: Transforme cada ameaça em item de backlog revisável

Tabela de ameaças bonita parada num chat não protege ninguém haha

O pulo do gato é converter cada linha num item que alguém do time aprova ou descarta

Converta cada linha da tabela em um item de backlog com este formato:

Título:
Elemento afetado:
Categoria STRIDE:
Controle proposto:
Critério de aceite (verificável):
Decisão humana: [ ] aceitar  [ ] mitigar  [ ] descartar
Justificativa da decisão: (em branco, preenchida pelo revisor)

O campo de decisão humana fica em branco de propósito

Quem decide é o time, a IA só entrega o rascunho

Passo 6: Faça a checagem final

Antes de jogar qualquer coisa no backlog, confere:

• todo componente (C1 a C5) e todo fluxo (F1 a F5) do passo 1 aparecem na saída?
• toda fronteira (T1 a T4) do passo 2 foi considerada em pelo menos uma ameaça?
• o formato veio consistente do começo ao fim, sem trocar de tabela pra texto solto no meio?
• cada item passou por um revisor humano e teve a decisão preenchida antes de virar tarefa?

Se algum elemento sumiu, pede de novo só pra ele, citando o código

Tome cuidado com o item que "parece óbvio": é exatamente o tipo de coisa que passa sem revisão e vira tarefa errada

Quando o threat model com IA vale a pena e quando não substitui a revisão humana

Vale a pena quando a feature mexe em fronteira de confiança, e não substitui a revisão em nenhum caso

Situações em que pedir antes de codar agrega muito:

• feature nova que cruza uma fronteira de confiança (ex: um endpoint público novo)
• integração com serviço de terceiro, como o gateway de pagamento do exemplo
• armazenamento de dado sensível que antes não existia no sistema

É a mesma lógica de avaliar um sistema antes de instalar: pensar no risco antes de ter código pra desfazer

Agora os limites, sem hype:

• a saída do modelo é rascunho, não laudo
• inconsistência de formato já foi relatada em modelos Gemini anteriores, então a checagem do passo 6 não é opcional
• os benchmarks divulgados do Carbon medem encontrar, explorar e corrigir vulnerabilidades, não a qualidade de um threat model de arquitetura
• não há confirmação de como os guardrails do Carbon vão tratar prompts de threat modeling quando ele abrir pra usuários comuns

A decisão final continua com o time, beleza?

Vídeo: quando o problema não é o modelo

Pra complementar, tem esse vídeo do canal Hora de Codar sobre o Better Harness e a ideia de que muitas vezes a falha de um agente está no harness em volta dele, não no modelo

A lição é a mesma dos passos acima: prompt e estrutura ruins derrubam até modelo forte

Próximo passo: rode o método no Argon e deixe o prompt pronto para o Carbon

Pega UMA feature do teu backlog atual, de preferência uma que cruze fronteira de confiança, e aplica os seis passos com o Gemini 4 Argon

Leva os itens gerados pra próxima revisão do time e deixa o pessoal preencher a decisão de cada um

Se for pela API, lembra que o preço introdutório do Argon vale até 30/11/2026

E guarda o prompt estruturado: como o Carbon segue sem data pra desenvolvedores, o mesmo pedido pode ser reaproveitado quando houver ID de modelo publicado 😀

Até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.