The short version. Sixteen agents work a target across five phases: reconnaissance, parallel vulnerability analysis, controlled exploitation, conditional post-exploitation and reporting. A finding without a working proof is downgraded rather than published as Critical. Nothing is deleted, corrupted, taken down or left behind.
What this engine does
The engine attacks your application the way an assessor would, from the outside, with no source-code access. It crawls and fingerprints first, then runs eight analysis tracks in parallel, then tries to prove the promising ones by actually exploiting them.
- Injection — SQL, NoSQL, OS command, template and XPath, through parameters, headers and body.
- Cross-site scripting — reflected, stored and DOM-based, with the payload that actually fired attached to the finding.
- Broken access control — IDOR, horizontal and vertical privilege escalation, tenant-boundary probing.
- Authentication and session logic — bypasses, weak session handling, token validation gaps. Credentials you supply are used only to reach the authenticated surface.
- SSRF — including the internal targets an attacker would reach for (metadata endpoints, private ranges), to see whether your application will fetch them.
- Security misconfiguration and exposure — headers, CORS, debug endpoints, source maps, version-control directories, secrets in client-side code.
- Transport security — TLS version and cipher posture, certificate validity, HSTS.
What it deliberately does not do
These are enforced in the runner, not left to the model's judgement. An agent that tries one gets refused before the command runs.
- No destructive actions. No data deletion, no corruption of stored records, no denial of service, no persistence left behind. Exploitation is proof-of-concept only.
- No scanning without authorisation. No DCV and no attestation means HTTP 403, at every tier.
- No scanning of targets that are not yours. Brand and homograph blocklists refuse well-known third-party domains outright.
- No unbounded load. A politeness rate limit governs request rate per host; this is an assessment, not a stress test.
- No credential exfiltration. Credentials you provide ride the dispatch channel, are never written to our database, and are scrubbed from the workspace when the scan ends.
How we prove you are allowed to run it
Authorisation is a hard gate, not a checkbox in our terms. A scan starts only if the asset is verified by Domain Control Verification — you place a DNS TXT record or a file we specify — or you supply an explicit legal-authority attestation stating you own the target or are authorised to test it. A request carrying neither is refused with HTTP 403, at every tier, with no override. For this engine the target is a domain you control, so DCV is normally the cleanest route — and it is the one an auditor will find most convincing later.
Where your data goes, and when it is deleted
Everything runs on EU infrastructure: edge functions in EU regions, scan compute in Frankfurt, object storage under EU jurisdiction, model inference through an EU endpoint. Nothing is used to train any model — ours or a third party's — and that is a contractual term in the DPA, which every plan gets.
- The report — kept two years, so you can hand it to an auditor next year.
- Raw uploaded material — third-party scanner files 30 days, application binaries 60 days, then deleted automatically.
- The anonymous homepage preview — content erased after 24 hours.
- The authorisation record — kept, because it is the evidence that the scan was permitted.
The full schedule is in our Privacy Policy, and the sub-processor list is on the Trust Center.
How a run actually works
Each scan gets its own workspace on an EU machine, and every command an agent runs goes through a sandbox: a separate user and namespace, with only that scan's directory visible. A neighbouring scan cannot read your workspace, and the agent cannot read the machine's environment.
The phases run in order, and the order matters: nothing is exploited before it has been analysed, and post-exploitation only happens at all if remote code execution was actually achieved — on most targets that phase never runs. If the cost ceiling for a scan is reached during analysis, exploitation is skipped and the report says so rather than silently producing a thinner result.
What you get at the end
A report you can hand to an engineer and to an auditor without editing it: every confirmed finding carries CVSS scoring, CWE and OWASP mapping, the reproducible command or request that proved it, and remediation code for your stack. Findings that could not be proven are marked unconfirmed instead of being inflated.
The report also states the assessment's own limits — what was in scope, what was not reachable, whether a WAF interfered. You can see the format in our illustrative sample report, and a real one in our own published assessment.
What this engine cannot find
A black-box engine has a defined reach. These are the things it will not surface, and knowing them is how you decide what else your programme needs:
- Business logic that requires understanding your domain — pricing rules, entitlement edge cases, multi-step workflows unique to your product.
- Anything behind a login it was not given credentials for.
- Flaws that only appear in source code review — dead code paths, unreachable branches, cryptographic design errors.
- Physical, social-engineering and phone-based attack paths. Those are human-assessor territory.
- Chained exploits that need days of patient manual work, or a novel zero-day in your dependency stack.
We publish this list for the same reason we publish our own assessment report, limitations section included: a vendor that cannot tell you what its tool misses is asking you to take the rest on faith.
Frequently Asked Questions
Will this take my site down?
No. Destructive actions are refused at the runner level, not merely discouraged in a prompt, and request rate is governed per host. Exploitation exists to prove a finding is real, not to cause impact.
Do you need credentials?
Not to start. Without them the assessment covers the unauthenticated surface, which is what an anonymous attacker sees. With them it also covers authenticated and authorisation logic, which is where most real findings live. Credentials are never stored in our database.
Can I scan a domain I do not own?
No. Either the asset is DCV-verified or you sign a legal-authority attestation stating you are authorised. Without one of the two the request is refused with 403, and well-known third-party domains are blocked outright.
How is this different from a vulnerability scanner?
A scanner reports what might be wrong based on signatures and versions. This engine tries to prove it, and a finding without a working proof is downgraded rather than shipped as Critical. That is also why the report is shorter than a scanner's and more actionable.
What happens to the evidence afterwards?
The report is kept for two years so it is available for an audit cycle. Raw material uploaded for a scan is deleted automatically on a much shorter schedule, and nothing is used to train any model. All processing stays in the EU.