Using AI during a penetration test

An AI tool reads an API specification and suggests a possible access-control problem. That might be a useful lead. Before it belongs in a penetration test report, someone needs to establish whether the endpoint exists in the tested version, whether the suspected behaviour is reachable, and what actually happens when it is tested.

That gap between a suggestion and a finding is where much of the work remains.

Give the tool a specific job

There are sensible uses for AI during an assessment: organising notes, suggesting questions from a sanitised design document, grouping similar observations, or improving a report’s wording. The tester should be able to explain which of those jobs the tool performed.

For example, a model might group several access-control observations as duplicates. Before removing any of them, check the affected roles and endpoints. Two responses that look similar may expose different resources or require different fixes.

Report editing needs the same care. A smoother sentence can quietly strengthen a claim. “This response suggests that another user’s record may be accessible” must not become “An attacker can access all customer records” unless the evidence establishes that impact.

Agree the boundaries before active testing

When a tool can send requests or invoke other tools, define what it is allowed to do. The engagement still needs named assets, permitted techniques, a testing window, and a way to stop activity.

A useful planning question is what happens if the tool discovers a new hostname. Is it inside the authorised scope? Who checks? A model’s decision that the host looks relevant is not permission to test it.

The same applies to instructions encountered during testing. A response body or a retrieved document can contain text aimed at the testing agent. That material is part of the system being examined; it cannot authorise a new action or change the engagement rules.

Know where the evidence goes

Before using a model with client material, establish which provider receives the input, what is retained, and who can access it. Source code, request captures, and screenshots may include credentials or personal data even when they look like ordinary debugging material.

Use synthetic examples or remove unnecessary fields where possible. Sanitisation needs checking too: removing a token from the request doesn’t help if the same token remains in a response, a screenshot, or an attached log.

A buyer should be able to ask how AI is used and receive a concrete answer. “We use AI to make testing faster” doesn’t explain the data handling or the controls around active tests.

What should survive into the report?

The report needs the evidence that supports a finding: the affected asset, prerequisites, relevant requests and responses, observed impact, and a fix the engineering team can work with. It should also state what could not be verified.

The number of generated test cases is a poor substitute for that record. Ten well-chosen tests of a sensitive workflow may answer a question that hundreds of generic requests never reach.

Human validation should mean someone has checked the technical evidence and accepted responsibility for the finding. It should be possible to explain why the finding is valid without referring to the model’s confidence or wording.

AI use and accreditation

CREST’s July 2026 announcement introduced responsible-AI organisational requirements and an AI-enabled penetration testing annex. It also distinguishes AI used within a testing service from security testing of AI systems themselves.

When assessing a provider, verify its current accreditation and the services covered. An application for accreditation or the use of an AI product doesn’t establish that status. The questions in this article are intended to help evaluate a testing process; Actiotech is not claiming AI accreditation here.

References

• CREST AI accreditation announcement
• CREST accreditation standards
• OWASP AI/LLM application security testing

Reviewed 10 November 2026.