pentest-ai

Non segnala. Dimostra.

Sito web · Installa · Perché la verifica · Benchmark · Limiti · Discord

⚠️ Strumenti offensivi, solo per test autorizzati. Installando accetti l'AUP e i Termini. Vedi Uso responsabile ↓

Due minuti, nessuna API key, nessun target tuo

pip install ptai && ptai demo

ptai demo scansiona un'app vulnerabile inclusa e stampa 4 findings, 3 oracle-VERIFIED. Ne riproduce uno dal vivo da una proof capsule (replay 3/3), poi esegue le stesse route in versione corretta e stampa 0 findings.

Due cose da notare. I findings compaiono e scompaiono con la vulnerabilità piuttosto che perché lo strumento è rimasto silenzioso — l'unica cosa cambiata tra le due esecuzioni è la correzione. E uno dei quattro resta un candidato: il bypass del login SQLi è reale, ma nessun oracle ha potuto ri-dimostrarlo su quella route, quindi non ottiene un badge. Quel divario è il prodotto che funziona, non un bug nella demo.

Cosa significa realmente VERIFIED qui

La maggior parte degli scanner ti dice che una cosa potrebbe essere sfruttabile e lascia a te il triage. ptai tratta un finding come un candidato finché un oracle macchina nominato non riesegue l'exploit e lo riproduce N volte su N. Solo allora ottiene VERIFIED.

Tre proprietà rendono questo più di uno slogan:

Nessun LLM produce mai un verdetto. La regola è applicata nel codice, non da una policy: un verdetto che non può nominare l'oracle che se l'è guadagnato viene rifiutato. Un LLM coordina l'esecuzione e ragiona sui risultati. Non decide mai se un bug è reale.

Ogni oracle ha un controllo che deve fallire. Un bypass trusted-header deve restituire contenuto privilegiato con l'header e un rifiuto senza di esso. Un controllo di credenziali leaked deve essere accettato per il segreto reale e rifiutato per un gemello deliberatamente corrotto. Un endpoint che risponde 200 a tutto non guadagna nulla. Questo è ciò che impedisce che "ha restituito 200" venga scambiato per prova.

L'output di scanner di terze parti viene trattenuto. I risultati di nuclei, nikto e zap non diventano findings sulla loro sola autorità. Restano non verificati finché uno degli oracle di ptai non li ri-dimostra in modo indipendente.

Ogni finding VERIFIED viene fornito come una proof capsule portabile — il finding, la ricetta per ri-dimostrarlo e la ricevuta. Chiunque può eseguire ptai replay contro il target live e vedere l'oracle ri-confermare, senza fidarsi di ptai. Le capsule sono deliberatamente non firmate: il replay è il meccanismo di fiducia, non una firma che devi accettare per fede.

Numeri onesti

Su un honeypot deliberatamente vulnerabile, 23 findings si verificano attraverso quelle 14 classi con precisione del 100% e zero falsi positivi. Su un OWASP Juice Shop standard, 17 findings verificati nella scansione del 2026-08-23 — riporta HTTP in-scope / verificati / precisione, non 17/116. Una sessione MCP Path 1 del 2026-08-25 (client MCP che guida run_probe, target morto prima della verifica dell'orchestratore) ha ottenuto 12 prove verificate con precisione del 100% contro 64 challenge HTTP in-scope (20 will-not-chase). Le chiavi OSINT, Web3 e solo-UI di Juice Shop sono fuori dal tabellone di automazione per design.

Leggi quei numeri con attenzione, perché i divari sono il punto. Esistono 64 probe ma solo 30 possono ottenere un verdetto; le altre 34 riportano candidati onesti. 203 wrapper sono registrati ma solo 18 trasformano l'output degli strumenti in findings — gli altri eseguono e restituiscono testo grezzo. Il gate degli oracle compra precisione, non tasso di rilevamento: rimuove i falsi positivi, non trova più bug.

L'harness dell'honeypot (tests/honeypot/) e un gate zero-falsi-positivi su app pulita (tests/cleanapp/) sono entrambi inclusi in questo repo e girano in CI, quindi sono riproducibili e non screenshot.

Cosa non fa

Detto chiaramente, perché uno strumento di sicurezza che si sopravvaluta è peggio che inutile.

• È uno scanner di applicazioni web. Tutte le 64 probe e tutti i 24 tipi di oracle targettizzano HTTP. AD, cloud, mobile e wireless hanno agenti e wrapper di strumenti, ma nessuna libreria di probe e nessun oracle dietro di essi.
• Non può fare privilege escalation locale. Serve esecuzione di codice su un host che già possiedi. ptai testa da remoto e non ha tale canale, quindi l'agente privesc riporta unsupported invece di uno zero fuorviante.
• Non è uno scanner CVE. Non c'è un database versione-a-CVE né una libreria di exploit. Il lavoro sui CVE è limitato alle ricerche su osv.dev su manifest leaked.
• I playbook pianificano, non eseguono. ptai playbook run risolve le dipendenze e stampa il piano. Eseguirlo contro un target non è ancora collegato.
• Non è autonomo. Gli agenti LLM di pentest completamente autonomi completano il 21–31% dei task end to end; le configurazioni assistite da umani raggiungono il 64%. ptai è costruito per il secondo regime. Premi Ctrl+C due volte per prendere il controllo a metà esecuzione.

La lista completa dei difetti interni, incluso tutto quanto sopra, è tracciata apertamente anziché in silenzio. Se qualcosa qui è sbagliato, apri una issue e verrà corretto.

Installazione

pip install ptai
ptai mcp install          # rileva automaticamente i tuoi client MCP e scrive le loro config