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 seus assets. Este artigo explica como ele foi projetado para operar de forma segura em ambientes produtivos, o que ele pode fazer, o que não pode fazer e quais controles existem para auditar seu comportamento.

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

Princípios de operação

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

• Impacto mínimo: o agente busca evidência suficiente para confirmar uma vulnerabilidade usando, 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: nunca modifica, exclui nem persiste dados em produção como comportamento padrã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.

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

• Postura de atacante externo: exceto quando você configura credenciais de teste para testar o que está por trás do login, o agente age como um atacante externo sem privilégios prévios. Ele 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 seus assets, dentro dos limites do escopo autorizado:

• Reconhecimento e enumeração: identifica superfícies expostas, endpoints, parâmetros e 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 é 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 achado fica registrado com os passos seguidos, o payload utilizado e a evidência mínima que comprova a vulnerabilidade.

Sobre a escalada de privilégios

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

Certas famílias de vulnerabilidades (como IDOR, broken access control ou falhas de privilégios) só podem ser confirmadas 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 papel X". Por isso o agente pode tentar escalar privilégios quando essa é a única forma de quantificar o impacto real do achado.

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 escopo.

• 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, não abusar do acesso nem exceder o escopo autorizado.

O que o agente de IA nunca faz

Esses comportamentos são explicitamente proibidos nas regras que governam o agente e fazem parte do design do sistema.

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

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

• O agente opera como um atacante externo sem privilégios prévios. Ele trabalha com contas que ele mesmo registra durante a execução ou com contas de teste que sua equipe fornece. Ele não usa, nem tem como usar, 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 rígido: o agente não tem autorização para tentar isso, mesmo que fosse tecnicamente possível.

• Se durante uma execução ele 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. Normalmente ele confirma que o endpoint é vulnerável e obtém um registro ou uma contagem, mas não baixa nem extrai dados reais de outros clientes.

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

O agente é proibido de realizar 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 altera 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 achado com a evidência que tiver até o ponto anterior à ação destrutiva e registra por que a ação não foi concluída.

Não se move fora do escopo autorizado

Cada Threat Emulation tem um escopo delimitado pelos assets que inclui, pelas restrições que você define e, em uma Change-based Threat Emulation, pelos repositórios vinculados. O agente não se move para:

• Outros assets que não estejam incluídos na Threat Emulation, mesmo que sejam acessíveis a partir de um asset em escopo.

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

Não persiste acesso

O agente não instala backdoors, não cria novos usuários com privilégios elevados, não deixa webshells e não mantém sessões ativas além do tempo de execução. Cada execução é 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 é a 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. 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 ele pode e o que não pode fazer. Isso inclui os limites rígidos mencionados acima (não tocar em contas de outros clientes, não destruir dados, não sair do escopo, entre outros).

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

• Escopo técnico configurado: os assets que você inclui na Threat Emulation, suas credenciais e documentação técnica, e as restrições que você define delimitam o espaço em que o agente pode operar.

• Triagem humana: todo achado do agente de IA passa por triagem da equipe da Strike antes de ser publicado, e 100% dos achados críticos também são reproduzidos e validados manualmente. A triagem inclui validar que o agente operou dentro do escopo acordado e que a evidência coletada é proporcional ao achado.

Rastreabilidade completa

Cada execução fica registrada com:

• Traces de cada passo: a aba Trace dentro de cada execução mostra o log completo das ações do agente: quais endpoints ele tocou, quais payloads enviou, quais respostas recebeu e quais decisões tomou.

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

• PRs cobertos: em uma Change-based Threat Emulation, a aba PRs tested de cada execução detalha exatamente quais mudanças do código foram incluídas.

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

Como apresentar isso à sua equipe de segurança

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

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

• Somente leitura por padrão: nunca modifica dados produtivos. As únicas ações de escrita que ele executa são as 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 uma Focused Threat Emulation, ou quando o cliente autoriza explicitamente uma exploração controlada como parte da validação.

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

• Escopo delimitado e controlável: você define quais assets, quais restrições e quais credenciais. O agente não sai disso.

• Triagem humana da equipe da Strike: nenhum achado é publicado sem validação humana, e os achados críticos também são reproduzidos manualmente.

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

Perguntas frequentes

A Strike pode excluir dados do meu banco de dados durante uma execução?

Não. O agente é proibido de realizar qualquer ação destrutiva sobre dados produtivos. Se durante uma execução for detectada uma vulnerabilidade que poderia permitir a exclusão de dados (por exemplo, um endpoint vulnerável a injeção SQL com DELETE), o agente documenta o achado com a evidência anterior à ação destrutiva. Ele nunca executa a exclusão.

Se o agente encontra 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 achado: normalmente um registro ou uma contagem que comprova que o acesso é possível. Não baixa nem extrai dados reais de outros clientes. A PII que possa 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 seus assets durante uma execução, o que em alguns casos pode implicar consumo de serviços. Esse tráfego fica limitado pelas restrições da Threat Emulation (rate limit, restrições de horário e tipos de teste excluídos). Se seu asset depende de serviços externos pagos sensíveis ao volume, configure as restrições correspondentes na Threat Emulation.

O que acontece se o agente afetar a disponibilidade do meu asset durante uma execução?

O agente foi projetado 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, pode interromper a execução em andamento com Cancel execution e entrar em contato com seu Customer Success Manager para revisar o incidente. Para mais detalhes, consulte Como pausar uma Threat Emulation ou cancelar uma execução.

Quem decide quais assets e qual escopo?

Você. A Strike só testa os assets que você inclui nas suas Threat Emulations. O escopo de cada Threat Emulation é definido pela configuração que sua equipe carrega na plataforma.

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

Abra a Threat Emulation, acesse a execução pela aba Executions e revise a aba Trace. Você vai ver o log completo de ações do agente: endpoints acessados, payloads enviados, respostas recebidas e decisões tomadas. Além disso, cada achado inclui os passos exatos de reprodução.