What we need, what we test, how long it takes.
One run against your live product, priced up front. Here is exactly what access we ask for, what a single run covers, and the timeline from request to a retested proof report — no surprises, read-only by default.
1 · Access — what we need from you
Most runs start from almost nothing. The essentials are your name and work email, the URL(s) in scope, and written confirmation that you own the target or are authorised to have it tested. From there, more access buys more precise proof — but none of it is mandatory.
+ Helpful, optional
- Read-only credentials, or a staging mirror, so the agent can mirror your stack exactly.
- Two test accounts (or two tenants) — the cleanest way to prove authorization and tenant-isolation bugs. We can create them with your go-ahead.
- An OpenAPI/Swagger spec or a short note on which areas matter most.
× Never needed
- Your production database or a dump of real customer data.
- Long-lived admin or root secrets.
- Anything that would put live customer records in front of the AI model.
A strict data boundary keeps your real data and secrets out of the AI model. When testing needs real-looking data, we use fictional accounts we create — never one customer's data to test against another's.
2 · Scope — what one run covers
A run maps and tests one product's full attack surface — the web app, its API, and the authentication and session layer behind them. Once mapped, the agent works the OWASP classes that actually matter for your stack:
- Access control & authorization — IDOR, BOLA, broken access control, tenant isolation.
- Injection & server-side — SQL injection, SSRF, command injection, template injection, XSS.
- Auth & identity — authentication, JWT, mass assignment.
- Logic & exposure — business logic, secrets exposure.
Proven, not listed. Every finding is demonstrated with a working exploit — a real effect, not a scanner's "possible." When the evidence doesn't meet that bar, the agent says so and either re-proves it or caps the severity. Proof, not guess.
+ In scope
- The one product you submit — app, API and auth layer.
- Read-only testing by default; smallest safe proof for each finding.
- Writes or state changes only with an explicit flag and a second confirmation; payloads neutered and reversible.
× Out of scope
- Anything you don't authorise, or systems you don't control.
- Destructive or denial-of-service testing.
- Persistence, backdoors, or exfiltration of real data.
3 · Timeline — request to retest
Days, not weeks. Nothing is tested before you approve scope, price and a start date.
-
Day 0Request & scope confirmationYou submit the target through the scan form. We come back to confirm scope, the fixed price and a start date. You approve before anything runs.
-
Days 1–NThe runThe agent maps the attack surface and works it end-to-end — enumerate, exploit, validate — proving each finding with a real effect and throwing away false positives instead of padding the count.
-
Delivery · days, not weeksYour proof reportYou receive one written report: every finding with proof, impact, the exact fix and a verdict, plus a static-analysis appendix. See a full sample →
-
Before it reaches youHuman reviewA person checks every finding before the report is sent — never on autopilot. False positives are caught here, not by you.
-
After you shipRetest — includedOnce you've deployed the fix, the agent attacks again — free — to confirm it actually held. The verdict on each finding is updated to fixed or still open.
4 · What you receive
One run produces one report: what was tested, what was proven, the recommended fix and the retest result — written for both an engineer who has to fix it and a stakeholder who has to sign off. The fastest way to understand the deliverable is to read one.
Common questions
Do you need our source code?
No. A run works black-box from the URL. Source access is optional — it sharpens some findings and feeds the static-analysis appendix, but it's never required and never leaves the boundary.
Is it safe to run against production?
Yes. Read-only by default and demonstrated with the smallest safe effect. Writes, deletions or anything persistent need an explicit flag and a second confirmation, and payloads are neutered and reversible. For risky write paths we prefer a staging mirror.
How do you handle our data?
A strict data boundary keeps your real data and secrets out of the AI model. Where testing needs data, we use fictional accounts we create. Findings and reports are retained so you can re-test them, and deleted on request — see the Terms and DPA.
What if you find nothing critical?
You still get the full report: the surface we mapped, the classes we tested, what held, and any lower-severity findings and hardening advice. A clean result you can hand to a customer or auditor is a result.