Skip to main content
A penetration test is run by a team of agents working the way a human tester does: map the surface, form a hypothesis, then try to prove it. The defining rule is that a result becomes a finding only after it has been exploited.

​
The four phases

1

Surface mapping

An agent maps the attack surface: routes, parameters, authentication flows, roles, technologies and trust boundaries. In a black box run, any API documentation you attach seeds this. In a white box run, your source provides it. The result is a list pairing each component with the vulnerability classes worth testing against it, sized to the package you chose.
2

Discovery

One agent per item on that list, all running in parallel, each proposing concrete candidates. Nothing here is reported. A candidate is a hypothesis, not a finding.
3

Validation

Each candidate goes to a fresh agent that does not know why it was proposed, which is what stops a plausible story surviving on its own momentum. To become a finding, the candidate must yield a working, minimal and non destructive proof of concept. A known vulnerable dependency instead needs its vulnerable version independently confirmed as present.
4

Fix, white box only

An agent patches the root cause in source and re-runs the proof of concept to prove the issue is gone.
Confirmed results are deduplicated and written up as findings.

​
Vulnerability classes

Injection and execution

SQL and NoSQL injection, command execution, server side template injection, XML external entities, insecure deserialization, prototype pollution.

Access control

Insecure direct object references, broken function level authorization, mass assignment, authentication and token handling, cross site request forgery.

Server side

Server side request forgery, path traversal, request smuggling, header injection, open redirect, subdomain takeover, information disclosure.

Client and content

Cross site scripting, insecure file upload and download handling.

Logic

Business logic abuse and race conditions, including multi step attack paths that chain smaller issues.

AI surfaces and supply chain

Prompt injection against AI features, and known vulnerable components confirmed present.

​
Engagement types

The engagement is derived from what you configured, and is cumulative. Every finding records the engagement and package that produced it, so a target tested black box once and white box later keeps both results distinguishable.

​
Authorization and safety

A target cannot run until domain ownership is verified with an organization specific value you publish by DNS record or hosted file. The verification value is unique per organization, so proof of control cannot be transferred. A run against an unverified target is refused.
Every proof of concept must be minimal and non destructive. The package you choose bounds both how deep the testing goes and how much traffic it generates.

​
Evidence on a finding

Vulnerability class, affected endpoint or package, CVSS vector and derived score, CWE, the proof of concept, supporting evidence, and the engagement and package. For a white box finding traced to source, the repository, commit and file are recorded as well.

​
Scheduling

Daily, weekly or monthly, per target and per engagement and package combination. Configuration changes apply to future occurrences. Runs already in flight keep the configuration they started with. See Set up a pentest.