The three 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.
Check statuses
Each item on the list is a check, and the run page shows where every check stands.
Candidates never disappear. As each one is validated the check moves on from Candidates to Proving, then either to Ruled out or, once proven, to its findings’ severities. Select View candidates on a check to see every candidate and what became of it.
Re-running on the same target
Every run also re-checks the findings still open on that target. A finding that is proven again exactly as reported stays the same finding, unchanged except for when it was last seen, rather than duplicated. When the original proof no longer works but the same weakness can be exploited another way, the new way is recorded as a new finding linked to the original, and the original is resolved once its own re-check finishes without reproducing it, so a fix that worked never reads as one that did not. A finding whose issue can no longer be reproduced is resolved automatically at the end of the run, with a note saying it was re-checked and could not be reproduced. Reopen it if you believe it is still exploitable. A finding you had already resolved or accepted is left closed; if the same kind of issue reappears later, it is recorded as a new finding with its own history.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, and browser origin isolation such as postMessage validation and iframe sandboxing.
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, agentic system and MCP tool security, 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.