Can AI find vulnerabilities that a human tester misses?

As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.

What kind of vulnerabilities does AI find that people miss?

Categories where the defect space is too wide for a person to hold in the head. Forgotten parameters, present in the code, exercised by nobody. Endpoints that exist behind a path variation and are missing from the API documentation. Content types a handler does not expect, so a JSON body where a form parser expects a query string triggers an unhandled error. Race conditions, where the same request fired concurrently behaves differently. Parser differentials, where two components disagree about the same value. None of these are intellectually hard; they are tedious, and tedium is exactly where a machine wins. A tester with eight hours and a 200-endpoint API will not try every parameter with every type against every parser. A fuzzer will, in minutes, and hand the human a list to confirm.

What kind of vulnerabilities does a human find that AI misses?

Everything that requires a goal. A discount engine that can be applied twice, or a coupon that stacks with a sale. A refund path that releases more than it took. A KYC flow that lets a user upload another user's document because the check compares file names. An internal API that trusts a header set by the gateway. A role hierarchy where a store manager can edit a city-wide price list. A fuzzer sees a parameter called role and tries role=admin; it does not know that role=store_manager plus a coupon gives a result worth more than either alone. Chained weaknesses are the same problem: two findings that are each low severity and one note in the middle of a real path to a customer database. That note is a human's, and it is often the most valuable line in the report.

How should a client judge a tool's claim of coverage?

Ask for the finding mix, not the finding count. A scan that reports 1,200 issues and 1,100 are the same template flaw is not coverage, it is a signature. A credible report shows categories, a confirmed count, a false-positive rate the vendor is willing to state, and a worked example for each high-severity item. Then check the opposite direction: does the report contain at least one finding that required business knowledge of your system? If every issue is generic, the engagement was a scan, however expensive the platform. For Indian clients, ask also what the report looks like to a CERT-In or DPDP reviewer, because the evidence standard matters more than the count.

Does using AI change the risk of a penetration test?

Not downward, but it changes the shape of it. Automated probing generates far more traffic against a target than a human tester does, which raises the chance of tripping rate limits, filling logs, or in a badly designed application, a genuine denial of service. The mitigation is operational: scope limits, a test window agreed with the client's operations team, a throttled request rate, and a named stop contact on the client side who can halt the run in minutes. A second risk is false confidence: a client who sees a clean machine report may believe the application is safe when nobody proved the business logic. We mark every machine-generated candidate as unverified until a tester has confirmed reachability and impact in the report.

What are the frequently asked questions?