Home / How it works
The loop
Find it. Break it. Fix it. Prove it.
Four stages. Most tools stop after the second one, and almost none of them come back to check that the fix worked.
Stage 01
Find it
The engine gets two things at once: your running application and the code behind it. It works through the app in a real browser, following links, filling in forms and logging in as each role you gave us. At the same time it reads the repository, so every page and API it finds can be traced back to the code that serves it.
That pairing is the whole product. A tool that only watches traffic is guessing at what the app was meant to do. A tool that only reads code is guessing at what an attacker can actually reach. Having both removes most of the guessing from both sides.
Stage 02
Break it
Nothing is reported on a hunch. When the engine thinks it has found something, it tries to exploit it, and only a successful attempt becomes a finding. From 19 October you can switch on confirmed-only mode and get a list holding exactly what we broke. Nothing marked "potential", nothing padded out to make the report look thorough.
Every confirmed finding arrives with the proof attached: the request that worked, the response that came back, a screenshot of the result, and the file and line that allowed it. See what a finding contains →
Stage 03
Fix it
We tell you exactly what to change, in your own code, with the surrounding lines in view. Not a general paragraph about input validation pulled from a reference library. Each finding carries a ticket reference so the work lands where your team already tracks it. Today you paste that reference in by hand: automatic ticket sync is on the list, not built.
Stage 04
Prove the fix
This is the stage the company is named after. A re-run sends the exact attacks that worked at your new code. The issue closes when the attack fails. Not when a developer ticks a box, and not because a scanner quietly stopped mentioning it. Re-running against confirmed findings works today; the automatic close, where a finding cannot be marked done until the attack fails, ships 16 November.
What you end up with is a history you can hand to a customer or an auditor: here is when we found it, here is the proof it was real, here is the change you made, and here is the proof it stopped working.
The money bugs
No signature exists for “the maths is wrong”
The bugs that cost money directly are not malformed requests. Every call is valid, every field is the right type, and the total at the end is wrong. There is no pattern to match, which is why tools built on patterns never find them.
Stacked discounts
Two promotions that were never meant to combine, applied together. Nothing about either request looks unusual. The basket is simply wrong.
Negative quantities
Order minus one of something and wait for the refund. The field was called quantity. Nobody said it had to be positive.
Quota resets
Downgrade, upgrade, and your monthly allowance starts again. A paid limit that resets for free is a paid limit you do not have.
Payment races
The same balance spent twice, because two requests arrived close enough together that both were checked before either one finished.
Ships 4 Jan Finding these means understanding what your product is actually for. We read the code that implements each rule, try to break the rule while logged in as an ordinary customer, and report only the attempts that went through. The business-logic module lands 4 January.
Underneath
How a scan actually runs
Every run on its own
Each scan gets its own worker, its own queue and its own workspace. Two scans cannot see each other or slow each other down.
Your code is not kept
On cloud runs the repository is copied for the scan and wiped the moment the scan ends, whether it finished or failed. Nothing is held between runs.
Or never copied at all
Run the agent inside your own network and the code is read on your hardware and never sent anywhere. Private scanning →
It cannot run away
Limits on how many scans run at once are live today. Hard time and spend caps per scan, with the cost shown before and after every run, land 13 November.
Watch one run
A scan, from first request to closed loop.
The shape of a real run: work through the app, read the code behind each route, try the attack for real, then re-test what you fix.
One run, narrowed to proof
From everything it touched to what it reported.
What matters is not how much a tool shows you. It is how little of it you have to check by hand.
One run, narrowed to proof
figures from the sample run further down this pageQuestions
The ones we get asked.
If yours is not here, ask an engineer directly rather than a form queue.
Do you need our source code?
For the interesting work, yes. Reading the code is what separates this from a tool that only pokes at the outside. But it does not have to reach us. Run the agent inside your own network and the repository is read on your hardware and never sent anywhere.
How is this different from the scanner we already run?
Keep your scanner. This is for the bugs it cannot see. A scanner tells you something might be wrong; we try to break it, report only what worked, then re-run after your fix to prove it stopped working. Two things in particular are out of reach for anything that cannot read the code and drive the app at the same time: one role reaching another role's data, and the business-logic bugs above.
Will it break our production environment?
Exploitation is off unless you turn it on, and you set it per application, with a list of anything destructive we should leave alone. Most teams run with exploitation on against staging and look-only against production.
What does a scan cost to run?
You bring your own AI provider key, so that part is billed to you directly with nothing added by us. We record the spend against each scan; hard caps, and the cost shown before and after each run, land 13 November. The prices are published in full.
How long does a scan take?
How long a run takes depends on the size of the application and how much of it is reachable. We have not published a figure, because we have not measured one honestly yet. Wall-clock duration and cost per scan are two of the four numbers in the benchmark on 3 November, and from 13 November the console shows both before and after every run.
Can we resell this to our own clients?
Yes. Each customer's data sits in its own space, and the reports carry your name and logo. The partner setup and white-labelled reports land 30 October, and the one screen showing every client lands 27 November. Partner terms are published.
Watch it do this to one of your apps.
The four stages read cleanly on a page. On a call we run them against something real and stop at each one, so you can see what the break stage actually produces before you decide anything.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.