O que incluir no contexto de um asset

O contexto fornece 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 seu treinamento é ruído, e o ruído dilui os resultados.

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 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 função de usuário pode fazer, quais módulos de negócio têm lógica crítica ou qual regulaçã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 de pentest padrão. Se você consegue encontrá-lo em qualquer guia da OWASP ou em um curso de segurança, o agente já sabe.

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 de relatório e a estrutura dos achados

• A metodologia genérica de pentest

Incluir tudo isso adiciona informações que o agente não precisa. Um detalhe curado sobre o que importa produz um contexto —e objetivos— de maior qualidade.

O que precisa estar presente

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

Inclua as informações específicas da sua organização:

• Funções e permissões: cada função de usuário com suas ações concretas: o que pode visualizar, criar, modificar e executar. Nada de nomes genéricos: o que este Admin faz neste aplicativo.

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

• Regulações aplicáveis: apenas 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).

• Contas de teste: um usuário real para cada função a ser avaliada. Se as credenciais forem fornecidas separadamente, indique no contexto que estão disponíveis e sob qual nome.

• Restrições operacionais: se o scope é produção, se há transações reais em jogo, os horários permitidos ou se existe um bypass de WAF para os IPs de teste.

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

Exemplo anotado

O mesmo contexto, com cada parte classificada conforme agregue valor ou não.

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

⚠ Se o scope incluir produção com transações reais (PIX, pagamentos, transferências), você precisa indicar isso explicitamente no contexto e confirmar se existe um ambiente sandbox. Sem essa indicação, o agente pode executar operações com impacto financeiro real durante o teste.

Inclua quando há dinheiro real em jogo:

• Ambiente: produção, staging ou sandbox. Se for produção, confirme 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 scope: o que não pode ser tocado. É tão importante quanto o scope: sem limites definidos, o agente não tem uma âncora para parar.

Checklist rápido

Antes de enviar o contexto, verifique se ele tem o seguinte:

• Um usuário de teste para cada função

• As ações e permissões concretas de cada função

• Os módulos de negócio com sua lógica específica

• O out-of-scope definido explicitamente

• As regulações que se aplicam e por quê

• Se houver produção: a indicação sobre operações reais

• As restrições de horário ou de WAF, se aplicável