Someone mentioned a tool called "Pentest GPT" — does anyone actually use this on pentests we've quoted?

The tool is essentially a prompt-chaining wrapper that parses network or vulnerability scan outputs fed by the tester and suggests which tool to run next. It queries a public AI model under the hood. Copy-pasting that output straight into a report is guaranteed to miss business logic vulnerabilities.

Did the low-bid firm agree to sign a confidentiality and data retention protocol? If they can't provide a technical guarantee that test data won't hit public servers, is that a risk worth taking for software running financial credit scoring?

We had a similar automation-heavy pentest done last year in the 50,000 TL range. Nearly eighty percent of the report was standard automated scanner output, and they completely missed a critical privilege escalation flaw in our payment flow. When we later paid 110,000 TL for proper manual testing, the real vulnerabilities surfaced.

In this industry, "we cut costs" usually translates to "we dumped the work on an intern who's feeding commands into a tool." AI is great as a supplementary tool, but if they're pitching it as a cost advantage, they're skimping on expert manual effort.

Speak with the firm again and require them to include manual verification evidence for every single finding in the report. Make it clear upfront that you will not accept a list of hypothetical vulnerabilities spit out by a tool.

we set up that tool to try it out too, it shows basic commands but completely misses logic flaws like authorization checks but definitely cant be trusted on its own for a finance project, be sure to put an ai restriction in the contract.

In accordance with the regulations governing institutions that process financial data, the uncontrolled transfer of internal network and customer data collected during testing processes to overseas cloud services may result in regulatory violations. It is recommended that you request a written data flow diagram from your service provider.

there are three things to check when doing this... if permission and scope arent in writing dont strt that test.

correct me if Im wrong.

Thanks a lot, I'll try it today.

I didn't know that.

Here's how it went for us. If permission and scope aren't in writing, don't start that test.

That's all, sorry if I went on too long.

My perspective changed after experiencing that. Most incidents start with a leaked password, not a vulnerability.

The answer above hits the nail on the head. Most incidents start with a leaked password, not a vulnerability.

This thread is archived.

Good call starting this thread. Trying to do this alone is the most expensive way.

If I were you, Id go this route.

I'm curious too.

There's a trap here, let me mention it. When we decide without measuring, we always end up in the same place.

Saved.