pentest-ai

Não sinaliza. Comprova.

Website · Instalação · Porquê verificação · Benchmarks · Limites · Discord

⚠️ Ferramenta ofensiva, apenas para testes autorizados. Ao instalar, aceita a AUP e os Termos. Ver Uso responsável ↓

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

pip install ptai && ptai demo

ptai demo analisa uma aplicação vulnerável incluída e imprime 4 findings, 3 oracle-VERIFIED. Reproduz uma em direto a partir de uma cápsula de prova (replay 3/3), depois executa as mesmas rotas corrigidas e imprime 0 findings.

Duas coisas a notar. Os findings aparecem e desaparecem com a vulnerabilidade em vez de 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 re-provar naquela rota, por isso não recebe um selo. Essa lacuna é o produto a funcionar, não um bug na demo.

O que VERIFIED significa realmente aqui

A maioria dos scanners diz-lhe que uma coisa pode ser explorável e deixa a triagem consigo. O ptai trata um finding como candidato até um oracle de máquina nomeado re-executar o exploit e reproduzi-lo N de N vezes. Só então ganha VERIFIED.

Três propriedades tornam isto mais do que um slogan:

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

Cada oracle tem um controlo que tem de falhar. Um bypass de header de confiança tem de devolver conteúdo privilegiado com o header e uma negação sem ele. Uma verificação de credenciais vazadas tem de ser aceite para o segredo real e rejeitada para um gémeo deliberadamente corrompido. Um endpoint que responde 200 a tudo não ganha nada. Isto é o que impede "devolveu 200" de ser confundido com prova.

A saída de scanners de terceiros é retida. Os resultados de nuclei, nikto e zap não se tornam findings por autoridade própria. Permanecem não verificados até um dos oracles do próprio ptai os re-provar de forma independente.

Cada finding VERIFIED é entregue como uma cápsula de prova portátil — o finding, a receita para o re-provar e o recibo. Qualquer pessoa pode ptai replay contra o alvo em direto e ver o oracle re-confirmar, sem confiar no ptai. As cápsulas são deliberadamente não assinadas: a reprodução é o mecanismo de confiança, não uma assinatura que tem de aceitar por fé.

Números honestos

Num honeypot deliberadamente vulnerável, 23 findings verificam-se nessas 14 classes com 100% de precisão e zero falsos positivos. Num OWASP Juice Shop padrão, 12 verificam-se numa única análise.

Leia esses números com atenção, porque as lacunas são o ponto. Existem 63 sondas mas apenas 28 podem ganhar um veredicto; as outras 35 reportam candidatos honestos. 203 wrappers estão registados mas apenas 18 transformam a saída de ferramentas em findings — o resto executa e devolve texto bruto. O portão de oracle compra precisão, não taxa de captura: remove falsos positivos, não encontra mais bugs.

O harness de honeypot (tests/honeypot/) e um portão de zero falsos positivos em app limpa (tests/cleanapp/) estão ambos neste repositório e correm em CI, por isso são reproduzíveis em vez de capturas de ecrã.

O que não faz

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

• É um scanner de aplicações web. Todas as 63 sondas e todos os 23 tipos de oracle visam HTTP. AD, cloud, mobile e wireless têm agentes e wrappers de ferramentas, mas sem biblioteca de sondas e sem oracles por trás.
• Não consegue fazer escalada de privilégios local. Isso requer execução de código num host que já possui. O ptai testa remotamente e não tem esse canal, por isso o agente de privesc reporta unsupported em vez de um zero enganador.
• Não é um scanner de CVEs. Não existe base de dados versão-para-CVE nem biblioteca de exploits. O trabalho de CVE limita-se a consultas osv.dev em manifests vazados.
• Os playbooks planeiam, não executam. ptai playbook run resolve dependências e imprime o plano. Executá-lo contra um alvo ainda não está ligado.
• Não é autónomo. Agentes de pentest LLM totalmente autónomos concluem 21–31% das tarefas de ponta a ponta; configurações assistidas por humanos chegam a 64%. O ptai é construído para o segundo regime. Prima Ctrl+C duas vezes para assumir o controlo a meio da execução.

A lista interna completa de defeitos, incluindo tudo o que está acima, é rastreada abertamente em vez de silenciosamente. Se algo aqui estiver errado, abra um issue e será corrigido.

Instalação

pip install ptai
ptai mcp install          # deteta automaticamente os seus clientes MCP e escreve as suas configurações

pip install ptai
export ANTHROPIC_API_KEY=sk-...        # ou OPENAI_API_KEY
ptai start https://target.example.com

# totalmente local, sem cloud:
export PENTEST_AI_LLM_PROVIDER=ollama

# ou determinístico, sem LLM nenhum:
ptai start https://target.example.com --no-llm

ptai tools install --tier core     # ou recommended / full
ptai tools install nmap nuclei     # ou por nome
ptai serve                         # HTTP REST + WebSocket para dashboards
ptai menu                          # lançador interativo, sem LLM

Benchmarks

Reproduzíveis, em git, com artefactos brutos. Sem "taxa de deteção de 98,7%" que não pode auditar.

n=1, avaliador único, tentativa única em OWASP Juice Shop. Metodologia e saída bruta em benchmarks/; relatório completo em docs/benchmarks/juice-shop.md.

A leitura honesta: o ptai é forte em alvos web SPA com cobertura de sondas curada. O HexStrike é mais amplo (cloud, binário, CTF) e provavelmente supera o ptai em superfícies tradicionais rastreáveis como WordPress. O Juice Shop é também a app vulnerável mais documentada na internet, por isso tanto o LLM como os autores das sondas têm vantagem — o que é exatamente por que o número do honeypot privado é mais baixo, e por que ambos são publicados.

Integre-o no CI

- run: pip install ptai
- run: ptai start ${{ vars.STAGING_URL }} --ci --fail-on verified --sarif pentest.sarif
- uses: github/codeql-action/upload-sarif@v3
  with: { sarif_file: pentest.sarif }

--fail-on verified quebra o build apenas num finding que um oracle realmente provou, por isso o portão não pode ser acionado por ruído de scanner. SARIF é enviado para GitHub Code Scanning, findings são publicados como comentário de PR. Modelos GitLab e Jenkins em docs/ci-cd.md.

Como funciona

recon ──▶ auth ──▶ web ──┬──▶ ad
                         ├──▶ cloud          ┌──────────────────┐
                         └──▶ api ──────────▶│  findings DB     │
                                             │  scope-guarded   │
                                             └────────┬─────────┘
                                                      ▼
                                          verify (oracles, N/N)
                                                      ▼
                                   chain ─▶ validate ─▶ detect ─▶ report
                                          md · html · pdf · SARIF · JUnit

18 agentes especialistas executam as fases. Com uma chave de API, cada um usa um LLM para raciocinar sobre os resultados; sem ela, executa como um loop de ferramentas determinístico. A ordem das fases e a deteção são idênticas em ambos os casos — as sondas encontram os bugs, o LLM apenas coordena.

Para quem é

Equipas de AppSec que ligam uma análise autenticada a cada PR, com um portão que só aciona em findings provados. Consultores que querem que o relatório se escreva sozinho e uma cápsula que os próprios engenheiros do cliente possam reproduzir. Caçadores de bug bounty que preferem triar 12 findings provados do que 600 talvez. Utilizadores de Claude Code / Cursor / Codex que querem ferramentas reais por trás do seu assistente sem outra fatura de API.

Trabalhe comigo

A ferramenta é MIT e gratuita para sempre — isso não vai mudar.

Se quiser um pentest entregue em vez de executá-lo você mesmo, ou um workspace alojado com histórico e acesso de equipa, ambos estão em pentestai.xyz. Cada finding num engagement entregue vem com uma cápsula de prova que os seus engenheiros podem reproduzir eles próprios, o que é um artefacto materialmente diferente de um PDF cheio de classificações de severidade.

Perguntas: [email protected]

Uso responsável

O ptai executa operações reais de rede e host contra os alvos que especifica. É o único responsável por ter autorização escrita explícita para cada alvo. Testar sistemas que não possui pode violar o Computer Fraud and Abuse Act, o Computer Misuse Act 1990, o Artigo 32 do GDPR e equivalentes noutros locais.

A primeira execução pede aceitação da AUP e persiste-a. Defina PENTEST_AI_AUP_ACCEPTED=1 em CI. Hosts fora do âmbito são recusados no momento da invocação da ferramenta. Três salvaguardas vêm desligadas por predefinição e valem a pena ativar: intensity=safe salta sondas que mutam estado, respect_rate_limits honra 429/Retry-After, e strict_scope recusa pedidos fora do host.

ptai start http://target --oast-server https://oast.example.com --oast-token <T>
ptai start http://target --no-oast          # ou desative completamente

FAQ

Preciso de uma chave de API? Não no caminho MCP — a sua subscrição Claude Code / Cursor / Codex é o LLM. Apenas a CLI autónoma precisa de uma, e mesmo aí o Ollama executa totalmente local.

É autónomo? Não, e não afirma ser. As sondas detetam, o LLM coordena, você decide. Ctrl+C duas vezes assume o controlo a meio da execução.

Seguro contra produção? Apenas com autorização escrita e as três salvaguardas acima ativadas.

Faz chamadas para casa? Sem telemetria; os findings permanecem no seu disco. Os callbacks OAST são a única exceção — veja acima, ou execute --no-oast.

Em que é diferente de pedir ao Claude para hackear algo? Uma biblioteca determinística de sondas curada encontra os bugs e um oracle de máquina prova-os. Um LLM sozinho dá-lhe uma suposição plausível sem forma de saber se é real.

Ecossistema

Comunidade: Discord · Discussões · Issues

Histórico de estrelas

Licença

MIT. Faça o que quiser com ela.