O que incluir na Description de um asset e em Additional information

Last updated: October 20, 2026

O contexto dá ao agente de IA da Strike as informações específicas da sua empresa que ele não consegue inferir sozinho. Tudo o que o agente já sabe pelo treinamento é ruído, e o ruído dilui os resultados.

Há dois lugares onde você carrega contexto:

  • Description, no asset: descreve o que é o asset e como ele funciona. Vale para todas as Threat Emulations que o incluem.

  • Additional information, na Threat Emulation: detalhes que se aplicam somente a essa Threat Emulation.

Por que importa o que você inclui

O agente conhece OWASP, PCI DSS, as técnicas de escalação de privilégios e como testar a autenticação. Esse conhecimento já está incorporado: você não precisa explicá-lo.

O que o agente não conhece é a arquitetura da sua empresa: o que cada papel de usuário pode fazer, quais módulos de negócio têm lógica crítica ou qual regulamentação específica se aplica ao seu setor.

Um contexto bem construído produz objetivos de testing focados no que é único do seu sistema. Um contexto com ruído faz o agente perder o foco no que realmente importa.

O que você não precisa incluir

Não repita conhecimento padrão de pentest. Se você consegue encontrá-lo em qualquer guia da OWASP ou em um curso de segurança, o agente já o conhece.

Omita o que o agente já sabe:

  • OWASP Top 10 / OWASP API Top 10

  • Checklists de autenticação e sessões

  • Listas de SQLi, XSS, SSRF etc.

  • A descrição do que é PCI DSS ou ISO 27001

  • O formato do relatório e a estrutura dos achados

  • A metodologia genérica de pentest

Incluir tudo isso agrega informações de que o agente não precisa. Um detalhe curado sobre o que importa produz um contexto de maior qualidade, e também melhores objetivos de testing.

O que precisa estar

A regra é simples: se não está no contexto, o agente não consegue inferir.

Na Description do asset

  • O que o asset faz: o propósito e os fluxos principais.

  • Módulos de negócio: os módulos próprios do seu sistema com a lógica específica deles: fluxos de aprovação, limites financeiros, cadeias de autorização, operações que envolvem dinheiro real.

  • Dados sensíveis: que tipo de informação o asset manipula.

  • Regulamentações aplicáveis: somente as que realmente se aplicam ao seu caso. Não liste todas as que existem; indique quais são obrigatórias e por quê (setor, país, tipo de dado).

  • Multi-tenancy: se a plataforma atende várias empresas ou clientes, indique. O isolamento entre tenants é um dos vetores mais críticos e exige contexto específico.

  • Ambiente e operações reais: se o asset está em produção e executa transações reais, e quais partes não podem ser tocadas. Veja o caso especial mais abaixo.

Em Additional information da Threat Emulation

  • Fluxos críticos que atravessam vários assets da Threat Emulation.

  • O foco ou os esclarecimentos que se aplicam somente a essa Threat Emulation.

  • Algo que fica fora do escopo somente nessa Threat Emulation.

O que tem campo próprio

Algumas coisas não vão no texto, porque têm um lugar específico na plataforma:

O quê

Onde é configurado

Usuários e senhas, cookies ou headers de teste

Nas credenciais do asset.

Horários em que não é possível testar

Em Schedule restrictions, dentro das restrições da Threat Emulation.

Testes que você não quer que sejam executados

Em Exclude tests, dentro das restrições da Threat Emulation.

IPs da Strike no seu firewall ou WAF

São autorizados do seu lado. Consulte Como autorizar os IPs da Strike.

Caso especial: produção com operações reais

Se o asset está em produção e executa transações reais (PIX, pagamentos, transferências), indique isso explicitamente na Description dele e esclareça se existe um ambiente sandbox. Sem esse esclarecimento, o agente pode executar operações com impacto financeiro real durante o testing.

Inclua quando houver dinheiro real em jogo:

  • Ambiente: produção, staging ou sandbox. Se for produção, confirme isso explicitamente.

  • Operações reais: se os módulos financeiros executam transações reais ou simuladas, e se o provedor de pagamentos tem um modo de teste.

  • Fora do escopo: o que não pode ser tocado. É tão importante quanto o escopo: sem limites definidos, o agente não tem uma âncora para parar.

Se algo fica fora do escopo somente em uma Threat Emulation específica, indique isso no Additional information dela.

Checklist rápido

Antes de confirmar, verifique se você tem:

  • Na Description: as ações e permissões concretas de cada papel.

  • Na Description: os módulos de negócio com a lógica específica deles.

  • Na Description: as regulamentações que se aplicam e por quê.

  • Na Description: se há produção, o esclarecimento sobre operações reais e o fora do escopo.

  • Nas credenciais: um usuário de teste para cada papel.

  • Nas restrições da Threat Emulation: os horários e testes excluídos, se aplicarem.

  • Em Additional information: o que se aplica somente a essa Threat Emulation.