Como o agente de IA da Strike opera sobre os seus assets: alcance, limites e controles

O agente de IA da Strike é o agente que executa as threat emulations sobre os seus assets. Este artigo explica como ele é desenhado para operar de forma segura em ambientes produtivos, o que pode fazer, o que não pode fazer, e quais controles existem para auditar o seu comportamento.

ℹ O objetivo deste artigo é dar visibilidade completa de como o agente interage com os seus sistemas, para que você possa apresentar a Strike internamente com confiança às equipes de segurança, compliance e leadership.

Princípios de operação

O agente de IA opera sob quatro princípios que guiam cada decisão que toma durante uma execução:

• Impacto mínimo: o agente reúne evidências suficientes para validar uma vulnerabilidade utilizando, por padrão, a evidência mínima necessária. Quando o cliente autoriza explicitamente, a Strike pode realizar uma exploração controlada para validar o impacto real do achado.

• Somente leitura por padrão: por padrão, o agente nunca modifica, exclui nem persiste dados em produção. Quando uma validação exige ações adicionais, elas só são realizadas com autorização explícita do cliente e dentro do escopo definido.

• Scope estrito: opera unicamente sobre os assets que você autoriza. Não se move lateralmente para sistemas adjacentes nem acessa recursos fora do scope definido.

• Postura de atacante externo: salvo em pentests whitebox, onde recebe credenciais de teste, o agente atua como um atacante externo sem privilégios prévios. Só acessa o que qualquer ator externo poderia ver de fora da sua organização.

O que o agente de IA faz

O agente executa as técnicas que um pentester profissional aplicaria sobre o seu asset, dentro dos limites do scope autorizado:

• Reconhecimento e enumeração: identifica superfícies expostas, endpoints, parâmetros, comportamentos do asset.

• Detecção de vulnerabilidades: testa vetores de ataque comuns (OWASP Top 10, falhas de lógica de negócio, IDOR, broken access control, injeções, falhas de autenticação, entre outros).

• Validação de impacto: por padrão, o agente demonstra que o acesso não autorizado é possível sem extrair dados. Quando o cliente autoriza explicitamente, a Strike pode realizar uma exploração controlada para validar o impacto real.

• Documentação com evidência: cada finding é registrado com os passos seguidos, o payload utilizado e a evidência mínima que prova a vulnerabilidade.

Sobre a escalação de privilégios

Sim, o agente pode tentar escalar privilégios quando necessário para validar o impacto real de uma vulnerabilidade, sempre dentro do escopo autorizado e com o menor impacto possível.

Certa família de vulnerabilidades (como IDOR, broken access control ou falhas de privilégios) só pode ser confirmada testando com múltiplos contextos de usuário. Dizer "este endpoint parece vulnerável" não é o mesmo que demonstrar "este usuário pode acessar dados do role X". Por isso o agente pode tentar escalar privilégios quando for a única forma de quantificar o impacto real do finding.

O que o agente nunca faz com os privilégios que obtém:

• Usar o acesso obtido para se mover lateralmente para sistemas fora do scope.

• Acessar recursos que não estejam explicitamente autorizados.

• Persistir o acesso, instalar backdoors ou manter sessões ativas além da execução.

O objetivo é sempre demonstrar o risco com o menor impacto possível, sem abusar do acesso obtido nem ultrapassar o escopo autorizado.

O que o agente de IA nunca faz

Estes comportamentos estão explicitamente proibidos nas regras que governam o agente e fazem parte do desenho do sistema:

Não acessa contas de outros clientes em produção

Em plataformas multi-tenant, o agente tem explicitamente fora de scope qualquer dado ou conta que pertença a outros clientes ou tenants. Isso é garantido por várias camadas:

• O agente opera como um atacante externo sem privilégios prévios. Trabalha com contas que ele mesmo registra durante a execução, ou com contas de teste que a sua equipe fornece. Não utiliza, nem tem como utilizar, contas reais de outros usuários da sua plataforma.

• Nas suas regras de operação, o acesso a contas ou dados de outros clientes está marcado como um limite duro: o agente não tem autorização para tentar, ainda que tecnicamente fosse possível.

• Se no curso de um teste detecta uma vulnerabilidade que poderia permitir acesso a dados de terceiros (por exemplo, um IDOR que expõe registros de outros usuários), o agente documenta a existência do problema com evidência mínima — tipicamente confirma que o endpoint é vulnerável e obtém um registro ou uma contagem, não baixa nem extrai dados reais de outros clientes.

Não destrói nem modifica dados em produção

O agente tem proibida qualquer ação destrutiva sobre dados produtivos:

• Não exclui registros, arquivos nem configurações.

• Não modifica dados existentes (não edita registros de outros usuários, não muda configurações do sistema, não altera o estado de transações).

• Não envia e-mails, notificações nem ações reais em nome de usuários reais.

• Não realiza transações financeiras nem operações com efeitos econômicos.

Quando uma vulnerabilidade teórica exigiria uma ação destrutiva para ser confirmada, o agente documenta o finding com a evidência que tem até o ponto anterior à ação destrutiva, e deixa registro de por que a ação não foi completada.

Não se move fora do scope autorizado

Cada threat emulation tem um scope claramente delimitado pelo asset configurado, as restrictions definidas e os repos vinculados (no caso dos Change-Based Tests). O agente não se move para:

• Outros assets não autorizados, mesmo que sejam acessíveis a partir do asset sob teste.

• Sistemas adjacentes (bancos de dados, serviços internos, redes corporativas) que estejam acessíveis a partir do asset.

• URLs ou endpoints excluídos explicitamente nas restrictions do asset.

Não persiste acesso

O agente não instala backdoors, não cria usuários novos com privilégios elevados, não deixa webshells, não mantém sessões ativas além do tempo de execução. Cada threat emulation é um evento autocontido que começa e termina em uma janela de tempo definida.

Não expõe PII nos relatórios

Quando uma vulnerabilidade envolve dados pessoais ou sensíveis, o agente mascara a PII antes de incluir a evidência no relatório. O que aparece no relatório é prova de que o acesso foi possível, não os dados reais.

Como o comportamento do agente é controlado e auditado

O agente de IA não é uma caixa preta. O seu comportamento é controlado por múltiplas camadas e fica registrado de ponta a ponta:

Camadas de controle

• Regras de operação (system rules): o agente opera sob um conjunto explícito de regras que definem o que pode e o que não pode fazer. Inclui os limites duros mencionados acima (não tocar contas de outros clientes, não destruir dados, não sair do scope, etc.).

• Camada de ética: uma camada adicional que aplica princípios transversais — somente leitura por padrão, minimização de impacto, proteção de PII.

• Scope técnico configurado por asset: as restrictions, credenciais e arquivos que você configura no nível do asset delimitam o espaço em que o agente pode operar.

• Triage humano: todo finding do agente de IA passa por triage do time da Strike antes de ser publicado. Isso inclui validar que o agente operou dentro do scope acordado e que a evidência coletada é proporcional ao finding.

Rastreabilidade completa

Cada execução fica registrada com:

• Traces de cada passo: a tab Trace dentro de cada threat emulation mostra o log completo das ações do agente: quais endpoints tocou, quais payloads enviou, quais respostas recebeu, quais decisões tomou.

• Evidência por finding: cada vulnerabilidade reportada inclui os passos exatos para reproduzi-la, com request/response e payload utilizado.

• PRs cobertos (Change-Based): em execuções change-based, a tab PRs tested detalha exatamente quais mudanças do código foram incluídas no scope.

Isso significa que, se a sua equipe de segurança ou compliance perguntar "o que exatamente o agente fez sobre o asset?", a resposta está no trace da execução — não exige confiar no que o agente diz ter feito.

Como apresentar isso à sua equipe de segurança

Se a sua equipe interna pedir garantias sobre como a Strike opera sobre os seus sistemas produtivos, os pontos-chave a transmitir são:

• Postura de atacante externo: o agente atua com os privilégios mínimos necessários, sem acesso especial.

• Somente leitura por padrão: As únicas ações de escrita que o agente executa são aquelas necessárias para manter sua própria sessão (por exemplo, registrar uma conta de teste), quando é explicitamente solicitado a validar um fluxo específico em um Focused Test, ou quando o cliente autoriza explicitamente uma exploração controlada como parte da validação.

• Contas de outros clientes fora de scope: explícito nas regras do agente e reforçado pela postura de atacante externo.

• Scope delimitado e controlável: você define quais assets, quais restrictions e quais credenciais. O agente não se move para fora disso.

• Triage humano do time da Strike: nenhum finding é publicado sem validação humana.

• Rastreabilidade total: cada ação fica registrada e é auditável a partir da plataforma.

Perguntas frequentes

A Strike pode apagar dados do meu banco de dados durante um teste?

Não. O agente tem proibida qualquer ação destrutiva sobre dados produtivos. Se durante um teste é detectada uma vulnerabilidade que poderia permitir o apagamento de dados (por exemplo, um endpoint vulnerável a injeção SQL com DELETE), o agente documenta o finding com a evidência anterior à ação destrutiva — nunca executa o apagamento.

Se o agente encontrar um IDOR que permite ver dados de outros clientes, o que ele faz?

Documenta a existência do IDOR com a evidência mínima necessária para confirmar o finding: tipicamente um registro ou uma contagem que prova que o acesso é possível. Não baixa nem extrai dados reais de outros clientes. A PII que pudesse aparecer nessa evidência mínima fica mascarada no relatório.

O agente pode gerar custos na minha conta (por exemplo, chamadas a APIs pagas)?

O agente pode gerar tráfego para o seu asset durante o teste, o que em alguns casos pode implicar consumo de serviços. Isso fica delimitado pelas restrictions do asset (rate limits, endpoints excluídos, janelas de tempo permitidas). Se o seu asset depende de serviços externos pagos sensíveis ao volume, configure as restrictions correspondentes na configuração do asset.

O que acontece se o agente afetar a disponibilidade do meu asset durante um teste?

O agente é desenhado para minimizar o impacto sobre a disponibilidade: respeita rate limits, evita técnicas que gerem DoS, e prioriza profundidade sobre volume. Se mesmo assim você detectar um problema de disponibilidade durante um teste, pode pausar a execução a partir da plataforma e entrar em contato com o seu Customer Success Manager para revisar o incidente.

Quem decide quais assets e qual scope?

Você. A Strike não descobre nem testa assets que você não tenha configurado explicitamente. O scope de cada threat emulation está definido pela configuração que a sua equipe carrega na plataforma.

Como posso auditar o que o agente fez em uma execução específica?

Abra a threat emulation e revise a tab Trace. Você vai ver o log completo das ações do agente: endpoints acessados, payloads enviados, respostas recebidas e decisões tomadas. Para findings específicos, cada um inclui os passos exatos de reprodução.