# How AI penetration testing works, step by step

Source: https://aipentestservices.com/how-it-works/
Publisher: Excession Labs (aipentestservices.com)
Last updated: 2026-11-09

How AI pentesting works in nine steps, from scoping call to retest: written authorization, planner and workers, tool rules, evidence checks and the report.

> **Short answer:** An AI-assisted pentest with Excession Labs runs in nine steps: scoping call, written scope and authorization, access setup, planning, parallel testing under allow, ask and deny tool rules, evidence-linked findings, evidence check by Excession Labs, report, then fixes and retest. You see a defined output at each step.

An AI-assisted pentest follows nine steps. People agree the scope and check the evidence, and the agent, Incursion, does the testing work in between. For each step we list what you see.

## The nine steps at a glance

Scoping callA short call to understand the app, the API and the reason for the test. You get questions and a list of what we need.
Written scope and authorizationExcession Labs writes the scope. The system owner authorizes the test in writing. Testing starts only after this.
Access setupYou provide test accounts, roles and the environment to test. We confirm access works.
PlanningA coordinator splits the engagement into objectives and tasks.
Parallel testingSeveral workers run tasks at the same time. Tool rules (allow, ask, deny) limit what they can do.
Evidence-linked findingsA task finishes only when each finding links to its evidence.
Evidence checkExcession Labs checks the evidence for each finding.
ReportYou receive the written report in HTML, PDF and Markdown, with proof-of-concept scripts.
Fixes and retestYou fix. We can retest the fixed findings.

## What happens before any test starts?

Three steps come before the first request: a call, a written scope and your access setup. Nothing runs against your system until the owner authorizes the test in writing.

1. Scoping call. We ask which apps and APIs matter, which roles exist, which data is sensitive and what the test is for. You get a short list of open questions.

2. Written scope and authorization. The scope names the hosts, the API base paths, the environments, the roles and the things we will not touch. It also states the bounded tests and their cost (for example email sending or paid third-party APIs). The system owner signs the authorization, and we test only with it. The [safety page](/safety/) lists the limits.

3. Access setup. You create test accounts for each role. Two accounts in the same role help prove cross-account effects. You also confirm the environment, any allowed IP addresses and a contact for stop requests. You then get a short access check: which accounts work, which roles they cover and what we could not reach.

## What does the agent do during testing?

The agent plans, then runs tasks in parallel under tool rules. A task counts as finished only when every finding carries evidence.

4. Planning. The coordinator turns the written scope into objectives, such as "compare what each role can read" or "test the upload endpoint within the stated bound". It splits each objective into tasks.

5. Parallel testing. Workers take tasks and run them at the same time. Each worker keeps its own notes and findings. Tool rules apply to every call:

| Rule | What it means | Example use |
|---|---|---|
| Allow | The tool runs on its own | Read-only HTTP requests inside scope |
| Ask | The tool waits for approval | A state-changing request against test-owned data |
| Deny | The tool is blocked | Anything outside the written scope |

The operator sets the rules from the scope.

6. Evidence-linked findings. A task is done only when each finding links to its evidence. The evidence is a saved request and response with timestamps, or a browser-observed result. A write is proven by reading the changed record back through another session. A bare "success" response is not proof. Controls run next to the exploit request: a nonexistent identifier, the wrong record type, another account's token, anonymous versus signed-in. Controls that held are kept for the report.

## How do findings become a report?

Excession Labs checks the evidence for each finding and writes the report. The agent does not write the final report alone.

7. Evidence check. Excession Labs reviews each finding against its saved evidence. A finding that has no real effect shown does not become a confirmed finding. Inferred paths are labeled separately. Open questions go in "Limitations and open questions".

8. Report. You receive HTML, PDF and Markdown versions, plus proof-of-concept scripts. The report has these parts:

- Project details: scope, assets and severity scale
- Assessment method and safety constraints
- Evidence labels ("Observed", "Browser-observed")
- Executive summary with priority actions
- Findings at a glance
- One section per finding: description, impact, verified results, reproduction, remediation
- Controls that held
- Remediation plan
- Limitations and open questions
- Evidence index and appendix of reproduction scripts

The severity scale has four levels: Critical, High, Medium and Low, each with a written definition. CVSS vectors are not added by default. If your program needs CVSS, say so during scoping.

9. Fixes and retest. Your team fixes the issues. You then ask for a retest of the fixed findings. Incursion supports retesting a finding. For testing after later releases, see [per-release testing](/per-release-testing/).

## Which parts are done by the agent and which by people?

| Step | Done by |
|---|---|
| Scoping call, written scope | Excession Labs with you |
| Authorization | The system owner |
| Test accounts and environment | You |
| Planning and parallel testing | Incursion, under the tool rules |
| Approval of "ask" actions | The operator |
| Evidence check and report | Excession Labs |
| Fixes | Your team |

[AI vs manual pentesting](/ai-vs-manual-pentesting/) explains the split. The [example assessment](/example-assessment/) is a labeled sample run, and the [Incursion page](/incursion/) describes the agent.

## Questions

### Do I need to give the agent production access?

No. You choose the environment during access setup. Many teams test staging with test accounts first. If you want production in scope, the written scope says so, and the safety rules for production apply.

### Who decides which tools the agent may run?

The tool rules decide. Each tool runs on its own (allow), waits for approval (ask), or is blocked (deny). The rules are agreed as part of the scope, not left to the agent.

### What happens to a finding that cannot be proven?

It does not become a confirmed finding. A task is done only when each finding links to evidence. A path that was inferred but not reproduced is labeled as inferred, and open questions go in a limitations section.

### Can I see progress during the test?

Agree this in the scope. The steps above show what you receive at each stage. We do not state fixed timings, because they depend on the scope.