pentest-ai

Não sinaliza. Prova.

Website · Instalar · Por que verificação · Benchmarks · Limites · Discord

⚠️ Ferramentas ofensivas, apenas para testes autorizados. Ao instalar, você aceita a AUP e os Termos. Veja Uso responsável ↓

Dois minutos, sem chave de API, sem alvo próprio

pip install ptai && ptai demo

ptai demo escaneia um app vulnerável embutido e imprime 4 findings, 3 oracle-VERIFIED. Ele reproduz um ao vivo a partir de uma proof capsule (replay 3/3), depois executa as mesmas rotas endurecidas e imprime 0 findings.

Duas coisas a observar. Os findings aparecem e desaparecem com a vulnerabilidade, e não porque a ferramenta ficou silenciosa — a única coisa que mudou entre as duas execuções é a correção. E um dos quatro permanece como candidato: o bypass de login por SQLi é real, mas nenhum oracle conseguiu reprová-lo naquela rota, então ele não recebe um selo. Essa lacuna é o produto funcionando, não um bug na demo.

O que VERIFIED realmente significa aqui

A maioria dos scanners diz que algo pode ser explorável e deixa a triagem para você. O ptai trata um finding como candidato até que um oracle de máquina nomeado reexecute o exploit e o reproduza N de N vezes. Só então ele ganha VERIFIED.

Três propriedades fazem disso mais que um slogan:

Nenhum LLM produz um veredito. A regra é aplicada em código, não por política: um veredito que não consegue nomear o oracle que o conquistou é rejeitado. Um LLM coordena a execução e raciocina sobre os resultados. Ele nunca decide se um bug é real.

Todo oracle tem um controle que deve falhar. Um bypass de trusted-header precisa retornar conteúdo privilegiado com o header e uma negação sem ele. Uma verificação de credencial vazada precisa ser aceita para o segredo real e rejeitada para um gêmeo deliberadamente corrompido. Um endpoint que responde 200 para tudo não ganha nada. É isso que impede que "retornou 200" seja confundido com prova.

A saída de scanners de terceiros é retida. Resultados de nuclei, nikto e zap não se tornam findings por autoridade própria. Eles permanecem não verificados até que um dos oracles do próprio ptai os reprove de forma independente.

Cada finding VERIFIED é entregue como uma proof capsule portátil — o finding, a receita para reprová-lo e o recibo. Qualquer um pode fazer ptai replay contra o alvo ao vivo e ver o oracle reconfirmar, sem confiar no ptai. As capsules são deliberadamente não assinadas: o replay é o mecanismo de confiança, não uma assinatura que você precisa aceitar por fé.

Números honestos

Em um honeypot deliberadamente vulnerável, 23 findings verificam entre essas 14 classes com 100% de precisão e zero falsos positivos. Em um OWASP Juice Shop padrão, 17 findings foram verificados na varredura de 2026-08-23 — relate HTTP no escopo / verificado / precisão, não 17/116. Uma sessão Path 1 MCP de 2026-08-25 (cliente MCP conduzindo run_probe, alvo morreu antes da verificação do orquestrador) conquistou 12 provas verificadas com 100% de precisão contra 64 desafios HTTP no escopo (20 will-not-chase). Chaves de OSINT, Web3 e apenas UI do Juice Shop estão fora do placar de automação por design.

Leia esses números com atenção, porque as lacunas são o ponto. 64 probes existem mas apenas 30 podem ganhar um veredito; os outros 34 relatam candidatos honestos. 203 wrappers estão registrados mas apenas 18 transformam a saída da ferramenta em findings — o resto executa e devolve texto bruto. O portão do oracle compra precisão, não taxa de captura: ele remove falsos positivos, não encontra mais bugs.

O harness do honeypot (tests/honeypot/) e um portão de zero-falsos-positivos em app limpo (tests/cleanapp/) ambos são entregues neste repositório e rodam na CI, então esses números são reproduzíveis em vez de capturas de tela.

O que ele não faz

Dito claramente, porque uma ferramenta de segurança que se superestima é pior que inútil.

• É um scanner de aplicações web. Todos os 64 probes e todos os 24 tipos de oracle visam HTTP. AD, cloud, mobile e wireless têm agentes e wrappers de ferramentas, mas nenhuma biblioteca de probes e nenhum oracle por trás deles.
• Não consegue fazer escalonamento de privilégios local. Isso exige execução de código em um host que você já controla. O ptai testa remotamente e não tem esse canal, então o agente de privesc relata unsupported em vez de um zero enganoso.
• Não é um scanner de CVE. Não há banco de dados de versão para CVE nem biblioteca de exploits. O trabalho com CVE se limita a consultas ao osv.dev em manifests vazados.
• Playbooks planejam, não executam. ptai playbook run resolve dependências e imprime o plano. Executá-lo contra um alvo ainda não está implementado.
• Não é autônomo. Agentes de pentest LLM totalmente autônomos concluem 21–31% das tarefas de ponta a ponta; configurações com assistência humana chegam a 64%. O ptai é feito para o segundo regime. Pressione Ctrl+C duas vezes para assumir no meio da execução.

A lista completa de defeitos internos, incluindo tudo acima, é rastreada abertamente em vez de discretamente. Se algo aqui estiver errado, abra uma issue e será corrigido.

Instalar

pip install ptai
ptai mcp install          # auto-detects your MCP clients and writes their configs