AI Pentest

Give the AI Pentest agent targets and, optionally, a sentence of instructions. It tests them like a penetration tester and reports only what it could prove. It runs from either scan form: web applications from Web App Scanning, hosts and networks from Infrastructure Checks. There are no profiles to configure.

What it does

• Finds the services and web applications in the targets you give.
• Tests them, including signing in with credentials you give or that it finds, and tests web applications with AI DAST.
• Tries to prove each issue, records only proven findings, and links findings where one enabled another.

It can use the scanners your team has set up (OpenVAS, Nessus, Acunetix) and ScanSuite's own web and network checks; a scanner that is not set up is not used. Several targets are tested in parallel and reported together.

Before you start

Targets follow the rules in Web App Scanning, Targets; who may change them is in Teams and roles.

Start an engagement

1. 01
   Open a scan form

   Web App Scanning for URLs, or Infrastructure Checks for IP addresses, ranges, networks and host names. On Infrastructure Checks, leave Select Scan Type on Vulnerability Scan: AI Pentest is offered only there.

2. 02
   Choose the product and enter the targets

   Product / Eng ID, then the targets under Target Scope.

3. 03
   Check that Autonomous AI assessment is on

   In the AI Pentest section. It is on by default for a new user; the form then remembers your last choice.

4. 04
   Write instructions (optional)

   In Instructions (optional) under the targets, see below.

5. 05
   Add sign-in details (optional, web only)

   Cookies (optional) or Custom header (optional) on the Dynamic Analysis page. Read the warning on state-changing requests first.

6. 06
   Select Start Analysis

   Scan submitted appears and the scan's page opens.

zoom_inEnlarge

Check that it worked: the scan's page shows the AI pentest card, Where the engagement is, with a sentence saying what the agent is doing now. If the scan does not start, the message is explained under If the scan does not start; if it fails later, the reason is in that card and in the log.

The fields

The Infrastructure page has no Cookies or Custom header fields. To test signed in from there, mark credentials for AI scans on the Credentials page.

Instructions

Plain sentences. Scope comes from the targets, not from the instructions: the agent never leaves the targets whatever you write. Examples:

Enumerate services, prioritize SMB and web, and verify exploitable findings with a PoC.

Focus on the login flow and look for authentication bypass and SQL injection. Do not brute force.

Sentences that say something plainly become rules that ScanSuite enforces on every request and scanner, whatever the agent decides. The scan's log lists them at the start, under the operator's instructions as rules every agent follows:

Signed-in testing

• Every login form the agent finds is checked for default and common credentials; a working pair is a High finding. This check always runs.
• Credentials marked Use in AI scans (column AI scans, bulk Mark for AI scans / Unmark AI scans on the Credentials page) are tried as well.
• Credentials that work, and the session you supply, are used to continue testing signed in, including logins in several steps and logins protected by a CSRF token.

Safety guarantees

• It never sends traffic outside the targets you give. A URL target limits it to that site's port; a host, IP address or range covers every port of the host.
• Exploit code runs isolated from your network and the ScanSuite server.
• It downloads exploit references only from ScanSuite's vulnerability database.
• Every engagement has a step budget and a time limit of about three hours per agent, and the result says why it stopped.
• A host it finds that you did not name, such as a subdomain, is tested only once it is admitted: it must lie under a domain you gave, resolve, not lead to a third party, CDN or cloud edge, and be allowed by the team's targets. The report lists every such host, admitted or refused, with the reason.
• Text in a target's answers is data, never instructions: a page that tells an AI agent to test other hosts or ignore its rules changes nothing, because scope and rules are enforced in code. ScanSuite notes such text on the scan page and in the report.
• A request or scanner run the rules refuse is not sent; the agent is told which rule refused it.

Production settings

For engagements against production systems, a system administrator can switch on stricter behaviour for every AI Pentest of the installation. All are off by default. On a server they go in /opt/scansuite/.env (see Setup parameters and services); on Google Cloud, in the deployment's extra_env in terraform.tfvars.

The scope judge and the log watch use the AI connection of the tasks Scope judge and Log watch, which a team can route to a different model than the agents use (see AI providers).

1. 01
   Edit .env

   Add the settings, for example SCANSUITE_PENTEST_AGENT_SAFE_DEFAULTS=true.

2. 02
   Restart

   Expected: [+] All services healthy.

   ShellCopy

   cd /opt/scansuite && ./scansuite restart

3. 03
   Check

   Start an engagement. Its log shows the rules with (… +safe) and the stop rule first: Stop at the first foothold …

Follow an engagement

The scan's page shows the engagement live: the stage it is in and what it is doing now, the Execution paths each agent took, the services it found and how far each was tested, and the findings as they are proven. See The scan page.

zoom_inEnlarge

A run can pause itself, with a warning in the log saying why:

• The harness paused the test: 5 refused actions within 300 s: the refusal pause.
• The log watch found a harmful pattern in the last 5 minutes: …: the log watch.

Nothing runs while it is paused. Resume or stop it from the scan page. Text aimed at AI agents in a target's answer shows as a warning too: … answered with text aimed at AI agents: "…".

Message the agents

While an engagement runs, Message the agents on its scan page sends it a message. Send to chooses who reads it:

Under each message, Read by names the agents that have read it. A restriction that must hold for every agent belongs in a message to all agents: one agent's message never changes the rules. To stop one agent, use Stop this agent in its row; Stop and report ends the engagement and reports what it proved.

For a security operations team, the agents and the log watch also write one line per event to the service log. On Google Cloud these lines are in Cloud Logging, where a log-based alert can match them:

How an engagement ends

The reason appears on the scan's page as Finished in … · <reason>. Other outcomes shared by all scans are in Managing scan execution.

Where the results go

Like every AI scan, the engagement records its findings on the Vulnerabilities page. The engagement report, in Markdown and XLSX, is in the scan's Report in Scan History. A finished engagement shows the status Finished there.

Besides the findings, the Markdown report lists:

• findings the verifier could not confirm (Not verified) and the ones it rejected, with the reason;
• the hosts you did not name: each admitted or refused, and why;
• text aimed at AI agents that the targets answered with;
• what the agents tested without a finding, and what they left untested.

Personal data in the evidence (e-mail addresses, phone numbers, IBANs, card numbers) is masked, and passwords the agents found or were given do not appear.

From a pipeline or a terminal

scansuite-ci --scan-type dast --scanners ai_pentest \
  --target https://staging.example.com \
  --instructions "Focus on the API. Do not brute force."

Use --scan-type infra with host targets for an infrastructure engagement. A pipeline must name only targets the user confirmed for testing. See CI/CD and automation.