Caça autônoma gerenciada: o dado do alvo isolado por arquitetura

O dado que você toca é o verdadeiro problema

Caçar bug de verdade não é disparar payload no escuro. Para provar um IDOR, você lê o registro real de outro cliente. Para provar um bypass de autenticação, você observa cookies, tokens e sessões vivas. Para provar uma falha de checkout, você manipula um fluxo de pagamento real. Tudo isso é dado sensível do alvo, e a pergunta que quase nenhuma plataforma de "pentest com IA" responde de frente é: para onde esse dado vai?

Numa SaaS multi-tenant comum, esse dado transita por uma infraestrutura compartilhada, e nem sempre fica claro o quanto ela isola um cliente do outro. Em bug bounty, onde o próprio programa costuma restringir por ToS quem enxerga o quê, isso é um problema antes de ser conveniência. O EVERSEC RAGE assume esse risco de frente: cada tenant roda isolado por arquitetura, não por promessa de contrato. O dado do alvo é processado dentro de um sandbox dedicado e nunca cruza com o de outro cliente.

gVisor: cada worker num kernel isolado

O agente não é um script educado. Ele executa ferramenta ofensiva (fuzzers, scanners, payloads gerados na hora) e ingere respostas de um alvo potencialmente hostil. Uma resposta maliciosa, ou um bug na própria ferramenta, não pode virar pivô para o host.

Por isso cada worker de caça roda num pod isolado com gVisor. gVisor é um kernel de aplicação em espaço de usuário: intercepta as syscalls do processo e as atende ele mesmo, em vez de expô-las direto ao kernel do host. A superfície que um container comum deixa aberta (o kernel Linux inteiro) fica atrás dessa fronteira. Some a isso o firewall de egress: o pod fala com o alvo e com o que você autorizou, não com o resto do cluster nem com os workers de outros tenants. Se um exploit que o agente dispara for virado contra ele, o estrago fica confinado a um pod descartável, isolado por tenant, não escala para os seus outros alvos nem para os dados de outro cliente.

Escopo fail-closed: a régua vive no código, não no modelo

A parte mais importante do modelo de segurança é o que o agente NÃO decide. O escopo é fail-closed, determinístico e fora do modelo: o agente propõe alvos, o código autoriza, e o default é negar.

E a régua não é escrita por quem ela gateia. Escopo derivado do programa publicado (a URL oficial) entra direto; ativos que VOCÊ escolheu à mão exigem ratificação humana antes de valer. Isso fecha a classe de furo em que o agente "se autoriza" a tocar algo fora de escopo, ou acha uma rota alternativa até o bloqueio sumir. Um gate que bloqueia não é obstáculo a contornar: é a decisão saindo do modelo e indo para o operador humano.

Por que o dado não vaza

Duas peças fecham o círculo. A inferência é BYO-key: você usa a sua própria chave de LLM (ou o roteador multi-provedor grátis), e a credencial só é decifrada dentro do pod efêmero do job, nunca logada, nunca reaproveitada fora dali. E o acervo (findings, RAG, payloads, evidência) fica isolado por tenant no Postgres, sob FORCE-RLS: row-level security que nenhuma role da aplicação consegue contornar, nem por engano.

O agente ainda pode alcançar e visualizar dado real para provar consequência, inclusive em produção, quando essa é a única forma de demonstrar impacto. A diferença é onde a prova repousa: isolada por tenant, sob FORCE-RLS e sandbox dedicado, nunca misturada com o de outro cliente.

Autonomia não é ausência de freio

Rodar de forma autônoma não é rodar solto. Todo finding passa por um firewall de 10 gates, com AutoReject e confiança recomputada antes de virar report, e o juiz é código, não a IA. A severidade é derivada da evidência (CVSS 4.0), e nada é submetido sem aprovação humana: zero auto-submit.

Se a ideia de dado do alvo transitando por uma infraestrutura compartilhada, sem isolamento claro entre clientes, sempre te incomodou, talvez seja esse o modelo que você procurava: automatizar a caça sem terceirizar o risco. Vale conhecer o EVERSEC RAGE e ver o isolamento por tenant garantido pela arquitetura, não por confiança.