Caça autônoma self-hosted: o dado do alvo não sai da sua máquina

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, ele transita pela infra do fornecedor. 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 Omni Pentest inverte a premissa: o agente roda na SUA infra, VPS ou k3s seu. O dado do alvo nasce e morre na sua máquina.

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 egress controlado por NetworkPolicy: o pod fala com o alvo e com o que você autorizou, não com o resto do cluster. Se um exploit que o agente dispara for virado contra ele, o estrago fica confinado a um pod descartável, não escala para os seus outros alvos nem para os seus segredos.

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 um roteador grátis multi-provedor), então o prompt vai do seu ambiente direto para o provedor que você escolheu, sem intermediário nosso. E o acervo (findings, RAG, payloads, evidência) fica no seu Postgres, isolado por tenant.

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: no seu disco, não no nosso.

Autonomia não é ausência de freio

Rodar na sua infra 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.

Se deixar o dado do alvo sair da sua máquina sempre te incomodou, talvez seja esse o modelo que você procurava: automatizar a caça sem terceirizar o risco. Vale rodar o agente no seu próprio VPS e ver o acervo ficar onde deveria estar.