Can AI do penetration testing?

Enumeration is a coverage problem. Every host, subdomain, endpoint, parameter and version is a thing to be listed, and the failure mode of human enumeration is not error but fatigue. A system that does not get bored produces a more complete map, and completeness is most of the value of that phase.

Path chaining is the second, and it is the less obvious one. Individually unremarkable findings become serious when they compose, and finding the composition means holding many partial results in mind at once and testing combinations. That is the shape of problem machines handle well and people handle in the order they happened to look.

The consequence is a coverage change rather than a speed change. A test that previously sampled a large estate because sampling was all the budget allowed can now cover it, and the findings that emerge from the parts nobody used to reach are frequently the interesting ones.

AI-driven penetration testing delivered as an engagement. Our tooling drives the attack; a Cryvanta operator scopes it and verifies every finding.

Business impact is the clearest gap. Whether an exposed administrative interface is a critical finding or an accepted risk depends on what sits behind it, who uses it, what compensating controls exist, and what the organisation has already decided to tolerate. None of that is present in the traffic, and a confident severity rating produced without it is a guess with a number attached.

The second gap is knowing what not to touch. A test runs against a live estate, and judgement about which actions are safe in that estate at that hour is contextual. This is the same boundary problem that shows up in automated response, and it has the same answer: a scoping decision made by a person in advance.

The third is verification. An exploitation attempt that appears to succeed may have succeeded, or it may have hit a honeypot, a stale record, or an artefact of the testing setup itself. OWASP lists misinformation as LLM09:2025, and this is where that risk lands in offensive work: a fluent, well-evidenced, wrong finding costs a customer more than no finding, because it consumes engineering time on a fix for something that was never broken.

If coverage is the thing that improved, scoping should move with it. A test scoped as a sample of an estate was shaped by an economic constraint that has partly lifted, and continuing to scope that way spends the gain on nothing.

The questions worth asking a provider change accordingly. Not how fast the test runs, but how much of the estate it covers and how that was decided. Not whether AI is used, but which steps it performs and which a person performs.

One question does most of the sorting: who verifies a finding before it reaches you, and what does verification mean here? A provider whose answer is a confidence score has told you the triage is still yours.

For an organisation inside NIS2 scope, testing is not an end in itself. Article 21 requires policies for assessing the effectiveness of risk management measures, and a test is the usual way to make that assessment concrete rather than asserted.

That framing changes what a good deliverable is. A regulator reads for whether an assessment happened, what it covered, and what was done about what it found. Reproducibility matters more than volume of findings, and a report full of unverified items is weaker evidence than a shorter one that holds.

It also means the scoping decision is itself part of the record. What was in scope, what was excluded and why, and who decided are the questions that come after the findings, and they are easier to answer if they were written down before the test rather than reconstructed after it.